From paper, to picture, to app

Posted by Michael Dales on 2010-08-14 12:15:58

You might be tempted to think that designing applications for mobile platforms like the iPhone is a lot simpler than designing for the desktop or the web. You have less space to do anything, your UI is necessarily simpler, there's fundamentally less you can do. So that's less stuff, less code, less work - right? Not quite.

These very constraints mean you need to think a lot more about how you present things to the user, and how to guide them through what you want them to do. Your app moves from being one hub screen, where most operations are, to a flow of operations. Look at that menu bar on your application - it's a fantastic way to present a myriad of wonders to the user - but that's taken away from you on the phone. You have to plan your approaches and tasks on desktop apps of course, but on a mobile platform that's so much more important. So I thought I'd jot a few notes about how I tackle this process.

Step 1 - Putting pen to paper

The first stage is to work out roughly what you want your app to do, and therefore its high level feature set. With PlaceWhisper that's to let people create and find Whispers, to create trails, and so on. Now I've got that in my head, I now decide what are the common tasks that people are going to need to do - and how they should be able to achieve them. What I'm trying to do here is find a storyboard for each task, from starting point to completion. Once those tasks are decided, I plot out how the user is going to get through my application for each task, and what screens I need to achieve them.

The above image shows all the paths through PlaceWhisper's initial UI. Each blob of text represents a screen and the information on that screen, and the arrows represent the paths between them. I came up with this flow by considering what tasks the user needed to achieve, and how they could get there. That picture is not the first cut of that diagram, and you can see there's a reasonable amount of scribbling corrections still. I do this stage off computer, as I want the freedom to scribble lots, start over, erase easily, and I find pen and paper is still the best way to achieve this.

Step 2 - Mocking up each screen

The first stage is still just a proposal - although I've notionally designed the paths through my application here, I still don't start coding the UI yet. Now I've got my rough usage flow, I want to be sure that I've got it right, and I can actually achieve the tasks I think I can. The next step is to actually plot out the stages for each major task in detail, to be sure I understand on which screen things happen.

For this I use Balsamiq to build a screen by screen flow of each task. The diagram shown in the screen shot above represents all the screens needed for a user to complete a particular task, from start to finish, going left to right, and the little swooping arrow is my way to indicate where the user taps to move on. I have one of these detailed flow diagrams for each major task. The above task is quite linear; but others have branches in them, and some don't. But overall they should be quite simple, as your user is after something that is easy to use. If the diagram is too complex to easily represent like this, you might want to reconsider the flow.

Each screen is numbered, and that number relates back to my hand drawn diagram - each screen in the paper flow diagram has a number, and if my detailed flow in Balsamiq makes me realise I need a new screen, I go back to the paper version and re-iterate. It might mean I need a new screen, or it might mean I need to tweak an existing one - most of my flows reuse one or two screens from other flows.

Step 3 - Time to implement

The key here is both documents - the pen-based version and the Balsamiq version - work together and leave me with a fairly solid understanding of how the application will flow in actual use. Only now that I've worked out all the user interface flows do I set to implement the user interface. The enumeration of the screen means I have a list of all I need to implement. If during implementation I discover I've made a mistake, then it's back to paper and I re-iterate again - nothing is perfect, and until you have the final product in your hand you're never 100% sure what you'll need. But the approach above helps reduce the time spent re-iterating in code, which is time consuming, whereas the earlier in the process I re-iterate the cheaper it is.

This three stage process I find really helps with development of applications for platforms like the iPhone, where more than ever it's imperative that your user can get things done quickly and easily, without having to search through forever for things. The process itself doesn't stop you creating terrible user interfaces, but if you're aware that you're trying to reduce the difficulty of achieving a particular set of tasks, it exposes any user flow issues early, and I found it's really helped me on a number of occasions now.