 Word. (In a usability test, this component
would be placed on top of a prototype of the Word
application rather than being shown by itself.)
- Each tab is on a separate piece of paper so it can be
moved to the front if the user selects it.
- The drop-down list for paper size is written on a
separate piece of paper and is shown if the user
touches the drop-down arrow.
- The radio button is simulated using removable tape.
- The preview components (shown in red for purposes of
this illustration) are tacked on with restickable glue
so they can be changed if the user selects Landscape.
(See Resources for more
information on where to get removable tape and restickable glue.)
Figure 2. The shopping cart page from an e-commerce site
Figure 2 shows how removable tape allows users to place any
combination of items in the shopping cart. The
computer can update the shipping cost and total
accordingly by wiping them off the transparency with a damp
paper towel and rewriting them. (It's not considered cheating
for the computer to use a calculator!)
How good should the prototype be?
You can use screen shots of an existing design if you happen
to have them, but it's also fine to hand-sketch them,
especially when you're in the early stages of design. And
as Figure 3 shows, sometimes hand-drawn elements are actually
more readable than screen shots that use a dark background color.
Figure 3. Hand-drawn versions of browser buttons compared to a grayscale screen shot
You can also mix and match screen shots and hand-drawn
components. The prototype only needs to be good enough for
you to get answers to the questions you're most concerned
about. Thus, most paper prototypes don't need:
- Straight lines or typed text. If the user can't
read something, it's OK to tell them what it says.
(But if the user doesn't understand a term, don't explain
it -- change it.)
- Images or icons. Use words instead. For example,
for the company logo, you can just draw a box around the
words "company logo. If images are part of the
content (a product catalog, for example), you can paste
them into your prototype using restickable glue, which
allows you to rearrange the page later.
- Color. As the saying goes, You can put
earrings on a pig, but it's still a pig. Color
can't save an inherently flawed design -- do your
initial testing with grayscale printouts of screen
shots, or sketches using any dark-colored marker. Color
can be added later once you're sure you aren't creating
- Consistent sizing of components. Unless you've
got a small or densely-packed display, don't worry about
adhering exactly to a grid. It's OK if components are of
varying sizes. For example, perhaps your menu bar and
icons came from a screen shot and are relatively small
compared to the hand-drawn parts of the screen. You can
clarify by saying things like This is all one
window if the user seems confused.
It's fine if the prototype looks a bit messy. Very often,
the first usability test will show you problems you'd never
anticipated, and then you'll want to make changes. Don't
spend time making the prototype look neat before you test
it -- if it's legible, it's good enough.
(For those of you who are thinking, But I can easily
mock up something that looks nice, see the
What paper prototyping is (and isn't) good for
Paper prototyping is especially useful for gathering data
about the following kinds of problems:
- Concepts and terminology. Do the target users
understand the terms you've chosen? Are there key
concepts they gloss over or misconstrue? (I've seen
these types of usability issues in virtually every
interface I've ever tested.)
- Navigation / workflow. If there's a process or
sequence of steps, does it match what users expect? Do
they have to keep flipping back and forth between screens?
Does the interface ask for inputs that users don't have,
or don't want to enter?
- Content. Does the interface provide the right
information for users to make decisions? Does it have
extra information that they don't need, or that annoys
- Page layout. Although your scribbled screens
may not be pretty, y