When to Use Paper - Paper Prototyping: The Fast and Easy Way to Define and Refine User Interfaces - page 249

Making Your Decision

The checklist in Table 14.1 summarizes the factors that this chapter has covered. (For a printable
version, see www.paperprototyping.com .) This checklist isn't a definitive decision-making tool that will
tell you whether you should use a paper prototype. Its goal is more modest—to ensure that you've
thought about the risks particular to conducting usability tests with your interface. Hopefully this
checklist will prevent your project from becoming a war story like the ones at the beginning of this
chapter.

Table 14.1: Checklist: Working Interface versus Paper Prototype

Working Interface Paper Prototype

People and
logistics

There are only a few
people working on the
design, perhaps 3 or 4 at
most.

The product team is larger.

Using a computer-based
prototyping tool would require a
learning curve before we were
proficient enough to prototype
what we envision.

The people directly
responsible for the design
are already proficient with
a computer-based tool like
VB, Dreamweaver, etc.

There are nonprogrammers on
the team whose input is
important, such as tech writers,
customer support reps, or
Marketing.

Everyone working on the
design has a technical
(i.e., programming)
background.

We aren't all in the same
geographic area and remote
testing isn't a good option—if
we're going to do usability
testing, someone has to travel.

The development team
and users are all located
within a reasonable
commuting distance, or
remote testing is a viable
option.

The recruiting firm charges us a
fee to reschedule users, or the
users are people we don't want
to inconvenience.

The users are readily
available. They won't be
upset if we have to
reschedule a test, and a
few rescheduling fees
won't break our budget.