Time and money are two things you can never have enough of in the development of mobile apps – or any other kind of software for that matter. You’re always short on budget, behind schedule, and afraid of the next bump or obstacle that lies in ambush ahead.
Much of time and budget deficits in app development have to do with the unpredictable nature of software development in general. You don’t precisely know what your target audience and end users want, especially if you’re building something totally new and without precedent. In fact, the users themselves can be as clueless as you are about their requirements and will only know what they want when they see it.
There you have a “chicken and egg” problem again. How do you build something you don’t know?
Naturally, some of the design decisions you make in the early stages of app development will be based on assumption. Some of those decisions will be way off mark and eventually culminate into something that deviates considerably from what the users want. At that point the only way to steer back on the right course would be to restructure, redesign (or sometimes abandon and restart the project, if you have the heart left for it), which means the project will require more time, more resources, more budget, and a helluva lot of more nerves.
One solution to save time and money in app development is to push design changes and corrections as early in the development lifecycle as possible, where implementing them will cost much less, both in time and money.
But how can that be achieved? In this post I’ll share some development and management tips that will help you to mitigate risk and save time and money in app development.
wear your users’ shoes
Most seasoned programmers will tell you that you have to think with your audience in mind if you want your app to be a successful. And this doesn’t only mean to think about what they need from your app or what they’ll be using it for. You need to think in the broader context and answer the many questions that can occur to your users.
Think about the processes, tools, use cases and ripple effects beyond the specific functionality of your app. What are the high level goals the users are trying to accomplish? What are the obstacles standing in their way? What opportunities can you provide that they’re oblivious to?
Tackle the questions by yourself, but file away the answers, and go to the next step.
Don’t have money to burn?: How to test your app on a tight budget
interview your customers
After having answered the questions yourself, find a few potential user – people who fit the persona of the end user – and ask them questions regarding the functionality of the app.
Questions should be broad, like: “How do you spend your day? What do like best about your work? What do you hate most? What tools are most cumbersome and you would like to see replaced?” Avoid asking questions that will lead the interviewee to specific answers, and write everything down.
Of course, you shouldn’t expect accurate answers in the beginning of the development process, because the target users themselves won’t be able to opine on something they haven’t seen yet and whatever answer they’ll give you will be vague. But you’ll have a general idea.
cross-examine the answers
Compare your own view of the problem space with that of the user. Having both will help a lot in overcoming the gap between yourself and the users, and having a better grasp of the concept and the solution that will help overcome the challenges. As the developer, your answers will naturally be influenced by your understanding of app capabilities, the possibilities and impossibilities in app development, previous successful apps you’ve analyzed and tucked away in your mind as reference for design problems.
The end-user’s answers will be influenced by the nitty-gritty details of the work, challenges they’re faced with every day, frustrating aspect of their work that’s bothering them and the business goals they wish to achieve.
The areas where your understanding and that of the user overlap are the best places to start from and fix everything else.
create an outline
Based on your new understanding, create a quick sketch of an app that would be the answer to the problems of the user. It doesn’t need to be a high quality layout design and only needs to convey the concept. If you’re not the designer yourself, make sure that your designer accompanies you in the interviews and your own brainstorm sessions. I employ use cases and user stories to better structure the context of my app layouts.
As soon as you have something visual to offer to your end-users, they’ll be able to give you early feedback. Of course, at this stage, the app isn’t nearly as tangible as it’ll be after it’s developed, but every piece of feedback you can get from users here is vital. Design corrections at this stage cost nothing in comparison to the later stages of development, where finding and fixing problems can be a demanding and costly endeavor.
Before proceeding to writing the app, you should repeat the cycle at least one more time, correct the prototype, take it back to the users for feedback and make corrections again. With a little effort and the help of simple mockup tools, you can create a navigable layout for your app and your users will have a much better grasp of the end product.
invest in an iterative
Once you’ve worked out the kinks of the design you can start writing the code. But does it mean that you’re done with the user until the end of the development process? By all means, no! As your app design concept starts to materialize and become implemented, new twists and turns will surface, things that you can’t find out on your own. You’ll definitely need the help of the end users again to help you stay on track. This can be accomplished through an iterative development process such as Agile or the Rational Unified Process (RUP).
The basic idea behind iterative development is to break down the app development process into smaller chunks (called “sprints” in Agile and “iterations” in RUP), each of which consists of its own design, development, testing and user feedback disciplines. It is important to have the user test, review and give feedback on the product you develop at the end of each iteration. This is the only way you can make sure you haven’t deviated from the main goal.
The length of each iteration will depend on how much you want to accomplish, but the general range is between two and six weeks. The outcome of each iteration will define the roadmap for the next one.
Managing time and cost is crucial to every software development process, more so with apps. The abovementioned cycle is a tried-and-true method to minimizing risks and making sure you approach your goal in a much more calculated manner.
Of course this doesn’t mean that you’ll be hitting the target at point blank range, but at least you won’t miss it altogether and you’ll be taking much steadier steps.