Personas (user personas)
Turn the patterns in your research into a few people the whole team can picture and design for.
- Time
- 45 min
- People
- 3–6
- Kind of work
- Frame
In short
A persona is a short, realistic profile of one type of person a service is for, built from patterns in research rather than imagination. To create one, gather your interview and data findings, find the behaviours and needs that recur together, give each cluster a name and a goal, and link every detail to evidence.
What it is
A persona describes a group of people who share goals, behaviours and problems as if they were one person, so that a team can talk about "what would Haya need here" instead of "the user". A useful persona holds what the person is trying to achieve, how they go about it today, what gets in their way, the context they act in, and a few words they actually used. It is a summary of research, written in a form that is easy to remember and to argue with.
Personas are widely used in service and product design, and public-sector teams, including UK Policy Lab in its Open Policy Making toolkit, use them to keep the people a policy or service affects in view. Their value depends entirely on the evidence behind them. A persona invented in a meeting, built mainly from age, gender and job title, gives a team false confidence and often repeats its existing assumptions. A persona grounded in research, organised around behaviour and needs, does the opposite: it lets the team check its decisions against people who exist.
When to use it
Use it when
- You have finished a round of interviews or observation and need a shared way to talk about the different people you met.
- A team keeps designing for an imagined average user who does not exist.
- Different groups use the same service in very different ways and you need to decide whom to design for first.
- You are briefing new team members, suppliers or leadership and want them to understand users quickly.
- You want a checklist for reviewing designs: would each persona be able to complete this?
Skip it when
- You have no research yet. Do interviews or gather data first, rather than writing personas from opinion.
- You need to understand one specific moment in detail. An empathy map or journey map will be more precise.
- The decision depends on numbers, such as how many people are affected. Personas describe types of people, not their proportions.
You need
- Time
- About 45 minutes for one or two personas once research is synthesised, plus time beforehand to group the findings.
- People
- 3 to 6 people, including those who did the research and at least one person who works directly with service users.
- Materials
- Interview notes, affinity groups or empathy maps, any service data such as volumes or channel use, the persona worksheet and sticky notes.
How to run it
Step 1: Gather the evidence
Bring every source you have: interview notes, observations, empathy maps, call centre reasons, complaint themes and channel data. Put them where the whole group can see them. Agree that every line on the final persona must point back to something in this pile.
Step 2: Find the behaviours that differ
List the ways the people you met differed in what they did and needed, such as "does everything online" versus "relies on a family member", or "plans weeks ahead" versus "acts at the deadline". Write each as a scale between two ends. Behaviours and needs matter more here than age or job, because they are what change the design.
Step 3: Place people on the scales
For each person in your research, mark roughly where they sit on each scale. Then look for people who sit together on several scales at once. Each recurring cluster is a candidate persona. Most services end up with three to five; if you have more than six, some can probably be merged.
Step 4: Write the goal and the frustrations
For each cluster, write the main goal in the person's own terms, the way they go about it today, and the two or three frustrations that come up most. Use quotes from the research where you can. Keep it about the service you are working on, not the person's whole life.
Step 5: Add context and a name
Add only the context that affects how they use the service: devices, language, who helps them, time pressure, access needs. Give the persona a realistic name and a short label for the behaviour, such as "the delegator" or "the deadline acter". Add a photo only if it will not lead people to stereotype; a simple illustration often works better.
Step 6: Check it against the evidence
Read each persona aloud and ask the people who did the research: did we meet people like this? Is anything here a guess? Mark guesses clearly or remove them. Note how many research participants each persona draws on, so readers know how solid it is.
Step 7: Choose the primary persona
Agree which persona the next piece of work is designed for first, and why. Usually it is the group whose needs are hardest to meet or who use the service most. Record the decision on the worksheet so that later design reviews can be checked against it.
Worked example
A national pension agency pays about 640,000 retirees and handles roughly 9,000 calls a day. A new digital service for updating bank details and dependants had a completion rate of 31%, and leadership wanted to know whom it was failing. The research team had interviewed 22 retirees and family members and reviewed a month of call reasons.
Five people met for 50 minutes: two researchers, a call centre team leader, a digital product manager and a policy officer. They started from the affinity groups already on the wall.
They drew four scales: does it alone or through someone else; online confident or phone first; plans ahead or acts after a payment stops; one pension or several income sources.
Placing the 22 participants produced three clear clusters. The largest was retirees who manage their affairs through an adult child, who logs in on their behalf. It drew on nine interviews and matched the top call reason, "I am calling for my father".
The team called this persona Abu Khalid, "the delegator", with his daughter as the person who actually uses the service. His goal was "keep my pension arriving without bothering anyone". The main frustrations were that the service would not let his daughter act for him, and that letters went only to his old address.
One proposed detail, that delegators were mostly over 75, was removed because only four of the nine were. It was replaced with the behaviour that mattered: "has not logged in himself in the past year".
The team chose the delegator as the primary persona for the next release, and the first design question became how a family member could be authorised to update details on someone's behalf.
IllustrativeTips and mistakes
Tips
- Lead with goals and behaviours. Put age and job, if you include them at all, at the bottom.
- Keep each persona to one page. If nobody can remember it after a meeting, it is too long.
- Write down how many research participants each persona rests on, so its strength is visible.
- Revisit personas when you do new research. A persona that never changes stops matching the people it describes.
Common mistakes
- Inventing personas in a workshop from what the team believes, then treating them as research.
- Building personas around demographics, so that two people with the same age and job but opposite behaviours end up in one profile.
- Making so many personas that the team cannot keep them in mind or choose between them.
- Writing an idealised user who already does everything the service hopes for, which hides the people it is failing.
What you walk away with
You leave with three to five one-page personas based on research, each with a goal, current behaviour, frustrations, relevant context, quotes and a note of the evidence behind it, plus an agreed primary persona for the next piece of work. The next step is to follow that persona through the service. Experience mapping shows where it struggles, and how might we questions turn its frustrations into challenges for the team.
Questions people ask
How many personas should a service have?
Usually three to five. Fewer may hide important differences; more than six is hard for a team to use. Choose one as the primary persona for each piece of work.
What is the difference between a persona and an empathy map?
An empathy map captures what one person, or one type of person, says, thinks, does and feels, often straight after an interview. A persona is broader and longer lasting: it combines many interviews into a profile of a recurring type of user.
Can we create personas without research?
You can write draft profiles of who you think your users are, but label them clearly as assumptions to test. They should not be used to make design decisions until research confirms or replaces them.
Tool card
The worksheet your team fills in, one box per field.
- Name and label
- Goal
- How they do it today
- Frustrations
- Context that matters
- In their words
- Evidence behind it