Database Reference
In-Depth Information
Set
expectations
"The prototype still has some rough
edges—we're still thinking through how it
should work and some parts of it are
incomplete. Before we cast it in concrete, we
want to get some feedback about how well
this design works. We're doing several
sessions like this one, so it's likely that the
final version of the interface will be different
than what you see today. If you have
suggestions we'll make note of them,
although at this point it is premature to
promise what we'll be able to include in the
interface. When we get done with this series
of sessions, we'll review everyone's feedback
to help determine our priorities for the next
release."
Acknowledge the
unfinished nature of
the prototype (avoid
the temptation to
apologize—present
this as a benefit).
Explain that the
design will evolve.
Explain that you will
record their
suggestions but don't
promise to implement
them (especially
important if the user
is a customer).
Paperwork
and
administrivia
"Do you have any questions about what we'll
be doing today? If not, could I please get
your signature on this form? And so I don't
forget, I'm going to give you your payment
now since you've already earned it by virtue
of showing up on time. If you need to leave
early for any reason, you're still entitled to
keep it."
Get signature on
informed consent
form.
Pay users (unless
you have decided to
pay them at the end).
Escort them into test
room.
In the Test Room
The observers are assembled in the room before the users come in, and the prototype is on the table,
displaying the screen that we've decided to use as the starting point, even if it's just a blank
background. Once the users are seated in front of the prototype, I ask the team members to introduce
themselves first—this allows the users to look around the room and get familiar with the test setting
before they are asked to speak. Observers should avoid giving much detail about themselves or what
they're working on, especially things like "lead designer," which might sound intimidating. If in doubt, just
names will suffice.
Then I introduce each user by first name (do whatever is appropriate in your culture) and have each
one describe a bit about his or her background. Not only does this get the users comfortable speaking
to the group, but the team can verify that the users meet the profile of the target audience for the
interface. Whoever did the user recruitment should provide you with the users' answers to the
screening questions, which can help you identify interesting aspects of the users' background. I usually
ask two or three specific questions—in the absence of structure, some users will either say very little
(bad) or will give their entire life history (worse). I also give the observers a chance to ask the users
more about their background before we begin the test.
Before giving the users the first task, I explain what they're looking at and how we'd like them to interact
with the paper prototype and Computer. I always end my introduction with the all-important, "We're
testing the interface; we're not testing you." I say this to every user at least once before the test (even if
they've participated in a test before), and repeat it if necessary. See
Table 9.2
for details and examples
of wording.
Table 9.2: Introducing the Test
Topic
Checklist
Example Wording
Search WWH ::
Custom Search