ou'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 that users
insisted on seeing some information that had to come from
the airlines' databases. On one hand, this was bad news
because it was technically difficult to get this
information. On the other hand, the team learned about
this need in time to address it in the first release, or
else the site would have failed.
- Make fast changes
With a paper prototype, you can revise the interface
very quickly, even during a usability test. If a term is
confusing, you can cross it out and try a different one.
You can add an example next to a confusing edit field or
a sentence of explanation. Simple changes like these can
solve many usability problems. Even when you find the need
for more substantial changes, you can often make them in a
matter of hours. One team completely redesigned an
e-commerce interface in one evening after learning from
the first two tests that it had some fundamental flaws.
The next day's tests confirmed that they'd fixed the
- Find out what marketing really wants
It's frustrating to implement something that wasn't
quite what your marketing department had in mind. I call
this the Bud Light problem after a funny series
of Budweiser commercials in which someone says, Bring
me a light! and is then presented with a lamp,
flaming torch, fireworks -- anything but a light beer. It's
not so funny when you've spent days or months developing the
wrong thing. Interface specs -- even with screen shots --
don't solve the Bud Light problem because they don't show
the behavior of the system, and they also don't show you
what people (especially non-technical people) expect the
interface to do. But when you put a paper prototype in
front of someone and watch them use it, you'll quickly
discover whether it meets their expectations. Invite
marketing to your prototyping sessions, and make sure
they attend the usability tests.
- Eliminate technology variables from the usability testing
In eight years of usability testing, I've collected a
number of war stories where technical glitches
caused tests to be postponed or ca