lems found with a low-fidelity
(i.e., paper) prototype as compared to a working
prototype. They found that there was a significant
degree of overlap between the problems found using the
two different methods. Although the working prototypes
did uncover a few more problems, they also took
significantly longer to develop than the
low-fidelity ones -- weeks instead of days. These
results indicate that there are diminishing returns
from taking the additional time to develop a polished prototype.
My own practical experience backs this up. I have
conducted several hundred usability tests of software
and Web sites, including more than 100 using paper
prototypes. With only a few exceptions, I find the same
kinds of problems with both.
- Professionalism ("What will others think of it ... and us?")
The thought of showing an unfinished -- or even flawed
-- design to outsiders makes some developers uncomfortable.
Many of us are perfectionists by nature and/or training,
and our jobs reward this trait. It's natural to be concerned
that others will perceive our work as incomplete or sloppy.
Fortunately, that's not what happens. Users (and coworkers)
respond positively to a paper prototype, provided that
they've been briefed appropriately. When participants
arrive for a usability test, I explain that we know the
design has some rough edges (sometimes literally!) but
that we want to get their feedback before we've invested
a lot of effort to build the wrong thing. I've found that
users understand this, and I've never heard a user make
a disparaging remark about a paper prototype. On the
contrary -- users appreciate knowing that their input
is being requested while there's still time to incorporate it.
- Development resources ("Do we really have time to do this? Is it just extra work?")
Those who have never done paper prototyping (or even
usability testing) often overestimate the amount of time it
will take. If you're already doing usability testing and
only the paper prototype part is new, estimate no more
than 1-2 days for prototype creation if you're working mostly
from screen shots, and up to a week if it's a new interface
or a complete redesign. Any more than a week and you're
spending too much time polishing the design before getting
user feedback. (The other activities associated with planning,
preparing, and conducting a handful of usability tests typically
take on the order of a week of hands-on time, spread out over
Sometimes paper prototyping will uncover planned functionality
that doesn't need to be implemented. For example, I once tested
a paper prototype of a distance learning Web application. The
original design called for users to have avatars to navigate the
virtual classroom, raise their virtual hands, etc. In prototype
testing, we quickly learned that all this virtual 3D stuff got
in the way of the real purpose of the application, which was
to enable large companies to provide training to geographically
dispersed employees. The designers realized that they were
jeopardizing their whole product concept by trying to make the
application feel like a video game. They dropped the 3D
functionality, which actually shortened their development
schedule. This was five years ago, and the product is still
around, sans 3D.
It's normal for interfaces to undergo substantial changes between
the initial concept and the actual release. No one enjoys writing
code that ends up having to be overhauled or scrapped. Paper
prototyping lets you find significant problems early in the
design process, so you can experiment to find the best solution
before investing the effort to implement it.
problem identification using both low- and high-fidelity
prototypes by Robert Virzi, Jeff Sokolov, and
Demetrios Karis is available from the ACM Digital Library.
(You must be an ACM member or pay a US$10 fee to download
Read the author's list of useful
supplies for paper prototyping, including hard-to-find
items like removable tape. Includes links to specific items on
two office supply Web sites.
Practical Guide to Usability Testing
by Joe Dumas and Ginny Red