Database Reference
In-Depth Information
Facilitating a Paper Prototype Test
In a paper prototype test, the facilitator's responsibilities are essentially the same as in any other kind of
usability test, but there are a few differences due to the medium of paper.
Have them show, not tell. In the process of thinking aloud, users sometimes slip into verbal
explanations, such as, "At this point I'd start over." (People do this when testing on a computer too,
but it happens even more often in paper prototyping because the Computer is human.) Ask the
users to demonstrate how they'd do that. Avoid letting the users simply talk through the
task—remind them to show you. Sometimes it's okay to relax this a bit after you've established a
common vocabulary. For example, if the users demonstrate that "start over" means "click Back
until we get to the home page," you don't necessarily have to make them traverse all the interim
pages each time if this method would work. But when in doubt, have them explicitly show you.
Clarify that it's okay to write on the prototype. Sometimes users are reluctant to write on the
prototype, and you may need to reiterate that you really do want them to write on the removable
tape, transparency, or prototype itself. (An occasional user will go too far and put Xs on buttons to
indicate clicking; gently remind them that writing only replaces typing, not clicking.) Whenever users
ask if they can write something on the prototype besides data, I say yes because chances are it's
something interesting, like crossing out information they don't want to see.
Watch for Computer mistakes. Sometimes the Computer will make a mistake, either a simple
one, such as not moving a highlight, or a major one, such as showing the wrong screen. The
facilitator should try to keep tabs on the Computer's logic and note any problems. Sometimes a
simple, "Is that right?" or "Didn't we change that?" is sufficient to clue the Computer in to the
problem.
Handle valid (but unprepared-for) user actions. Users may do something entirely reasonable
that you simply haven't prepared for, such as typing a term you didn't expect into the search
engine. One tactic is to confirm that their way would have worked and then ask them to please find
another. Or perhaps you can quickly sketch a screen or modify one of the screens you did prepare.
For example, if you have a page of search results that contains more items than what the user's
search would yield, maybe you can cross off items to approximate the list that the user would see.
Take a break if the paper prototype crashes. Every once in a while, the users manage to end up
in a state that didn't occur to the development team even in their wildest dreams (or nightmares). I
can tell when this happens because the Computer will look at the other designers and ask, "What
do we do when that happens?" This is valuable because it reveals a pitfall that the code will need
to avoid. If this happens, take a short break so that the team can step out into the hall and confer.
You may need to join them to hear how they'd like to proceed. Be sure to reassure the users that
they've just done a very good thing in finding this problem—if the users are relaxed enough for
humor to be appropriate, I'll tell them that the paper prototype has "crashed" and we need to go
reboot it.
Search WWH ::




Custom Search