Create a user persona

Outcome

A set of two to four personas, one of them named as primary, each on one page. Every line on the page traces back to something a participant did or said. The set is attached to one design decision, and that decision is written at the top of the primary persona.

When to use it

• Two people on the team keep arguing about who a screen is for, and each one is describing a different user.
• You have, or can get, eight to twelve conversations with people who recently did the task the product supports.
• A product serves people who use it in clearly different ways, and the roadmap has to choose between them.

When not to use it

• Nobody can name the decision the persona is meant to settle. You would be buying alignment the team could simply agree on.
• You have no research and no way to get any. Write a proto-persona instead, label every line as an assumption, and use it as the brief for the interviews.
• The question is where an experience breaks, not who it breaks for. Map the journey instead.

Before you start

• The decision. One sentence: what will the team decide differently once the personas exist?
• Participants. Eight to twelve people who did the task recently. Recruit across the differences you suspect, such as new and long-time users.
• Time. About a week: two or three days of interviews, one day to plot, one day to write and review.
• The template. Open the Persona Template in Figma or print the PDF. Its sections are the ones you fill in Step 6.

Steps

Step 1: Write down the decision the persona must settle

Write the stuck argument as a question with two or more answers, for example should the settings screen be built for setting the tool up, or for checking what someone else set up? Share it with the people who will use the personas and get them to agree that this is the question.

You should now have: one written question, agreed by the team, that the persona set will answer.

Step 2: Interview people about the last time they did the task

Ask each participant to walk you through the last time they did the task, step by step. Ask about the last time specifically, not what they usually do, because people describe their habits as tidier than they are. Take notes on what they did, what they used, who else was involved and what went wrong.

You should now have: notes from eight to twelve interviews, each describing one real episode.

Step 3: List the behavioural variables

Read through the notes and list every way the participants differed in what they did. Write each difference as an axis with two ends, such as runs it alone ↔ needs sign-off from someone else. Leave out demographics at this stage. Six to ten axes is normal.

You should now have: a list of six to ten behavioural axes, each with two labelled ends.

Step 4: Place every participant on every axis

Draw each axis as a line. Mark where each participant sits on it, using the same initials on every line. Do this for every participant and every axis, even when it feels repetitive. This is the step that makes the clusters visible.

You should now have: a grid of axes with every participant placed on each one.

Step 5: Find the clusters

Look for groups of participants who sit close together on four or more axes at once. Each such group is a candidate persona. Two people agreeing on one axis is noise. If nothing clusters, you have one persona, which is a real result.

You should now have: two to four clusters, each with the participants and axes that define it.

Step 6: Write each persona on one page

For each cluster, fill in the persona template: a name and role, the context they work in, their goals, their frustrations and their behaviours. Use the axis positions to write the behaviours. Add only details that change a design decision; delete any field you cannot trace to the notes. Pick a quote that a participant actually said.

You should now have: one filled-in persona page per cluster, with no invented details.

Step 7: Name the primary persona

Choose the persona whose needs, if unmet, mean the product has failed. Write the decision from Step 1 at the top of that persona's page, with the answer the primary persona implies. Share the set with the team and ask which line they disagree with.

You should now have: a persona set with one primary, the decision it settles and the answer, reviewed by the team.

Worked example

A small payroll product. The team cannot agree whether to spend the next quarter on the setup wizard or on a screen that explains the current configuration.

1. The decision is written as: is the settings area for configuring payroll, or for auditing a configuration someone else made?
2. Ten customers walk through their last payroll run.
3. Five axes come out of the notes: runs payroll alone ↔ needs a finance lead to sign off; steady monthly cycle ↔ constant contractor changes; chose and configured the tool ↔ inherited it from a predecessor; trusts the defaults ↔ checks every line against a spreadsheet; an error is an inconvenience ↔ an error is a compliance problem.
4. Plotting the ten customers puts six of them together on four axes: inherited the tool, checks every line, needs sign-off, treats an error as a compliance problem. The other four sit together at the opposite ends.
5. Two clusters: the inheritor and the operator who set it up.
6. Each gets a page in the template. The inheritor's goal is "know what payroll is set to and why before I sign it off". The operator's goal is "change things quickly when contractors come and go".
7. The team names the inheritor as primary, because an inheritor who cannot audit the configuration stops trusting the product. The decision at the top of the page reads: build the configuration overview first; the setup wizard waits.

The persona set did not make the decision easy. It made it a question about which persona is primary, which the team could answer.

Checklist

• The decision the personas settle is written at the top of the primary persona.
• Every persona comes from interviews about a real, recent episode.
• Clusters were found on four or more behavioural axes, not on demographics.
• Every line on each page traces to the notes; no invented details remain.
• The quote on each page was said by a participant.
• There are two to four personas, and one is named as primary.
• The team has reviewed the set and said which lines they disagree with.

Common mistakes

• Starting from customer types. Picking plausible types first and then looking for behaviour to fit them returns the assumptions you started with. Start from behaviour and let the types appear.
• Filling every field in the template. A field exists, so someone fills it: favourite brands, marital status, a personality slider. Delete what you cannot trace to the research.
• Merging buyers and users. In business software the person who pays and the person who uses the product often want different things. Keep them as separate personas.
• No primary. Designing for every persona at once averages them into someone who does not exist.
• Leaving guesses unmarked. A proto-persona is useful only while everyone can see which lines are assumptions.

Related

• Persona Template: the one-page layout you fill in at Step 6, in Figma or as a PDF.
• Persona Generator: formats a persona card from a short brief once the research is done.
• Create an empathy map: what one persona says, thinks, does and feels at a single moment.
• Create a customer journey map: the journey of the primary persona through one goal.
• User Personas: A Practical Guide: why behaviour-derived personas with a primary change decisions.