Usability Testing with a Paper Prototype - Paper Prototyping: The Fast and Easy Way to Define and Refine User Interfaces - page 158

How the "Computer" Behaves
For the most part, the Computer should think of himself or herself as a machine that can do only what
it's been programmed to do.
Accurately Reflect the Users' Inputs
The essence of any human-computer interface is that the machine takes input from the human, does
some processing, and produces some kind of output. For an interface to be usable, users need to
understand the cause-and-effect relationship between their inputs and the outputs, even if the
processing is a complete mystery. (I don't need to understand how my car's antilock brakes work. All I
need to know is that if I keep pressure on brake pedal—even when it makes that weird rattling
noise—the car will stop as quickly as it can.)
Although developers often focus on the processing—which is, after all, the part that has to be
coded—users deal mostly with the inputs and outputs, so it's important to have your prototype
represent them accurately. For example, if the user writes "hiking boots" into a search engine field, use
that piece of removable tape at the top of the search results page to make it say "Search results for:
hiking boots." If you try to rely on memory, they (or you) may forget exactly what they entered. Similarly,
if you show users a screen with different data than what they entered, they can get confused unless the
differences are minor and easily explained.
Wait for the Users
Avoid anticipating what the users will do. To speed things along, sometimes an overly helpful Computer
will set down the next screen (or more subtle, pick it up) before the users actually do anything to make
it appear. Resist this temptation unless you're absolutely certain what screen they want and how they
would have gotten there.
Avoid Conversation
Since, as the Computer, you're sitting across from the users and they know that you know how to use
the interface, sometimes users will direct questions to you. Don't answer them—it's the facilitator's job
to handle this. (If this feels awkward, you might say, "I'm sorry, but computers can't talk.") However,
there are some situations when it's appropriate for the Computer to say something:
To distinguish action from discussion. Sometimes users will point at the prototype while figuring
out what to do next. In this case, the Computer (or the facilitator) can ask, "Are you just discussing
or are you doing something?"
To clarify what the user would see. If the prototype is messy enough that users can't read it, or
there's something that's hard to represent with paper, it's okay to state what the user is looking at,
but not why. For example, the Computer can say things such as, "That button is gray," or, "These
are tabs." But beware the word because, which is a red flag that you've slipped into explanation.
For example, "That button is gray because you haven't selected a record yet." If you catch yourself
saying "because," stop talking.
To provide an oral error messages. Sooner or later, a user will take a wrong turn that you aren't
prepared for. It's fine if you need to make up an error message on the fly and simply tell the user
what it would say. Try to use the same content that the real system would—resist the temptation to
give them additional information that would not appear in the context of the error. (Also see the
discussion of "incredibly intelligent help" in Chapter 4 .)