Perfecting Your Personas

by Kim Goodwin on August 2001

A persona is a user archetype you can use to help guide decisions about
product features, navigation, interactions, and even visual design. By
designing for the archetypewhose goals and behavior patterns are well
understoodyou can satisfy the broader group of people represented by that
archetype. In most cases, personas are synthesized from a series of
ethnographic interviews with real people, then captured in 1-2 page
descriptions that include behavior patterns, goals, skills, attitudes, and
environment, with a few fictional personal details to bring the persona to life.
For each product, or sometimes for each set of tools within a product, there is
a small set of personas, one of whom is the primary focus for the design.
It's easy to assemble a set of user characteristics and call it a persona, but it's
not so easy to create personas that are truly effective design and
communication tools. If you have begun to create your own personas, here are
some tips to help you perfect them.

Personas represent behavior patterns, not job descriptions

A good persona description is not a list of tasks or duties; it's a narrative that
describes the flow of someone's day, as well as their skills, attitudes,
environment, and goals. A persona answers critical questions that a job
description or task list doesn't, such as: Which pieces of information are
required at what points in the day? Do users focus on one thing at a time,
carrying it through to completion, or are there a lot of interruptions? Why are
they using this product in the first place?
There is seldom a one-to-one correlation between personas and job
descriptions. In some cases there will be multiple personas with the same job
description; in others, a single persona can represent people with a wide range
of jobs. If you were creating software used by call center agents, for example,
you might have an experienced agent persona who is very familiar with the
product, as well as an inexperienced agent who needs more prompts and
written information. If, on the other hand, you were designing an e-mail
application, one persona could represent people with hundreds of very
different job descriptions, as long as they all shared similar goals and behavior
patterns related to communication.

Keep your persona set small

If you've ever read a book or watched a movie with an enormous cast of
characters, you may have found it hard to remember who was related to
whom, who said what, and so on. You probably didn't feel like you knew any of
the characters very well. If you were designing a product for such a large cast
of characters, could you predict how so-and-so's cousin (whose name you
forget) would behave in a certain situation? Probably not. That's why a large
set of personas is problematicthe personas all blur together.

Ideally, you should have only the minimum number of personas required to
illustrate key goals and behavior patterns. There's no magic number, but if
you're designing a consumer product and you have a dozen personas, then
you may be making distinctions that aren't very important. For example, if you
were creating an electronic family calendar, your persona set might include a
career mom, a stay-at-home mom, a career dad, and a teenager. If the career
mom has the same needs as the career dad, and also does all the family
management the stay-at-home mom does, you may be able to eliminate both
the dad and stay-at-home mom personas.

Your marketing and sales targets may not be your design

targets
Many product managers and executives are surprised when there isn't a direct
correlation between market segments and personas. The people who bring in
the most revenue may not be the best design target. If you were designing an
in-flight entertainment system, a frequent business travelerevery airline's
most valued customerwould be a tempting design target. A business traveler
would actually make a poor design target, though, because he would be too
familiar with flying and with using computers and other gadgets. If you design
for the business traveler, the retired bricklayer going to see his grandchildren
won't be able to use the system. If you design for the bricklayer, the business
traveler will also be happy.

Add life to the personas, but remember they're design tools

first
Sometimes it's easy to focus too much on a persona's biography. Personal
details can be the fun part, but if there are too many of them they just get in
the way. To avoid this problem, focus first on the workflow and behavior
patterns, goals, environment, and attitudes of the personathe information
that's critical for designwithout adding any personality.
Once you have the critical design information, add just one or two personal
details, such as what your persona does after work (she goes home to watch
old movies with Claude, her cat), or what personal touches there are in her
workspace. You can also add life to the persona by using environmental
details to reinforce important characteristics. For example, if someone tends to
be incredibly busy at work, don't just say he's incredibly busy; instead, say
there's a sandwich on his desk that he's been trying to find time to eat for three
hours. Without a little bit of personality, personas can easily turn into generic
users instead of precise design targets.

Use the right goals

Each persona should have three or four important goals that help focus the
design. Keep in mind that goals and tasks are different: tasks are not ends in
themselves, but are merely things we do to accomplish goals. Not just any
goals will do, though, so it's important to understand which types will help you
make design decisions.

