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
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.
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 the 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 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
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.