Database Reference
In-Depth Information
& drop and right mouse menus. There's
even a help system."
They are in
charge
"Remember that we're testing the
interface—we're not testing you. We'll end
promptly at 4:00, but if you need to stop or
take a break before then, just let me know.
Are you ready to start?"
Remind the users
that you're testing the
interface.
Confirm ending time
and that they can
stop or take a break
at any time.
Begin first task
"Okay, here's the first thing we'd like you to
do. Take a minute to read this and let me
know if it makes sense. If so, then
whenever you're ready please show us
what you would do first."
Hand users the first
task.
Clarify the task if it's
confusing.
If necessary, prompt
the users to begin
interacting with the
prototype.
How Users React
No doubt about it—paper prototyping feels weird for the first few minutes. Actually, so does any kind of
usability testing. From the users' perspective, it's like standing on the edge of the swimming pool,
worrying that the water's going to be cold. The key to getting users to relax is having them jump in the
pool and realize that the water's fine. Once they start interacting with the prototype, their brains become
engaged in the task and they focus less on the social nature of the setting. It's also easier for the
facilitator to reassure the users that they're providing value once they're doing something besides
staring at the interface. So the key to starting a test off on the right foot is to get the users "clicking" and
"typing" as soon as possible. (Exception: Sometimes it's interesting to start a task by asking users to
describe how they currently do it or how they'd expect to go about it to determine whether your interface
supports their approach. Just keep this discussion brief.)
It's amazing how quickly users get into the task and act in a realistic manner. In one test of a video
conferencing system, the task involved negotiating a business deal. We used photographs of a person
in various facial expressions to simulate the other end of the video connection, and users talked to the
pictures as if they were live people. Even with a human obviously manipulating the prototype, users
often say things like, "Hmm, the red light came on" or "Good, it worked," which indicate that they're
focusing on the interface as the entity they're interacting with, not the humans simulating its behavior.
I also make it a point to talk to users afterward and ask what they thought of the experience. I've found
that most people seem to understand and appreciate the reason why we're testing with paper.
Occasionally someone will comment that some aspect of the interface might have been clearer on a
screen. I'll simply acknowledge their statement (for example, "Yes, that table will be easier to read when
the columns line up") and thank the user again for his or her help. But I've never heard a user say that
the experience was silly or a waste of time, and I've heard plenty of positive feedback.
Search WWH ::




Custom Search