Quantcast

Bruce McCarthy is Founder and Chief Product Person at UpUp Labs, where he and his team are at work on Reqqs - the smart roadmap tool for product people.

« Eating my own dog food | Main
Thursday
May042006

Paper prototyping

My first planned experience with user-driven design was at a seminar taught by Jared Spool of User Interface Engineering. The inimitable Jared had music blaring from the Squirrel Nut Zippers and spent about 3 hours explaining to us in his very animated way the benefits of paper prototyping.

Jared said that no matter how talented your team is, your first iteration of a design can only be a best guess at what will work for the users. You might get it 50% right on the first try.

Well, as  a newly-commissioned software product manager, I was all ears. The solution, Jared said, was to test the product before you build it. How? By simulating the product in a "paper prototype."

Paper prototyping has three main principles:

  1. Invest the least amount of energy possible in your prototype
  2. Put your prototype in front of real users
  3. Give them a realistic task and (this is key) don't help them complete it

The most expensive and time-consuming way to design something is to do the design, ship the product, and then start getting feedback. Many companies do this because they don't understand the design process. They figure if they hire good designers, they'll get good design in the first try, right?

If you assume instead that your first attempt at a product design will fall short, you'll want to invest as little time in version 1 as you can so you can get it into the hands of users quickly and then redesign it to incorporate feedback. The simplest, quickest way to simulate a product with a graphical interface is to draw it on paper.

Not only does a paper version of a screen take just a few minutes to draw (instead of hours of coding, followed by hours of QA), but because it only takes a few minutes to draw, you're not afraid to crumple it up and try again. It's painless to move a button from the top of the screen to the bottom if all you have to do is draw it.

If you've ever asked a developer if you can make just one more tiny little cosmetic change to a product late in the development cycle, you'll appreciate how much easier it is to change things before you've committed anything to code.

Hours instead of releases

This low-tech approach allows for quick iterations between feedback sessions that very rapidly improve your design -- sometimes over the course of hours. And here is where real-world users come in. It's a sad fact that most of the people working on your product (or selling it, or marketing it or running your company) won't ever use it. This means they are not capable of giving you real-world feedback. In order for each of your many design iterations to be better than the last in terms of its ability to serve real customers, the feedback you get must be from real users.

You've got to schedule a series of people who would really use your product to come in and review your design. Then you schedule time in between each appointment for your team to incorporate their feedback into a new paper design (moving buttons, swapping the order of screens, adding helpful hints, etc.) for the next user. With this approach, your design will get closer to the ideal with every iteration. Design. Test. Fix. Test. Fix. Test. Fix. Etc. The more iterations you have time for, the better the design.

Force them to use it

How you do the testing in each iteration is as important as when (before the product is created) and with whom (real users). It's not useful to put the screens in front of people and ask their opinion. Most users will respond to the esthetics and whether you seem to have all the features they expect. To get at whether the product really works for them, you have to force them to use it -- and you have to let them fail at using it. The way you do that is to develop use cases and then ask test subjects to walk through them.

Briefly, a use case is a description of a real-world set of tasks leading to a goal. If your product were bn.com, one use case might be a college student ordering college textbooks. Your use case should tell them they are a college student (which hopefully they really are), they want to buy their college textbooks, and they've been told by the school that the books are available from bn.com. You give them a dummy credit card number and let them loose on your design.

You show them your paper mockup of the home page and ask them to use their finger as the mouse and point to what they want to click on. Whatever link they follow, you provide the next (paper) page. If they want to type something in, you have them write it down. If the content of the page is dynamic (e.g., search results), you have at the ready small scraps of paper that you can assemble on the fly. And there's also no rule that says you can't draw something fresh right on the spot, if the user does something unexpected.

Helping is bad

At some point in this exercise, your test user will inevitably get stuck. They will fail to locate something you thought was obvious, they'll think they're done when they're not, or they'll just throw up their hands with no idea how to proceed. This is where you learn something, so pay close attention -- and don't help!

For the most part, people like to help. But the goal here is not to have them reach the end of the task, it is to see where they fail. Ask the user to think out loud as they walk through the site, to tell you what they are thinking and why they are doing each thing they are doing while they do it, but don't respond if they ask you questions. Find the first point of failure, make sure you understand what caused the problem, fix it, and test it again to find the next point of failure. Keep doing this until there are no more points of failure and you will have a usable design.

What have you forgotten?

Jared's seminar gave me a dramatic lesson in the value of this design approach. After the lecture, he broke us into teams and held a contest. Each team was to design a paper prototype of a touch-screen kiosk for ordering at Taco Bell. We were given paper, pencils, scissors, tape, and glue sticks, along with a list of menu items and prices. At the end, one member of each team was to become the test subject for another team. The team whose test subject completed their order the fastest would win.

I'd been doing different sorts of design for years, so I thought I could blow away the other teams. My team and I set to work and produced a design we were quite proud of. We even took the time to write out a bunch of item names and prices on strips of tape, which we could choose among to add to the paper "screen" during use to simulate a display of the order in progress.

Our test user moved through our paper screens with ease. She even remarked how much she liked our continuously updated order display. She completed all the steps, and then it happened. The moment of learning. She'd entered everything -- and we were ahead of all the other teams -- but we had forgotten the button for placing the order!

The rules said that if your user got stuck anywhere in the process, you had to fix your prototype and the user had to start over again at the beginning! So, we scrambled to add the missing button and (agonizingly) had our user start again. She breezed through the screens a second time, submitted her order successfully, and we were still the first team to finish.

Iterate or die 

We won, but I learned there is absolutely no substitute for real user testing. Get real users, make them use the design, and watch where they fail. Fix the design and test it again.

User-driven design is iterative design. It might not seem as inspired as something your genius of a designer comes up with after pulling an all-nighter, but the magic of that design will fall flat if no one can find the "place my order now" button. 

If you have any thoughts you'd like to share on this post -- or anything else about user-driven design -- I invite you to post your comments here or in the User>Driven Forum.

Reader Comments (2)

Interaction-Design.org has an excellent summary of paper prototyping (which they call "mock-ups" in their comprehensive and sensible encyclopedia of interaction design.

http://www.interaction-design.org/encyclopedia/mock-ups.html
November 19, 2006 | Registered CommenterBruce McCarthy

[...]To develop a flawless product, for an individual it’s very essential to have the overall idea about the product and for a team to deliver a truly usable application[...]

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>