 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 cancelled. This was disruptive
to the development teams, which were relying on the tests to
answer important questions about the interface. But I've
never had to abort a usability test due to a problem with a
paper prototype. I've even done paper prototyping during a
Paper prototypes give you complete control over how the
interface behaves -- this is useful for short-notice demos as
well as usability tests. Paper prototypes don't use databases,
networks, servers, or any other form of technology, which
eliminates most of the things that can go wrong. You don't have
to worry about someone putting a change up on the development
server that breaks the very thing you're trying to test (and
this also means that development doesn't have to come to a
complete stop every time you want to do a usability test).
You may be thinking, "But this is my application. I'm the one
writing the code." Yes, but until you're well into the
debugging stage, your code (or code written by others that
yours depends on) may not be stable enough to allow users to
do meaningful work without crashing. Bugs happen -- there's a
big difference between the pleasant fantasy of &147;These ones
and zeros obey my every whim and the painful reality of
I'd be better off if I hadn't come in today. I
hope I'm not the only software developer who's ever said that!
Even people who recognize the benefits of paper prototyping
may have some concerns about the technique. The questions I
commonly hear fall into three categories: validity,
professionalism, and resources.
- Validity ("Does it find real problems?")
I'm often asked whether paper prototyping might have bad
side effects, either in terms of missing important problems
or finding false ones. The short answer is that paper
prototyping does find most of the same problems that you'd
find by testing the real thing.
To my knowledge, there is only one published scientific
study (see Resources) of the
validity of paper prototyping. Three researchers at
Verizon (formerly GTE Labs) compared the type and
number of prob