Life goals are only occasionally useful in design. For example, "Retire by age
45" would be of little use if you were designing a word processor, mobile
phone, or PDA, but it may offer valuable insight when you're designing a
financial planning tool.
Experience goals describe how the persona wants to feel when using a
product; having fun and not feeling stupid are experience goals. Not every
persona needs an experience goal; in most persona sets, there is one persona
who represents people with a lot of anxiety about technology. One of this
person's goals is to avoid feeling stupid. Other experience goals might center
on the product domain. A persona using an online banking site, for example,
might want to feel confident that his transactions are secure.
Most persona goals should be end goals that focus on what the persona
could get out of using a well-designed product or service. End goals may
involve the work product that results from using the tool. For example, a
graphic designer using a layout tool might want to create an award-winning ad.
End goals can also involve indirect benefits from using a product. If a manager
wants to be more proactive, a better spreadsheet tool can help her achieve
this goal if it makes her more efficient.

Personas must be specific to the design problem

Organizations with more than one product often want to use the same
personas over and over ("We have a salesperson persona alreadywhy can't
we use her for the spreadsheet as well as the contact management
software?"). Unfortunately, this doesn't work because effective personas must
be context-specificthey should be focused on the behaviors and goals
related to the specific domain of a product. A persona's behaviors and goals
related to contact management have very little to do with those related to
manipulating financial data. You could keep the same name and personal
details, but you'd have to throw away the rest of the persona and start over. It's
better to start with a new set of personas for each product.

Ten steps to Personas

Design Research / Article 3.
First Published in July 2007, HCI Vistas Vol-III
Author: Dr. Lene Nielsen
Having worked with personas before the method ever came to be known as
personas there are, from my research and practical experience, three
important areas that have to be considered: the data material, engagement
in the personas descriptions, and buy-in from the organization which is part of
the development process whether it is redesign or a development from
scratch. This is the rationale behind my development of 10 steps to personas,
an attempt to cover the entire process from initial data gathering to ongoing

development.
In the following I will briefly outline the 10 steps. Any project that uses
personas does not necessarily need to follow all 10 steps as long as the
responsible party knows the consequences of skipping a step.
Step 1: Finding the Users
The initial step is to get hold of as much knowledge of the users as possible.
The data can originate from several sources: interviews, observations, second
hand information, questionnaires, reports, cultural probes etc. In my
experience large companies have often a lot of information about the users,
reports from marketing, call centers etc. these can in some extend substitute
real life meetings with users, but they also create problems as they do not
focus on the subject that the project is about. This might become visible in the
next step.
Step 2: Building a Hypothesis
Working with personas is focusing on users in a certain context which
originates from the project. Often companies have a certain way of talking
about their users that does not take into consideration the different context the
users might be in when using a website or a system. In a recent project for a
national Danish authority concerning redesign of a web portal business reports
to different governmental authorities, the national authority had a tradition for
dividing Danish businesses into categories of size and trades. From interviews
with staff in the call center and reading of several a hypothesis was formed.
The former division of businesses did not make sense in this project, as it does
not matter which trade the one who has to do the reporting is in, what matters
it seemed is how big the company is, and whether the persons who reports is
employed within the company or a consultant of some sort. There had been a
number of surveys performed, but none of these had this division in mind and
had to be reread from the new perspective.
Step 3: Verification
In my experience the most difficult task in persona project are how to cut
the cake - coming from data to a decision of how may personas
descriptions to include. This takes several of the 10 steps and involves more
than a group of consultants or project members to just hand over some
descriptions.
In Verification the focus is on finding data that supports the initial
patterns and at the same time supports the personas descriptions and the
scenario writing. The persona method requires a certain kind of information
that can help generate engagement in the descriptions and support scenario
writing e.g. what does the users like ad dislike, what are their values, what are
their attitudes towards the system/site, in what conditions will they use the
system/site? When these data are collected do they then support or go against
the initial data.

Step 4: Finding Patterns

My inspiration in this and the previous step originates from making sense of
data in qualitative inquiries. The way you know that you are on the right track
is when others can follow your argumentation and others can come to the
same result. Therefore it is of importance to show the categorization to other
team members, project partners etc.
Step 5: Constructing Personas
A crucial step is what to include in a personas description and how to avoid
creating stereotypes. I have quite often seen personas descriptions that either
depict super humans or stereotypes that is difficult to engage in. In this phase
you must remember that the whole purpose of personas is not to describe
users as such, but to create solutions that use the needs of the persona as a
starting point.
Drawing on knowledge from fictional writing of characters 5 areas need to be
present in the description, not mentioned specifically, but possible for the
reader to deduct from the description.
- Body (a photo or a description of how the person looks creates a feeling of
the person as a human being, posture and clothing tells a lot about the person)
- Psyche (we all have an overall attitude towards life and our surroundings
which also influence the way we meet technology e.g. is the persona introvert
or extrovert)
- Background (we all have a social background, education, upbringing which
influence our abilities, attitudes and understanding of the world)
- Emotions and attitudes towards technology and the domain designed for
- Personal traits. This one is tricky, in fictional writing there is a distinction
between flat characters and rounded characters. The flat character is
characterized by having only one character trait which is reflected in all actions
the character does and creates a highly predictable character close to the
stereotype. The flat character is difficult to engage in. The rounded character
has more than one character trait, is not predictable and easier to engage in.
When writing personas is becomes essential to avoid the stereotype and
create descriptions that the project team members can engage in. Therefore it
is advisable to look for information that repeats the same trait. In a case I had,
the persona to be described liked to feel in control, from this the team
members writing the description made her work for the tax authorities, this
came to reflect her attitude to life, she became overweight and with few
friends. For them the information of being in control created a negative attitude
towards the persona that was repeated in all information.
The fifth step is also a step that can ensure that can enhance buy-in. In my
experience it is few organizations who allow for team members to be part of

the writing process instead they use consultants or the usability department to
write the descriptions. The personas method should rather be perceived as a
process where everybody should understand how the descriptions came about
and what they can be used for. If you allow different team members to be part
of the writing process they feel ownership for the personas. They can be
rewritten be a single person to ensure homogeneity in writing and
presentation, but it pays off later to include more in the writing process or as
we did in a project, to let the participant choose the pictures for the personas.
I am fully aware that not everybody can be part of the process, newcomers
arrive, a row of companies might be involved, but if the personas are not
disseminated to participants they are not worth anything. It is not only the
personas that need to be distributed to everybody, but also the data behind
(the foundation document as Grudin, Pruitt, Adlin calls it) and not least how
and for what you are to use the personas. Many projects forget to inform and
teach developers and designers how to use the personas, how to think in
scenarios or how to use them in the use-cases.
Step 6: Defining Situations
As mentioned earlier the real purpose of the personas is to create scenarios
from the descriptions. This step is a preparation for the scenarios where it is
described in which situations the persona will use the system/site or which
needs the persona has that will lead to a use situation. Each need or situation
is the beginning for a scenario
Step 7: Validation and Buy-in
To ensure that all participants agree on the descriptions and the situations two
strategies can be followed: ask everybody their opinion and let them
participate in the process. Often the persona method is viewed as mean for
communication users to developers and others, but is as much a process that
ensures a user-centered development. Having a process view helps create
sessions where as many stakeholders as possible can be involved in the
developing the personas and in using them for design.
Step 8: Dissemination of Knowledge
I am fully aware that not everybody can be part of the process, newcomers
arrive, a row of companies might be involved, but id the personas are not
disseminated to participants they are not worth anything. It is not only the
personas that needs to be distributes to everybody, but also the data behind
(the foundation document as Grudin, Pruitt, Adlin calls it) and not least how
and for what you are to use the personas. Many projects forget to inform and
teach developers and designers how to use the personas, how to think in
scenarios or how to use them in the use-cases.
Step 9: Creating Scenarios
As mentioned earlier, personas are nothing in themselves, it is when a
persona enter a scenario they prove to be valuable. A scenario is like a story,

it has a main character (the persona) a setting (somewhere the action takes
place), it has a goal (what the persona wants to achieve), it has actions that
lead to the goal (interactions with the system/site/device), and -not least- it has
obstacles that blocks the way to the goal. I have seen quite a number of what I
call happy scenarios, where a device solves all problems. Try to read this
description of Mrs Tahira Khan and how she overcomes her diabetes and you
will see what I mean. It is not a very realistic or convincing example that a 65year old woman, who recently traveled to UK, who has undiscovered diabetes,
hardly any understanding of the English language and relatively poor literacy
in her own language overcome her diabetes with an electronic device.
Step 10: Ongoing Development
Lastly I recommend updating information on the personas. This can be done if
user tests suddenly show new results or if something changes in the personas
environments. It is crucial that not everybody is able to change the information,
but knows whom to contact. I often recommend having a personas
ambassador, who looks into the descriptions now and then, and who project
participants can contact if they find irregularities in the descriptions. And as
Adlin and Pruitt recommend in The Personas Lifecycle to let the personas
die, when they have outlived their purpose.
Rfrences:
http://www.cooper.com/journal/2001/08/perfecting_your_personas.html
Ten steps to personas: http://hceye.org/UsabilityInsights/?p=73