I've authored three Windows Phone 7 mobile apps. This is not a huge number I know but I would like to share how I think about mobile app design. The workflow below is not limited to any particular platform and can be applied to Windows Phone, iOS, Android development or at a push Blackberry ;)

Step 1: Stop and Think

It's so easy to break open an IDE and start hacking together your app, especially if you're using great developer tools such as Visual Studio and Expression Blend. Shutdown your computer, grab a cup of coffee, sit down and think.

thinking does equal working

As a developer I have to force myself to do this, which is why shutting down your computer is a necessity!

Think about why you are bothering to build an app. Think about who is going to use your app. Think about when your app will be used. Contrary to some management outlooks you may have experienced, thinking does equal working.

Step 2: Choose Your Features

Take some pens and Post-it notes (you still have your computer turned off right?).

Go nuts, write down any cool feature you can think of. Write each idea on a separate Post-it. Don't worry about the detail at this point, a sentence or two is fine, in fact that's why you should use Post-its as you can't fit too much on them. Don't worry about if they are good ideas as this point just get them written down.

If you can, and if it's appropriate, do this exercise in a group. If the group can have non-developers, business people or potential end-users then it's even better.

Once you think you've captured enough ideas it's time to prioritise them. You can use any prioritisation method you like, but an easy one is to stick the Post-its on the wall under three headings: Yes, Maybe, and No. Again don't spend too long on this, no final decisions are being made at this point, things in the Maybe column may make it into a future version of the app, or even a completely different app...

Step 3: Lose Your Features

So you've got a big list of awesome features in your Yes column. Now it's time to lose some of them.

don't be afraid to ditch what you initially thought was a kick-ass feature

If you are building an app version of your web site, you'll probably want to aim for feature parity. Initial thinking about apps was to provide a cut down version of your web site, perhaps with only a small subset of the features. This thinking is probably no longer valid: for an increasing number of people the Smartphone is the only computer device they have. If we do not provide feature parity then how are these people going to access your service? There are of course arguments to be made either way, you may have your app do a small subset of features in an app-experience and redirect to your mobile-friendly website for the other features (you do have a mobile friendly web site right?).

If your app is not going to be based on an existing website you don't have to worry about feature parity. In this case each feature in your Yes column should be scrutinised to see if it is essential to the person who will be using your app. This is the time to be super critical, don't be afraid to ditch what you initially thought was a kick-ass feature and move it to back to the maybe column.

One of your goals should be to get a working version of your app released as soon as possible so you can get feedback and decide what you add in version 2. This is another reason not to be too protective about the things you initially put in your Yes column.

Step 4: Prototyping and Sketching

So now you've decided on your must-have features. Keep your computer turned off for a while longer...

There are loads of prototyping tools such as SketchFlow and Balsamiq but for the ultimate in speedy, iterative and collaborative prototyping, paper and pen is hard to beat.

You can download and print off some templates such as this Windows Phone template or just start from scratch.

So now you're ready to start designing some screens on paper.

Stop.

Before you start designing individual screens, it's hugely important to think about the application flow. This is more than just what menu "buttons" will be where. It's more about thinking what your users are trying to accomplish, what's important to them, what do they care most about.

Start with a big sheet of paper, write "app opened" in the middle, then draw out the flow to other screens, menus, pop-ups, toast notifications, etc. Count how many interactions ("clicks") they will need to get to a core feature and redraw as required to optimise the flow.

Now it's time to sketch some mock-ups. Take some paper or large rectangular Post-its and start to sketch what the screens that make up your features will look like. Don't be afraid to draw multiple versions of the same screen and put them side-by-side for comparison. The idea is to iterate quickly, don't use a ruler to get perfectly straight lines, cross things out, scribble, redraw, whatever works for you. Make sure you keep referring to your application flow while doing this.

Step 5: Review and Refine

If you can, get someone who was not involved in the above steps and take them through the application flow and paper mock-ups. Getting a fresh pair of eyes can help highlight any gaps in your thinking. It's easy, even when dealing with paper prototypes, to become attached to your ideas. When you get some objective feedback on your ideas be open to areas where you may have gotten it wrong.

Conclusion

From here you can either turn on your computer and refine your prototypes further using a prototyping tool, or you can start to build. I would suggest that unless you're constrained legally or you need electronic signoff, etc. then it's more efficient to start building. Keep your paper prototypes and application flows up on the wall and refer to them during development.

Don't be afraid to change, challenge and evolve your design as you build. If you do decide to change things, always think of the application flow and what the user is trying to accomplish by using your app.

SHARE: