Database Reference
In-Depth Information
were doing the right thing [with the 3D interface]. Paper prototyping helped the company address these
issues and change technical direction. Without it, these decisions would likely have taken 6 to 12
months longer."
At the kickoff meeting, ask everyone to discuss what things they're concerned about and/or would like
to know more about. The exact questions, of course, depend on the circumstances of your project, but
following are some questions you might use to get people started:
What are you least sure about?
What are the greatest risks from a business perspective?
What problems keep you up at night?
What important design decisions do you still have to make?
What have we gotten the most negative feedback about?
What tasks are critically important to users, even if they're done infrequently?
What parts are new?
If you have an existing version of the interface, make sure to get input from trainers and/or customer
support, who will likely have a good idea where the trouble spots are. If your team is designing
something new, these questions may be harder to answer. You may not even know where your biggest
risks lie—in essence, this is your biggest risk.
Write down everyone's concerns on the whiteboard, and ask someone to type it up at the same time.
It's fine if people don't agree on what the problems are. Don't discuss, just list. The next chapter on
task design explains how you use these concerns as inputs into the process of creating tasks.
(Although you could wait until the task design meeting to have this discussion about risks, I find it's
useful to do it at the kickoff meeting because it helps people understand the purpose of paper
prototyping and usability testing.)
Discussing your concerns first may help clarify the type of user you want to focus on, which is the next
activity in the kickoff meeting. However, it's possible that these steps should be reversed for your
project—the things you're most concerned about might depend on which user(s) you're talking about. If
you find yourselves getting bogged down in the discussion of risks, you may want to switch gears and
talk about users, then pick up your discussion of risks once you've agreed on the user profile.
Create a User Profile
It's important to get consensus from the development team about which kind of users you want to
recruit for the usability tests. It's common for interfaces to have more than one type of user, but if you're
doing usability testing for the first time, choose only one. For example, if your interface is used by
system administrators and end users, pick one of those populations to test with. The main problem with
testing multiple types of users is that you're tempted to subdivide your test population too much, and it's
very hard to interpret the results if you've brought in only two users from each of four target markets.
You need to test with enough of one kind of user to see the patterns, and once you've done that you'll
have plenty of data to digest. So pick one type of user for now—you can always do another usability
study later.
There is no one best process for creating a user profile. I describe what I usually do, but you might
want to do some further reading on the topic.
Start by discussing what characteristics the target users have. Following are some questions you may
find helpful:
What education or training have they received?
What are they responsible for in their work?
How familiar are they with the technology and concepts our product uses?
Search WWH ::




Custom Search