Making a Paper Prototype - Paper Prototyping: The Fast and Easy Way to Define and Refine User Interfaces - page 71

One of the product team members (designated ahead of time as the "Help System") gives a terse
answer. The Help System should resist the temptation to answer questions that users haven't asked
yet—wait and see whether the short answer solves the problem. If the users are still confused, they
can ask another question and the Help System will provide a bit more detail, and so on.
The purpose of incredibly intelligent help is to find the piece of information that makes the
lightbulb go on in the user's head.
The purpose of incredibly intelligent help is to find the piece of information that makes the lightbulb go
on in the user's head—sometimes users only need a clue or two to get them back on track, not a long
explanation. Write down the questions users ask and the explanations given. After the test, see
whether the information users needed can be incorporated directly into the interface (thus avoiding the
question in the first place), or if that is not practical then it should be included in the help or
documentation.
Human Actors
Sometimes you may want to include humans in your paper prototype—as humans! For example, users
might call an 800 number or initiate an Internet chat with an online customer service rep. To simulate
this interaction, designate a member of the development team to play this role. (I don't recommend
having users call the real customer support number unless you're willing to waste time on hold.) The
catch is that this person shouldn't look at the interface during the conversation because in real life they
wouldn't be able to see it.
One of the advantages of using human actors is that user questions emerge in a natural way, and you
can determine the information required to answer them. As with incredibly intelligent help, the team
should try to incorporate this information right into the interface.
Wizard of Oz Testing
Paper prototyping is similar in spirit to so-called Wizard of Oz testing. In essence, Wizard of Oz means
any testing setup in which a human being acts as an intermediary between user and machine. It's often
used to conduct testing with users before the underlying technology is developed. As the name implies,
a human (often, although not necessarily, hidden) performs manipulations to make it appear as though
something high-tech is happening. For example, several years ago I participated in a study to find out
how people would give commands and dictation to a voice recognition system while editing documents.
The users were not allowed to touch the computer but rather had to give all their commands orally to an
experimenter sitting next to them who would then perform them literally. We got some interesting
insights from these tests—for example, when scrolling up a page, the command "back up" actually
means to go down the page!
A variation of the Wizard of Oz technique can be useful for paper prototyping. In rare cases, it's
necessary to show the user something on a computer that is too difficult to simulate with paper (such
as a very complicated graph) or that relies on inputs that can't be known ahead of time (such as live
data). To do this, an expert sits at a computer in the same room as the users and paper prototype and
enters the users' inputs from the paper prototype to show what the resulting output would be. The user
still interacts exclusively with the paper prototype, but they see the results of their actions on the
computer screen.
I have used this technique only rarely in paper prototyping. Because the tasks are created before the
paper prototype is developed, there is usually a finite and predictable set of results that users might see
(even when you account for likely mistakes), and thus it's possible to prepare them ahead of time. But
this technique may be useful for sophisticated tools where a more intuitive interface is being added on
top of a hard-to-use "expert-only" system, for example, one that previously relied on command line
entry.
Documentation, Help, and Training
If you're working on documentation, help, or training for an interface, testing a paper prototype will yield
useful inputs to your process of deciding what really needs to be covered, and to what level of detail. In