Database Reference
In-Depth Information
imply that the user has missed something "obvious."
Listen for Nonspecific Utterances
Vocalizations such as
hmm, ah, oh,
or oops usually represent the tip of a cognitive iceberg, and they're
your cue that something important is going on inside the user's skull. Ditto for nonverbal gestures. A
person who is confused or thinking may wrinkle a brow, frown, or put a pen in his or her mouth. All
these cues offer a great opportunity for the facilitator to probe what's happening in a nondirective
manner: "John, what's going through your mind right now?"
[
2
]
Make Use of "Hourglass Time"
Paper prototype tests often have short pauses when the Computer is looking for (or creating on the fly)
the next piece of the prototype. Instead of sitting in silence, you can use this time by summarizing the
actions the users have taken so far (or better yet, ask them to do so) or by asking what they expect will
happen next. It also might be a good opportunity to offer a break.
Learn When to Shut Up
Unlike a real sportscaster, it's not necessary or even desirable for the facilitator to keep up a nonstop
barrage of questions and commentary. As a new facilitator, I sometimes pummeled users with so many
questions that they didn't have sufficient time to consider their answers. When people are thinking, it's
perfectly appropriate to let the silence go on for a bit—15 or 20 seconds will seem a lot longer to you
than to them—before you encourage them to verbalize. When a person is conversing, his or her brain
cannot be fully focused on the interface. If you're always jumping in with questions or hints, the
development team may complain (with some justification) that you aren't giving the users enough time
to figure things out on their own. In other words, you're part of the problem.
Let Users Decide When They're Done
As a rule, you should let the users decide when the task is done. For example, I once had a user give
up on a data entry task—the information was saved automatically, but he thought he had to use the
Save command, which happened to be grayed out. After 10 minutes of frustration, he gave up. This
was an important usability issue, but one we wouldn't have seen if we had stopped him the moment
we
knew the task was complete.
End Tasks Early if Appropriate
As an exception to the preceding rule, on occasion you may want to end a task prematurely if the part
you care about happens early. For example, on an e-commerce site, you might want to watch users
complete the checkout process all the way to the confirmation screen on one task, but you don't need
to see this more than once. On the next task, when the users add the item in the shopping cart, I might
say, "I'm going to ask you to pause here. You've covered the part we needed to see, so in the interest
of time we'd like to move on to something else." (This is just my preference, but the word "pause" feels
less awkward to me than "stop," which implies that I didn't like what the users were doing.) Caveat: Use
this tactic sparingly (ideally no more than once per test) because users may become inhibited if they
expect to be stopped at any moment.
Consider Allowing Between-Task Discussion
My usual practice is to allow observers to ask a question or two at the end of each task, although some
facilitators may choose not to do this if they're concerned about maintaining control of the session. But I
keep these discussions brief, usually just a couple of minutes, because one of the facilitator's
responsibilities it to manage how the test time is spent. If an issue has come up that merits more in-
depth discussion, I might give the observers the choice, for example, "We have about 20 minutes left.
Do you guys want to continue this discussion now or do one more task and then come back to it?"
Although I'm still managing the time, the observers get to decide which activity is of greater interest to
them.
The Scientist
The scientist is responsible for the integrity of the data, through note-taking, videotaping, written tasks,
test procedures, and so on. The scientist strives to maintain objectivity and to minimize any adverse
Search WWH ::
Custom Search