Database Reference
In-Depth Information
The Play-by-Play
Although in theory the observers see and hear everything that the facilitator does, there are some
reasons why this may not be true in practice. The facilitator usually has the best vantage point because
he or she sits close to the users and the prototype. People who are sitting farther away or in another
room may not be able to read the error message that just came up or see which menu option the users
clicked on. Observers who are writing notes may have missed what the users just did. Some users
speak softly, and observers can't hear them.
So one thing the sportscaster does is what I call the play-by-play—verbally reinforcing any user action
that might not have been obvious or visible to observers. For example, if the user writes something in
the search field, you'd say, "So you typed 'return policy' in there." And then when the Computer hastily
scrawls a "No matches found" error on a scrap of paper, you'd say, "Hmm, 'no matches found.' What
does that mean to you?" Obviously, you don't want to mindlessly parrot every detail—the sportscaster
uses this tactic judiciously, when there's a good chance that observers missed some information that's
important to understanding the users' behavior or context. It can alter the user's behavior if you call
attention to something the user hadn't noticed, so it's best to do the play-by-play for those things you're
pretty sure the user is already focusing on.
Here are some other sportscaster tricks I've learned over the years.
Encourage Questions, But Don't Answer Them
One of the ironies of the test facilitation is that you want to encourage the users to ask questions, but
most of the time you don't want to answer them, at least not right away. This can feel awkward, so you
might want to prepare some responses ahead of time. For example, if a user asks you the meaning of
a term, you might say something like, "That's a really great question but forgive me if I don't answer it
yet—maybe you'll discover the answer as you go." Other tactics are to direct users' attention back to
the task ("Why is that important?") or to plead ignorance ("Hmm, I'm not sure.") But do acknowledge
the users' questions in some manner, or they may stop asking.
Write down all the questions that users ask. Questions often indicate something important about the
functionality or usability of the interface. At the end of the test, if the users didn't find the answer to
something they were truly curious about, you can enlighten them. ("Remember that undo function you
wanted? It was hidden over here.")
Use the Users' Vocabulary
The words you use when talking to users can influence their behavior. Avoid the temptation to use the
"right" terms—when possible use the same vocabulary that the users have already used. Otherwise,
you might inadvertently provide a clue about how the interface is supposed to be used. For example, if
a user refers to the corporate logo on your Web site as "the beach ball," you would call it the beach
ball, too, not the home page link.
Use Open-Ended Questions
It's usually better to ask open-ended questions rather than closed-ended ones because the former
encourage users to give more detailed answers. The purpose of an open-ended question is to
encourage users to reveal their underlying thought process.
"What will that do?"
"What are you trying to do right now?"
"What are you thinking?" (Use a neutral tone with this one!)
"Hmm, tell me more about that."
"What does ___ mean to you?"
Although open-ended questions are often preferable, sometimes you may want to use a closed-ended
question if time is short or you really do want to know something specific, such as, "Did you see this link
to the return policy over here?" However, I suggest reserving such questions for the end of the session
because they can change the user's subsequent behavior. In addition, you should be careful not to
Search WWH ::
Custom Search