Database Reference
In-Depth Information
walkthrough before dispersing to do individual work. In my consulting practice, I've found that 15 to 30
minutes is usually sufficient for people to research a couple of questions and make a few screens—in
other words, to make enough progress that it's worth doing another walkthrough. If you allow too much
time, you risk losing your momentum.
Caution: This Isn't a Usability Test!
There's often a strong temptation to turn a walkthrough into a premature usability test by asking a co-
worker to play user. Typically, someone will say, "Hey, why don't we get so-and-so to be the user?
She's never seen this before, so she'd be great." Resist! There are some problems with this, both
obvious and subtle:
You aren't ready for prime time.
The reason for walkthroughs is to
prepare
for usability testing.
You're certain to find unresolved issues, some of which you'll end up discussing on the spot, which
is fine for those of you who are working on the interface, but a waste of time for the person you
asked to help you. He or she has better things to do than listen to you debate whether a button
should be disabled or how you'll handle a particular error.
Co-workers aren't real users.
Co-workers are usually not representative of real users, even if
they talk to users every day or used to be users themselves. Your co-workers know stuff that real
users don't, such as your company's business strategy, acronyms, brand, other products, and so
on. Very likely, your co-workers know more about your interface—even if they haven't seen it—than
real users do. Therefore, the behavior of a co-worker usually isn't a good proxy for what real users
will do. (Possible exception: You're designing an intranet or other interface specifically intended for
employees of your company.) And if you bring in a co-worker who truly "knows nothing" about what
you're doing, then you may run afoul of the next issue.
There are ethical and legal considerations.
When you usability test with internal employees you
actually have
more
ethical and legal responsibilities than if they were strangers. It's one thing if you
have a bad test (one where the user feels foolish or appears ignorant) with a stranger, but it's quite
another if you have to see that person in the cafeteria every day. It's even worse if that person is
your boss! There are even potential liability issues: If a co-worker participates in a usability test and
feels (correctly or otherwise) that their performance was perceived poorly by others, you could
have a lawsuit on your hands. Of course, the likelihood of this is small, but you should think twice
before asking someone outside the product team to play user.
At one company that shall remain nameless, a person coming in for a job interview was
asked to participate in a usability test instead when the scheduled participant didn't show up.
The person believed that the usability test was part of the job interview and became
distressed about being placed in a situation that made him look bad. Lawyers got involved.
The case was settled out of court, but it serves as a cautionary tale about the risks of
conscripting people at random to participate in usability tests.
You don't want more opinions.
I've yet to work at a company where there's a shortage of
opinions. The whole purpose of usability testing is to gather data from real users, not yet another
internal opinion. It may not be wise to redesign an interface solely on the basis of internal feedback.
If a co-worker gives you feedback that you don't want to act upon (at least not yet), then you're put
in the awkward position of explaining why you're apparently ignoring the valuable advice you asked
him or her to give.
Keeping the aforementioned cautions in mind, sometimes it can be valuable to ask a co-worker to play
user for another purpose: to introduce them to the concepts of paper prototyping and usability testing.
Some of my colleagues have reported very positive results from inviting an influential manager or VP to
play user after first carefully explaining the technique of paper prototyping and the purpose of the
walkthrough. There's more on the topic of convincing skeptics in
Chapter 13
.
Who Should Be the Computer
People sometimes think that you have to be a software developer to play Computer, but that's not
necessarily the case. In fact, it can be valuable for a tech writer or trainer to be the Computer because
Search WWH ::
Custom Search