Usability Testing with a Paper Prototype - Paper Prototyping: The Fast and Easy Way to Define and Refine User Interfaces - page 164

Figure 9.4: Homer Simpson knew exactly what functionality he wanted in a car, but he was still a
lousy designer. (© Fox Twentieth Television.)
Homer: I want a horn here, here, and here. You can never find a horn when you're mad. And they
should all play 'La Cucaracha.'
Advisor: What about a separate soundproof bubble-dome for the kids with optional restraints and
muzzles?
Homer: Bullseye!
With that caveat, sometimes it is useful to ask users to mark features or content they're most interested
in or to cross off things they don't want. One Web site I tested used six tabs at the top for each of its
major content areas. At the end of the usability test, I gave users a pen and told them they had 10
votes to distribute across those six tabs to indicate the value they perceived in each. Although this
experiment was crude, there were some useful patterns, like the fact that one of the tabs contained
stuff that none of the users cared about. If you are interested in more information about ways to involve
users in the design process, you'll want to read other topics and papers about participatory design (see
the Reference section).
Making Changes between Tests
Hopefully, you'll be conducting a handful of tests with your paper prototype. You should allow yourself
some time between tests—say 2 or 3 hours—to make more substantial changes than what you were
able to do on the fly. (If the design is still in its infancy or many changes are expected, you might even
designate a day in the middle of your usability study for rethinking the design.) Rearranging screens,
simplifying a screen, adding an example—these kinds of changes often help considerably and aren't
difficult to do. Even when more substantial redesign is called for, it often doesn't take as long as the
initial design did because your brain has a better grasp of the problem.
Problems first, then answers. One method that works well for making changes efficiently is to
first list the issues on a whiteboard—everything that the observers saw during the test that
indicated a problem. (If you do this in the same room that you're testing in, remember to erase this
list before the next users arrive!) Then divide and conquer, just as you did to create the
prototype—people put their initials by the things they want to solve. With this approach it's possible
for a team to make fairly substantial changes to the paper prototype in an hour or so. If you're
doing this over lunch, order a couple of pizzas for the team and then you'll have plenty of help.
Include information in the interface. The interface is the first and often the best place to explain
things to the user. Always ask yourself whether a particular usability problem can be solved by
directly changing the interface rather than writing instructions somewhere else. Try to make the
easiest change first, which often means wording. For example, in testing a Web application for
teachers, we found that users were confused by what to do next. We solved this problem by
adding a sentence to the bottom of the page suggesting the next step. This worked so well that we
called these "magic sentences." (See Figure 9.5 .)