Designing for Mobile Devices - Usage Scenarios and Paper Prototyping

Mobile application design and development presents different challenges to developers and designers of mobile systems. The aspect ratio and the smaller display compunded with hardware and software input mechanisms that differ a lot from traditional input mechanisms make designing for mobile devices very tricky.

Here are some aspects of traditional design that I have found extremely helpful in my work in mobile application design:

Usage Scenarios: Identify usage scenarios for the application in question. These can be written as essays that describe specific actors (users) engaged with the application to achieve some goal. There must be an end goal to each scenario, for eg. Ray successfully creates a new portfolio entry by adding the stock symbol into “stockr”. The example above is a goal that a particular usage scenario achieves. The usage scenario encompasses many pieces of functionality but culminates in one goal ie. Ray enters searches for a companies stock by company name, Ray selects the company out of the list of search results, Ray chooses the stock symbol for the company that he wants to enter into his portfolio. Here’s a more complete example scenario written in the form of an essay.

Paper Prototyping: While developing an application interface on the device it helps immensely to have paper prototypes or whiteboarded interface flows of the application based on user scenarios. I favour building paper prototypes on the specific devices themselves - this is possible in the case of smartphones but is a bit more problematic when dealing with CDT phones which are currently more prevalent

For Smartphones: Using a Notes/Scribble application for paper prototyping directly on the device (You can use the standard Notes on WinMobile, Sketcher or HeadsUp on PalmOS, MemoJot on Symbian and tkcPainter on Linux based smartphones) has helped me in understanding the aspect ratios and the physical boundaries of the device I am creating solutions for.  This might sound really basic at first and trivial (it is and thats the point…) but it aides designers in focusing on how best to work with the constraints at hand. When you add a lot of functions on the screen you can immideately see clutter and a non-intuitive experience emerge. It also helps to see how your users would hold the device while interacting with your application.

See the image below:

It was clear to me in the first pass that having the menu of options (the 0, 1, 2… are meant to show icons for a navigation menu for the application) would be non-intuitive and also quickly become somewhat of a strain on the hands when used in the left hand since the thumb has to move relatively further away each time for navigation. This led us to explore the possibility of having the menu of options on the left handside by default and provide a simple way for the user to switch the position of the navigation menu depending on their preference. Many more such options become obvious when you undertake this prototyping.

For Regular Phones: It helps to take life-size pictures of the device from the manufacturers website and make multiple copies of empty screens on which you can then paper-prototype. The idea is to be able to “hold” your paper prototypes and be able to go through them like you would a stack of cards (in the obvious flow that the usage scenario describes).

The physical flow of interaction can be mapped using these protypes and it allows for a much easier and more coherent conversation amongst developers and designers when you are deciding on which functionality to play in a particular iteration. Also, it provides everyone on the team an opportunity to poke holes at the physical interaction design for the application. The prototypes on the device also provide an opportunity to “feel” through the functionality and make improvements or drop unnecessary functions from the interface.

powered by performancing firefox