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

People and Logistics
First let's consider the people—who's on your development team, where they're located in relation to
users, and how difficult your target user population is to (re) schedule.
Composition of Development Team
Paper prototyping seems to work well when the product team is large and/or interdisciplinary. Many
people who have useful ideas lack the technical ability to implement them, such as customer support
reps, Marketing, QA, and writers. With a paper prototype there is no technical barrier to prevent ideas
from coming from a variety of sources. Although it's possible for the designer to go to these people to
get their input, it may be more efficient to gather the people together and let them contribute their
expertise directly to the prototype. (Naturally, you'll want to take a look at the individuals who make up
your team to decide whether this is a good thing or not!)
The converse is somewhat true—if the development team is small and very proficient with their tools,
the benefits from using paper may not be as great. I've seen teams with two or three developers who
could make substantial changes fairly rapidly. At one company, after each usability test the room would
immediately empty as the developers rushed back to their desks to make changes before the next test.
(Unfortunately, this was the same company featured in the " Ready, Fire, Aim " war story, who also
proved their capability to make substantial mistakes on short notice!)
Location of Development Team and Users
Usability tests involve a whole cast of characters—users, the facilitator, the Computer, and observers.
In a paper prototype test, you have to get the whole cast together in the same room. Unless everyone
is already at one location, it can be inconvenient to reschedule a usability test. I've known cases where
customers traveled considerable distances to participate in usability tests, like a guy who flew across
the United States for a 2-hour usability test and went back home the same day. It's also not unusual for
development team members from another city to come in for a couple days in to observe usability tests.
The more people who assemble for the test, the farther away they're coming from, and the more
influential they are, the more painful it is when something forces you to reschedule. But if you're
developing an intranet and your users are right down the hall, postponing a usability test is no big deal.
Remote Usability Testing
It's difficult to usability test a paper prototype unless the Computer and users are in the same room.
However, some of my colleagues have experimented with ways to test prototypes remotely, by
preparing materials in either paper or electronic form and then walking through them with the user on
the phone. See the From the Field box on p. 324 for examples.
From the Field: Remote Usability Testing
"I once did paper prototype testing over the telephone with excellent results by sending the
participants a paper prototype booklet that I asked them to open only after our phone
conversation began. The booklet supported the use scenario, so the participant could say 'Now
I'd press the OK button,' and I could say, 'All right, now you see the screen shown on page D.' I
was surprised at how well it actually worked, and it enabled us to include many more participants
at next to no cost. (Note that the application we were testing was quite simple; this technique
might become unwieldy with an interface containing more screens.)"
Betsy Comstock, PolyCom
"Rather than sending the papers, I created a set of prototype images and stored them on a Web
server. Each image URL is encrypted so the user won't be able to guess what the next image
would be by tweaking the URL on his/her browser. The users were connected via ICQ for text
communication and we even managed to connect to a participant in Russia! Every time I asked