Introduction to Usablity Test Facilitation - Paper Prototyping: The Fast and Easy Way to Define and Refine User Interfaces - page 145

Other Common Testing Challenges

Writing about everything that can possibly go wrong during a usability test would be a topic in itself. But
here are some common situations and tips for handling them.

Getting Users Unstuck

It's usually not a question of whether users will get stuck, but rather how soon and how badly. Having
users run into difficulty while attempting tasks is perhaps the most valuable part of usability testing
because it indicates a problem with the interface that you can (hopefully) solve now that you're aware of
it.

Once you explain something, you forever lose an opportunity to understand the problem.

When users ask a question, resist the temptation to answer it. Once you explain something to a user,
you forever lose an opportunity to understand the problem. Once the answer has been revealed, users

may have one or both of the following reactions:

They will be embarrassed at what they perceive to be their own ignorance and not want to tell you
what they were thinking. "Oh, never mind, it was just me."

They literally can't reconstruct or articulate what their thought process was in the absence of
information that they now have. They'll say something like, "Okay, that makes perfect sense. It's
fine the way it is."

On the other hand, you don't want the test to grind to a halt. My favorite tactic for getting a user unstuck
is to ask a series of questions, starting very general and progressively getting more specific. For
example, say you're testing a telephone interface and the user can't figure out how to transfer a call:

Facilitator User

1. What are you trying to do right now? I want to transfer this call to Mike in

Accounting.

2. What do you think the next step is? I want to dial 5385, but not lose this guy I'm

talking to.

3. (A small hint): Do you see anything that

might help you?

I'm not sure ... if I dial the extension, won't it
just beep?

4. (A big hint): What do you think the Flash

button does?

I was wondering about that, but I was afraid it
would hang up.

This approach is useful in ferreting out the root cause of a problem. You verify that the user:

Is trying to do what you thought (perhaps the user assumes the caller would prefer to be given
Mike's extension instead of being transferred).

Shares your understanding of how to go about it.

Can find and use the specific function or control needed to proceed with the task.

In this example, the root cause of the problem is insufficient information about how the Flash button
works.

The User with an Agenda

Every once in a while a user will take advantage of the usability test as an opportunity to give the
product team detailed—perhaps repeated—feedback on what's wrong with the interface or how it
"should" be designed. Sometimes when users have behaved this way, it's been my fault for not briefing