Database Reference
In-Depth Information
The flight attendant also notes each user's demeanor-are they cheerful or serious? Assertive or timid?
What kind of day have they had so far? Although it's impossible to make a thorough assessment of
someone's personality in a few minutes, the more you can learn about a user, the better you will be
able to make judgment calls when that user is stuck. I might joke with a user who was confident and
upbeat, but with a person who seemed shy or tired I would avoid humor and be a little quicker to step in
when he or she ran into difficulty.
The flight attendant has duties after "take off" as well. Throughout the test, the flight attendant monitors
users for signs of stress. Some red flags include sighing, short answers to questions when longer
answers were previously given, apologies or other self-blaming statements, and so on. The flight
attendant remembers to offer a mid-test break (often appreciated by the observers as well) and a
beverage refill. If a user ever appears distressed, the facilitator has the right and responsibility to pause
or end the test session. (This situation should be very rare—one in a few hundred tests—so a full
discussion is beyond the scope of this topic. Suffice it to say that the facilitator's primary responsibility
is to salvage the ego of the participant.)
Once I have thought of the situation in terms of the
information
that is lacking, it's easier to say
something to the user that sounds respectful and reassuring but not phony.
One of the most important things that the flight attendant can do is assure the users that they are
holding up their end of the bargain, even when—make that especially when—they encounter difficulty.
Although we'd like it if everyone sailed through the tasks, it's more valuable for the product team to find
the things that give people trouble. When users get stuck, they're really doing us a favor, albeit one that
might feel painful to both them and us. It's important to acknowledge and alleviate that pain in a way
that comes across as respectful. This is sometimes tricky—gratuitously positive feedback like "Gosh,
you're doing great!" or "Don't worry, it's not your fault" may sound hollow or patronizing to a struggling
user. There's also a risk that praise can make users think they're on the right track when they're not.
I find that it helps a lot if I refuse to think of users as dumb or ignorant. It's much more accurate, not to
mention fair, to think in terms of specific knowledge that we mistakenly assumed users would have. If a
user-blaming thought enters my mind (for example, "He has no clue how to do this"), I recast the issue
in terms of the missing facts: "He's shown us that people need to know X, Y, and Z to do this task. We
thought this user profile would know X from their jobs—maybe our assumption was wrong. And we
really do need to find a better way of explaining Y and Z." Once I have thought of the situation in terms
of the
information
that is lacking, it's easier to say something to the user that sounds respectful and
reassuring but not phony.
It may take quite a bit of practice before it feels natural to provide feedback in an appropriate way. Over
the years, I have learned to take my cues from the users. Although some people might want
reassurance that you don't blame them for the problem, others merely need to hear that you've followed
the logic of what they're doing. Here are several different examples of the kinds of things I've said to
users who encountered difficulty. What all of them have in common is their respectful intent based on
my assessment of the user and the situation. You'll need to decide which of these examples might be
appropriate for your users, and over time you'll come up with your own.
"This is exactly the kind of feedback we were hoping to get."
"It's not just you. Other people have run into this too, so it's definitely something we need to
change."
"What you've done makes perfect sense, so hopefully we can change the logic of the system to
support your approach."
"Thank you—you've just found something important that we wouldn't have noticed on our own."
"The developers are intimately familiar with the code, and sometimes they don't realize that they've
omitted crucial information from the interface."
"You're part of our market for this product, so your perspective is valuable."
"Hmm, it never explained how to do X, did it? In real life it wouldn't be fair to expect people to use
this without being told about X."
Search WWH ::
Custom Search