The iKilltrees, our paper-prototype of an iPhone app for user testing.
As part of our application development process, we’re always trying to prove that we’ve made some bad assumptions. The best way to do this is to get someone to use your app who hasn’t been involved in the design and development process.
We’re working on an iPhone application (for a client) that is designed for people who have recently been diagnosed with breast cancer. The idea is to help them navigate the medical jargon, allow them to store diagnosis info, and send them news and research related to their diagnosis.
During development, we’ve been grabbing internal folks to validate interface elements, test terminology, and find bad assumptions.
We will also be doing user testing on actual iPhones with breast cancer survivors. But during initial development we’ve been testing internally on what we affectionately call the iKilltrees (shown above). This paper prototype of the app is not pretty… but it’s helped us find several usability issues that could have made their way into actual code.
Testing on paper isn’t perfect either. We’ve found we need to be careful about our assumptions here, too. It isn’t always clear whether we’ve found issues with the app’s usability, or simply the iKilltrees‘s usability.
The iPhone platform has fairly strict user interface guidelines that make many GUI widgets standard. Examples include the “slot machine”-like picker, the tab bar, and search inputs. While you can approximate these interface elements on paper, they won’t work anything like a real app.
Similarly, most iPhone gestures can’t be mimicked with paper. A tap is pretty straightforward, but swipes, pinches, flicks, etc. are tough to replicate.
Tips for paper prototyping success
- Develop tasks with clear success criteria. Don’t just hand the iKilltrees to someone in your office and ask them what they think. That’s not user testing. Give them tasks that reflect expected user needs, and make sure you have explicit definitions of what counts as “success” for each task. Ideally, you counterbalance task order to remove potential bias.
- Get your users to give you the “play by play.” Ask testing participants to explain what they are expecting, what gesture they would use if they could, and whether the piece of paper you hand them in response to their action meets their expectations, and why or why not.
- Practice first. Before you attempt to “be the CPU,” run through your experimental method with someone else to get to know the stack of papers. Tabs on the edges of pages help, too. Delays caused by the experimenter shuffling papers around can throw off your results as the user loses focus between screens.
- Record the sessions. We used an iPhone 4 to record HD video of sessions, which was really useful to refer back to later, and also helped us convey to designers and developers the exact nature of usability issues.
With mobile apps, the usability stakes are incredibly high. All of the problems of 1995 have been magnified: crappy connectivity, tiny screen real estate, and under-powered processors.
Designers have to rely much more on icons, short navigation labels, and the user’s ability to learn.
While paper-based testing shouldn’t be the only testing you do, it’s the cheapest insurance you’ll ever get against costly code refactoring.
