Database Reference
In-Depth Information
Tips for Dealing with Skeptics
When you propose using paper prototyping in your organization, it's unlikely that everyone will embrace
the technique without question. Here are some suggestions for dealing with those who remain skeptical
despite your most convincing reasons.
Respect skepticism.
This one is first for a reason: Paper prototyping isn't a perfect technique, so
it can actually hurt your case if you argue too vigorously in favor of it. Listen to people's
concerns—try to separate the valid ones from the fears that arise from unfamiliarity with the
technique. The material in this chapter will help with some of the questions and misconceptions
people typically have, but it won't be enough to satisfy everyone. Skeptics have a right to hang
onto their concerns until they can replace them with firsthand knowledge.
Make a sample paper prototype.
Some people resist paper prototyping simply because they can't
quite picture what you're talking about. Take an existing application that is small in scope, print
some screen shots, and even hand-draw a few. (This preparation should take less then an hour—if
you think it'll take longer, pick something simpler.) Bring the prototype to a meeting, have a willing
co-worker play user, and show people how it works.
Have influential people try it out as mock users.
Several people have told me that this tactic
was successful in getting paper prototyping accepted into their organization; see, for example, the
From the Field box above. (Caveat:
Chapter 7
mentioned the risks in having a co-worker act as a
user, so don't treat this situation the same way you would a usability test. Causing influential people
to feel foolish can be a career-limiting move. One suggestion is to take more of a walkthrough
approach—tell the person each step to take but have them do all the interaction with the prototype.
The person will still get to see what users experience, but isn't put on the spot.)
From the Field: Introducing Paper Prototyping
"Back in the mid-90s, paper prototyping wasn't widely known and there was a lot of
skepticism initially. Paper prototyping wasn't very credible in the eyes of managers. So I
asked some managers to participate in early test sessions and pretend to be end users.
After they experienced paper prototyping as a user, they realized that it worked, and there
was a lot less resistance to using it."
Timo Jokela, formerly of Nokia
Seek support from sympathetic departments.
If you're a developer or usability specialist, note
that technical writers, trainers, and customer support reps are likely to be staunch supporters of
usability testing—without it, usability problems become
their
problems. Invite them, and other
sympathetic souls, to everything you do regarding paper prototyping and/or usability testing. Don't
worry about whether you have the authority to request their presence, just make them aware of
your plans and trust that they'll do their best to be involved.
Just do it.
Because paper prototyping can be done with as few as two people, you may not need
to get a whole lot of buy-in before you start trying it. Think about whose permission you truly need,
see if you can set up a couple of usability tests, and invite people to come and watch. In
companies where paper prototyping is new, I've noticed that it's common for the third or fourth
usability test to be much better attended than the first—once a person sees firsthand the value of
the data that they get, they insist that their manager/co-workers/staff attend subsequent tests.
Ask for feedback.
If someone is skeptical but still agrees that paper prototyping is worth trying,
promise them that afterward there will be an opportunity for everyone to give their feedback on how
well the method worked, whether they want to use it again, and anything they might want to do
differently. In fact, I make it a point to do this at the conclusion of every usability study.
Search WWH ::
Custom Search