So you want a mobile app for your company but you don’t know how to get it built? In this series of posts I’ll tell you all about how you go from idea to App Store. We’ll cover all of the steps: from firming up your initial idea to finding a developer to getting your app out to your clients.
Today we’ll talk about the second step, designing your app. In other words, what exactly will your app do? The posts in the series will include:
- Firming up your app concept: Before talking to developers
- App design: What does your app do?
- How to find the right app developer for your project
- Engaging a developer: Contracts, milestones, and other considerations
- Working with an app developer: Communication and testing
- Putting your app out there: App Store submission and what happens after launch
App design: What does your app do?
Once you know the goal users will use your app to accomplish, the next step is to figure out how your app will let them do it. Depending on your own experience and how well you know your current customers, you may want to do this on your own, with your own staff, or with your app developer. The design should consider the needs and wants of the users as well as the limitations and capabilities of the device.
We’ll discuss finding and choosing an app developer next time but consider bringing them in while you’re working on the design. They know their mobile platform’s capabilities and limitations intimately and will be able to provide technical guidance. But even more importantly, it’s an easy way to set up a short contract to see how you and the app developer communicate and work together.
I strongly recommend doing a short engagement before embarking on the longer development contract with a developer. Just make sure that it’s clear that this is a design-only contract, with no coding to be done, and that you’ll get a clear and concise design report. If you find that you prefer not to work with this app developer, that report will provide a great head-start for another developer. It should also serve as the basis of your development contract.
You don’t have to decide on the color of every button at this point but the design report should outline all of the screens and features to be included.
So how do you get to that outline? First, write out the tasks users will accomplish with your app. There should be no more than 3 tasks. In the case of a banking app it might be three things: check their balances, pay their bills, and review recent transactions. For a Twitter app, the tasks could be: sign up for an account, post a tweet, and read the latest tweets.
For each of those tasks, figure out what the flow of actions should be for someone wanting to accomplish that task. For paying a bill in a banking app, this flow might be:
- Pick the bill to pay
- Pick an existing account to pay the bill from
- Enter the amount to pay
- Show a confirmation screen with the payer account, payee, and amount
- When they press a “Pay” button on the confirmation screen, tell the bank’s servers to make the transaction
Draw out a set of screens where the user can do these steps, with arrows showing how they move from one screen to the next. POP – Prototyping on Paper is a great app for trying out how your app flow works on your iPhone without writing any code. Just draw your screens on paper, take photos of them with your iPhone, and set up how the app should move from one screen to the next.
At each step, make sure it’s clear what the user needs to do next. Your clients will often be using apps in busy spaces or when they only have a little time. Go through the task several times yourself using your prototype and try to get a handful of other people to go through it. Avoid helping them through the task, just hand them the prototype and ask them to complete the task. If it’s not clear how they should proceed, it’s much easier to make a change at this stage than after programming has begun.
The app should guide users through the task in case they aren’t fully paying attention or get interrupted in the middle of the task.
Repeat this flow for each of the tasks, if you have more than one. Then do one more flow: from when the user opens up the app to when they choose which task to accomplish. In the bank app, it might make sense to default to showing their current balances with a button to show the recent transactions for each account. When they’re looking at an account, maybe they could choose to pay a bill from that account on that screen. Or maybe you’ll have a “Pay Bill” button right on the first screen. Think about what’s right for your users, what they’ll want to do often, and what else might be on their mind.
Don’t worry too much about the technical functionality at this point, other than checking whether certain steps are possible. iOS apps have some surprising limitations that you might not be familiar with. Other than feasibility, leave cutting down features due to time or budget until later. You may be surprised to find out that something that you thought was complex is actually easy to do and something that seems very simple will take several weeks of effort.
At this point, you should really understand what you need from this app and how the experience will work for the user. Now that you know what kind of app you need, it’s time to think about choosing a developer. Unless you’re already working with a developer, in which case it’s time to figure out if they’re the right person for the job. Next time we’ll cover finding and choosing an app developer. If you have any questions that you want to be sure that I cover, contact me.