Menu

Beta — We’re reformatting our articles to work with the new site, but this is one hasn’t been done yet; it may contain formatting issues. No need to report this. We’re working on it.

Getting from Research to Personas: Harnessing the Power of Data

by Kim Goodwin
on April 5, 2005

The usefulness of personas in defining and designing interactive products has
become more widely accepted in the last few years, but lack of published information
has, unfortunately, left room for a lot of misconceptions about how personas
are created, and about what information actually comprises a persona. Although
space does not permit a full treatment of persona creation in this article,
I hope to highlight a few essential points.

Start with the right kind of research

Personas are based primarily on ethnographic user data. Ethnographic techniques
are valuable because they assume that an interview subject’s attitudes and
behaviors are so habitual as to be unconscious. Rather than asking users what
they want, it is more effective to focus on what users do, what frustrates
them, and what gives them satisfaction. By combining interviewing with direct
observation – preferably in the actual usage context – you can get a lot of
data very quickly. Observation also helps minimize dependence on users’ self-reported
behavior, which is often inaccurate.

A dozen hour-long interviews are usually sufficient for defining a simple
consumer product, though it can take several dozen for a complex enterprise
application. You’ll know you can stop interviewing when you can predict how
each user will respond; this means patterns are beginning to emerge. If you
have the time and budget, you can verify your findings with quantitative surveys
or other techniques, but these cannot replace direct observation.

Identify behavioral patterns from the data

Once you finish interviewing, list all of the behavioral variables, i.e.,
ways in which interviewee behavior differed. Most variables can be represented
as ranges with two ends. In an online shopping domain, for example, you might
have variables such as frequency of shopping, degree of enjoyment, and price
vs. service orientation. (See Figure 1) There may also be demographic variables
that seem to affect behavior, such as age or technical skill. Be wary of focusing
on demographics during persona creation, since behavioral variables will have
far more impact on the design. Note that if you are doing an enterprise application,
each role will have its own set of behavioral and demographic variables. Although
the number of variables will differ from project to project, it’s typical to
find 20 or so variables per role.

Next, map each interviewee against the appropriate set of variables. It doesn’t
matter whether user #2 is 45% or 50% of the way up the scale; what matters
is where he appears relative to the other interviewees. When you are finished,
look for people who clump together across multiple variables. When you have
found a set of people clustering across six or eight variables, there’s a good
chance that you have found a major behavior pattern that will form the basis
of a persona. Give each major pattern a brief description, such as "the
bargain-hunter" or "the impulse-buyer." For very specialized
roles, you may find only one major pattern, but for consumer applications or
broader roles, you will typically find two or three patterns.

Beware of defining false patterns, though. There is a logical connection if
people who are very price-conscious also spend a lot of time comparison-shopping,
but there may not be any connection if interviewees who are very price-conscious
all happen to have cats.

Assemble your persona descriptions around behavioral patterns

For each pattern, add details based on your data. Describe the potential usage
environment, typical workday (or other relevant time period), current solutions
and frustrations, relevant relationships with others, and goals. Avoid the
temptation to add a lot of irrelevant personal detail; if you’re designing
an e-mail tool, it doesn’t matter that your persona wants to be an actress.
One or two bits of personality can bring an otherwise dull persona to life,
but too much biography will be distracting and will make the persona less credible
as an analytical tool. If every aspect of the description can’t be tied back
to real data, it’s not a persona – it’s a creative writing project that should
not be used for making critical design and business decisions.

Describe your personas in narrative form

A list of bullet points might contain the same essential facts, but since
personas do double duty as communication tools, a narrative is far more powerful
in conveying the persona’s attitudes, needs, and problems. The Cliff’s Notes
edition may convey the basic ideas, but it will never be as compelling as the
story. Avoid writing novels, though; a typical persona description is no longer
than this article. The persona does not need to contain every detail since
the people who did the interviewing are (hopefully) the people doing the design,
and no one else has the time or patience for that much detail.

Avoid false precision

Precision indicates a degree of certainty in the results; if you write down
a laboratory measurement as "1.01 centimeters," it implies that you
actually measured hundredths of centimeters. The same is true of personas;
if you provide a detailed description, it implies that you observed that level
of detail in your research. In cases where you have little or no research,
there’s no point in trying to "make up" a set of personas. Instead,
you can create "provisional personas," which are a sketchy best guess
at user needs and characteristics. They typically consist of a few goals and
one or two other characteristics, but no detail or narrative. It’s important
that all team members understand these are useful thought experiments, but
are not real personas because they are not based on data.

Build your product on the best foundation

The whole point of creating personas is to get past our personal opinions
and presuppositions to understand what users truly need. If we invent fictitious
model users and call them personas, we’ll just have the same old problems
with the development process packaged up in a new way. If you truly want to
build a better product, create your personas based on real data, and use them
in conjunction with business goals and good design principles to guide your
solutions.

Take personas to the next level

Kim has a lot to say when it comes to personas and scenarios.In her virtual seminar Designing with Scenarios: Putting Personas to Work Kim covers the relationship between personas and scenarios and how to bring them into your design process.

[This article was originally published on Cooper, by Kim Goodwin.]