Database Reference
In-Depth Information
Notice what these profiles have in common—they consist of no more than a handful of factors, they
distinguish between requirements and nice-to-haves, and they also mention characteristics to screen
out.
Demographics versus Characteristics
In practice, I've found that demographic factors such as age, gender, and income don't seem to have
much effect on a user's ability to turn up usability problems, so I often don't include them in the user
profile. Usually, if you get people who have the appropriate skills, knowledge, and motivation,
demographic factors are secondary.
However, I'm not saying that demographic factors are irrelevant—they are certainly an important part of
understanding who your users are. It's just that when it comes to finding people to participate in
usability tests, demographic factors often turn out to be only a proxy for what you're really interested
in—usually some combination of knowledge, preferences, and behavior.
For example, say you're developing a travel Web site, and marketing research has shown that your
target market falls into a certain income range. But then you think of that low-income couple you know
who treat themselves to a week in Aruba every spring. Perhaps the important factor isn't income, but
the number of trips taken each year, in other words, their behavior. So you'd ask, "If the person buys
more than one plane ticket online per year, would we want them regardless of income?" If the answer is
yes, you can drop the income demographic from your user profile because it's only acting as a proxy for
amount of leisure travel.
Another way to scrutinize demographic factors is to ask, "How would someone with factor X behave
differently when using our interface than someone without it?" If you can't answer that question, the
factor can be omitted from your profile. For example, several years ago I worked with a company that
was introducing high-speed Internet access to a market. They wanted to conduct a paper prototype
test of their Web site. One of the factors on their initial user profile was "Has two phone lines." Their
reasoning was that people who had a second phone line for their computer would be prime candidates
for another method of Internet access. This made perfect sense for their marketing efforts, but when
we asked ourselves, "How would people with two phone lines use this Web site differently than people
who only have one?" we realized it was totally irrelevant for what they wanted to test. Which was good
news because dropping that requirement made user recruitment much easier.
Although I often omit demographic factors from a user profile, I'll make an exception if a factor truly is
an integral part of what we're trying to study; I have tested Web sites specifically aimed at men,
women, college students, parents, and so on. In these cases, the product team believed that a
demographic factor had a strong effect on the validity of the data obtained from testing. (Translation: If
we had tested with someone else, there's a significant risk that the usability test results would have
been dismissed as atypical.)
Reality Check
Just because your team reaches consensus on the user profile doesn't mean that it represents reality.
(In the more egregious cases, you get a big clue during user recruitment when you can't find those
people—because they don't exist!) Take every opportunity to validate your user profile with people who
know (or even better, are) users. One of my colleagues once worked at a company where the product
team assumed that users would have a background in math and statistics. But when my colleague
visited some training classes, he found that only about one third of the users fit what the product team
had considered to be the "typical" profile. Fortunately, he discovered this in time to fix the product,
which might otherwise have alienated two thirds of its target market.
Time Needed to Create the User Profile
The first time you create a user profile, it might take you an hour or three, especially if there are differing
assumptions about who your users are. Sometimes you may realize that you don't have a clear picture
of who your users are—this isn't ideal, but it happens. If there are uncertainties or disagreements about
users, note these as areas for research.
Once you have a user profile, you might be able to reuse it for subsequent usability tests. But be sure
to first discuss whether you've learned anything about users since the last usability study that might
Search WWH ::




Custom Search