g, 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, you'll still get a sense of whether
users can find the information they need. Do you have
the fields in the order that users expect? Is the amount
of information overwhelming, not enough, or about right?
- Functionality. You may discover missing
functionality that users need, or functionality you'd
planned but users don't care about.
On the other hand, paper prototyping isn't ideal if your
biggest questions pertain to:
- Technical feasibility. Paper prototypes don't
demonstrate technical capability. It's possible to create
a paper prototype that can't actually be implemented. To
avoid this, I recommend that there always be at least one
person involved who understands the technical constraints.
- Download time or other response time. Because a
person simulates the behavior of the computer, the
response time is artificial.
- Scrolling. I've seen some interesting and subtle
problems with Web page designs that discourage the user
from scrolling either down the page or back up to the top.
I wouldn't have found these problems with a paper prototype
- Colors and fonts. If you really need to see how
something looks on a computer screen, paper prototyping
can't show you that. It's a good idea to involve the graphic
designer in the paper prototype tests because he may find
issues that influence the visual aspects of the final design.
Some development teams use paper prototypes in the early stages
to smoke out the show-stoppers, and then do a couple of
additional usability tests later with the real interface just to
look for any additional surprises.
Key benefits for designers and developers
If you design and/or implement user interfaces, paper prototyping
can provide several benefits:
- Test your design with users before you code
Paper prototypes are ideal for finding out whether
you're on the right track, before you write even a line
of code. Sometimes the things you learn can have a
significant impact on the interface or even the
underlying architecture. For example, in testing a
prototype of a travel Web site, we learned