Custom App Development Best Practices
By Eric Middleton, 1Rivet
It can be easier than you think to build a custom app in a short amount of time and at a reasonable price, as well as providing users something valuable. The key is to think through the business process, the features and functions, the data, and the minimum viable product.
Every time we build a custom app from scratch, our biggest task is defining the scope. A custom app can do anything and everything, but what you choose to include and exclude has to be logical. Start by identifying the business process the app will solve.
What Do The App’s Users Need?
Whether the app is for internal use or will be customer-facing, your first steps are to define what the users want it to do and how they currently do the tasks the application will accomplish.
Let’s say you’re building a workflow tool where tasks will jump from department-to-department and person-to-person for creation, reviews, amendments, and approvals. Start by creating a swim lane which includes every person or department involved in the process. Begin with the very first person who would create the task and think about their interactions, then work your way through the process flow until the end.
What Data Is Critical?
Along the way, define the data the app must capture. What are the most critical pieces of data that relate to the application? Knowing that answer is key to the success of the application design. Using Turbo Tax as an example: The key data includes your tax documents, your answers to questions about income or expenses, your personal identification, etc. All of data directs you through a process that is specific to you.
Ultimately, an application can be functional, but if it doesn’t capture the right data at the right point in the process, it will disappoint. For business apps — if the data doesn’t fuel analytics, reconciliation, or decisioning — it will miss the mark. Business users are busy people and providing them with guidance or even a system-generated decision will keep their business on task.
Once you understand the data, you can move on to designing the application. How will the screens flow? We find it to be very beneficial to do screen design in an Agile way. We take functions and processes of the application and design through those lenses.
App Design Considerations
Before you design the first screen, you have to set color schemes and navigation standards. That’s much easier to do if you have brand standards and user interface and user experience staff to implement them. If not, then it is a perfect opportunity to do it now because this application can set the go-forward design standards.
If you’re doing it all yourself, setting those design benchmarks is critical. It may not matter if you opt for blues and grays over blues and blacks, but you do need to use the same user action color throughout the app. Just as you would in building a website, using the same action color will help the user see those markers quickly and know what to push when it is time to select that “approved” button.
Defining Minimum Viable Product
Once you build those screens, you’ll now have a much better estimate of just how long it will take to build the application. From a consulting viewpoint, this is the point at which we usually have to tell clients if we can do everything on their wish list or not.
It's the price tag that generally leads companies to focus on what’s really important for the app to do and how much they want to spend. We find at this stage in the project clients will complete a minimum viable product (the bare minimum your app must do) and then move additional functionality to other phases of the project.
Personally, I think the best option is to define the minimum viable (MVP) and get the app into the hands of the users as quickly as possible. You can do user interface (UI) and user experience (UX) forever. You can overcomplicate the process, the screen designs, and the system. The goal should always be quick out the door, gather feedback, and update the application.
MVP has an advantage over doing a full product layout on flat screens. Some people think you can use layouts to mentally walk through an app and make any needed adjustments before you build, and there is some truth to that.
If I can show you five screens and flow in an app prototype, you might realize the flows should work differently. The data you thought should go on screen five really belongs on screen three. Or, you don’t need the complete customer history on page two, just the last five transactions the customer completed.
However, until people can click through something and see it working, you won’t know if you really solved their issues or got their data right. How people interact with and move through an app is the real test that challenges the process you chose to incorporate in the app. Agile development allows for this, as well as for the users to quickly see a new function or feature added to the overall application.
Going with the MVP lets you see where and when the user isn't using the app as efficiently as they could. Testers will typically ask great questions, too. Do I have to do these eight steps or can the system do that for me? Do I have to scan that in or can I use my phone to take a picture and upload it to the app?
Agile, Waterfall, Or Wet Agile?
After getting user feedback and testing, some folks like to go with true Agile and launch things into production and get people to use the system. At 1Rivet, we like to use a “Wet Agile,” which is between Waterfall and Agile. You create new features and components, but don’t launch a new application until it's done or done enough. Of course, putting an app into production with 10 percent functionality may not be acceptable to some users. It definitely won’t work if the tail end of development includes critical decisioning tools users need. The key here is determining what needs to go in first and what can wait.
I’ve worked in shops where, if we could automate five steps and collect enough data to take a process from paper to the cloud, the users satisfied. They’re happy to get the next five steps done two months from now. When an app goes into production like that, there’s a delicate balance between when its usable and useful to the user because it delivers critical information and when the app is not quite there yet.
Launch Based On Business Goals
Either way, from a development standpoint, it’s important to think logically about the business process when setting a launch goal. Some solutions can’t go in until they’re completely done, even if it takes a year.
In other cases, if an app has two functions done, it can go into production. And, in Agile, you can sequentially release the other functions so the clients get the benefits sooner rather than later.
No matter which option you choose, you must know what the core functions and features are and whether you can build them fast enough in an Agile way.
For example, eBay would never launch and say, “You can load photos and share information about an item, but not bid to buy it.” Being able to bid was a process that had to be included before launch. However, eBay could have launched without the ability to see seller other items for sale at a later date.
If your app sells products, does it have to have every payment option? Maybe for launch, you have credit cards, then add PayPal and then add Venmo. Launch, get people used to your app, then add other cool features and functions you think they want. If you’re lucky, the users will love precisely what you give them, and the rest is just uplifting. Plus, we find users are where the best ideas come from for the future of an application (and why listening to users is another key)!
Progress Versus Perfection
Custom app development isn’t an exact science, but the answer to any question along the way can never be “perfection.” When building a custom app, perfection is the enemy. It’s like building a house and saying, “I’m not moving in until the pool and patio are finished,” even though it’s winter and you won’t use the pool or patio for five more months.
If you’re paying two mortgages, the correct answer might be “I’m moving into the house as soon as I have running water, a roof over my head, and an air mattress to sleep on.”
The same is true with a custom app. If you want to build a great app quickly and cost-efficiently, just take time to think through the process, the features, the functions, the data and your minimum viable product. Once you know all that, you’re sure to succeed.
About The Author
Eric Middleton is Managing Partner and CEO of 1Rivet with over 20 years of experience delivering complex systems and business integration programs and in-depth knowledge of program management, marketing and technology consulting experience.