Most teams learn how to create a user persona the wrong way: someone opens a slide template, invents “Marketing Mary, 34, loves yoga and oat milk lattes”, adds a stock photo, and the file is never opened again. That is not a persona. That is fan fiction with a job title.
A real user persona is a compressed summary of evidence. Every line on it should be traceable back to something a real person said, did, or failed to do. This guide shows you the exact process: how to collect raw research notes, how to spot behavioural patterns inside them, and how to turn those patterns into a one-page document that actually changes design decisions.
We will walk through a complete worked example at the end, including the messy interview notes we started from.
What a User Persona Actually Is (And What It Is Not)
A user persona is a research-based model of a user segment, built around behaviour, goals and context, not around demographics. It exists for one reason: to help a team make decisions when the real users are not in the room.
If a persona cannot settle an argument about a feature, a flow, or a piece of copy, it is decoration.
Fiction personas vs evidence-based personas
| Fiction persona | Evidence-based persona |
|---|---|
| Built in a workshop from team assumptions | Built from interviews, support logs and analytics |
| Leads with age, gender, marital status, hobbies | Leads with tasks, triggers, workarounds and blockers |
| “Enjoys travel and photography” | “Re-enters the same client data three times per job” |
| Cannot be falsified | Can be checked against the raw transcripts |
| Used once, in a kickoff deck | Used weekly, in backlog grooming and design critique |
The test: point at any sentence on your persona and ask “which participant said this, and in which session?”. If nobody can answer, delete the sentence.
Before You Start: What You Need
You do not need a big budget or a research team. You need raw material. The minimum viable evidence base for a first persona set:
- 5 to 8 user interviews per suspected segment, 30 to 45 minutes each, recorded and transcribed
- Observation data if possible: screen recordings, shadowing sessions, or watching someone do the task live
- Support tickets and sales call notes from the last 6 to 12 months (free, already sitting in your tools, massively underused)
- Behavioural analytics: funnels, feature adoption, session frequency, device split
- Survey data only as a secondary layer, to size the patterns you already found qualitatively
Triangulation matters here. Interviews tell you why, analytics tell you how many, support tickets tell you where it hurts. A persona built on only one of the three will be wrong in a way nobody notices for months.
The 6-Step Method to Create a User Persona
Step 1: Define the decision the persona must support
Start at the end. Write down, in one sentence, the decision you are struggling with. Examples:
- “Should onboarding assume the user has their data ready, or guide them to collect it?”
- “Do we optimise for mobile-first entry or desktop batch entry?”
- “Which of our three audiences should the homepage speak to?”
This sentence determines what you interview for and what goes on the persona. A persona built with no decision in mind will be filled with trivia, because trivia is what you collect when you do not know what you are looking for.
Write your research questions
Translate the decision into 4 or 5 open questions you will explore in interviews. For the onboarding example:
- What does the user do in the hour before they open the product?
- What information do they have at hand, and where does it live?
- What do they currently do instead of using us?
- What makes them abandon a task halfway?
- Who else is involved in the decision or the task?
Step 2: Collect raw evidence (and keep it raw)
Interview people who currently do the job, whether or not they use your product. Mix three groups: active users, churned users, and non-users who have the problem.
Rules that keep the data usable:
- Ask about the last time, not about generalities. “Walk me through the last invoice you sent” beats “How do you usually send invoices?” People describe their habits inaccurately but remember specific events well.
- Chase the workaround. Spreadsheets, sticky notes, WhatsApp messages to themselves, printed sheets. Workarounds are the highest-value signal in persona research because they show unmet needs that the user has already paid to solve.
- Record verbatim quotes. Do not paraphrase while you listen. Paraphrasing is where your assumptions sneak in.
- Timestamp and tag everything with a participant code (P1, P2, P3) so you can trace a claim back later.
Store notes in a single sheet or research repository with one row per observation. One row = one thing a person said or did. This is the format that makes step 3 possible.
Step 3: Code the notes, tagging behaviour instead of demographics
This is the step most tutorials skip, and it is the whole game. Coding means going through every row of raw notes and attaching a short label describing what it is about.
Use behavioural codes, for example:
trigger(what starts the task)tool-stack(what they use today)workaroundblockergoaldecision-makerfrequencydevice-contexttrust-signal
Do a first pass without inventing categories in advance beyond these basics, then a second pass where you refine the labels based on what actually appeared. Two people coding the same transcripts independently, then comparing, dramatically reduces bias.
Explicitly do not code for age, gender, city or education unless you have evidence that the variable changes behaviour. In most B2B and SaaS products, it does not.
Step 4: Cluster codes into behavioural patterns
Now group the coded observations and look for people who cluster together on how they behave, not who they are.
A practical way to do this:
- Pick 4 to 6 behavioural variables that showed real variance in your data. Examples: frequency of use, data readiness, delegation (does it alone vs delegates), tolerance for setup time, device context.
- Draw each variable as a horizontal axis from one extreme to the other.
- Plot every participant on every axis, using the coded evidence to justify the position.
- Look for participants who land in the same region across three or more axes. That is a pattern.
- Name the pattern after the behaviour, not a stereotype: “evening batch invoicer”, “delegating owner”, “on-site mobile logger”.
If participants scatter randomly on every axis, you either need more interviews or you have one audience, not several. Having one well-evidenced persona is far better than three invented ones.
Step 5: Write the one-page persona
Each pattern becomes one persona. Keep it to a single page. Everything on it must be defensible.
The anatomy of a persona that gets used
| Section | What goes in it | Evidence source |
|---|---|---|
| Name and behavioural label | Short, memorable, describes the behaviour | Cluster from step 4 |
| Context | Role, environment, constraints that affect the task | Interviews, observation |
| Primary goal | The job they are trying to get done, in their words | goal codes |
| Trigger and frequency | When and how often the task happens | trigger, frequency, analytics |
| Current tools and workarounds | What they use today, including the ugly stuff | tool-stack, workaround |
| Blockers and frustrations | Where the task breaks down | blocker, support tickets |
| Decision criteria | What makes them adopt or reject a tool | trust-signal, churn interviews |
| 2 to 3 verbatim quotes | Exact words, with participant code | Transcripts |
| Design implications | “Because of X, we must do Y” | Your synthesis |
| Confidence and sample | How many participants, when, what is still unknown | Research log |
Notice what is missing: age, salary, favourite brands, a stock photo of someone smiling at a laptop. Add a photo only if it helps the team remember the persona, and never let it imply demographic traits you did not measure.
The confidence and sample line is the single biggest upgrade over the typical template. It tells readers how much weight to give the document and when it expires.
Step 6: Pressure-test it, then put it to work
Before you publish the persona, run these checks:
- Traceability check: every claim links to at least two participants or one participant plus quantitative support.
- Falsifiability check: could future research prove this line wrong? If not, it is too vague.
- Decision check: take three open questions from your backlog. Does the persona give a different answer than “it depends”? If not, it is not finished.
- Stakeholder check: show it to support and sales. They talk to users daily and will immediately flag anything that feels invented.
Then make it operational:
- Pin it in the project channel and the design file, not in a folder nobody opens.
- Add a line to your ticket template: “Which persona does this serve, and which part of their day does it change?”
- Reference it by name in design critique: “the on-site logger has gloves on and one bar of signal, this modal fails for them”.
- Review every 6 months, or whenever you ship a major change to the core flow. Personas drift as products and markets change.
Real Example: From Raw Notes to a Finished Persona
Here is the full process applied to a fictionalised but realistic case: a small invoicing and job-tracking app for independent trade professionals (electricians, plumbers, builders).
The decision we needed to make
“Should we invest in a faster desktop batch workflow, or in a mobile capture flow usable on a job site?”
The raw notes (extract)
| Participant | Verbatim note | Code |
|---|---|---|
| P2 | “I photograph the receipt in the van, then it sits in my camera roll until Sunday.” | workaround, device-context |
| P3 | “Sunday night is paperwork night. Two hours, kitchen table, laptop.” | trigger, frequency, device-context |
| P5 | “If I stop to type on site the customer is standing there watching me. I won’t do it.” | blocker, device-context |
| P1 | “Half the estate has no signal. I’ve lost a form twice, never again.” | blocker, trust-signal |
| P6 | “I do six to nine jobs a week, I invoice them all in one go.” | frequency, goal |
| P4 | “My partner does the chasing of unpaid ones. She has the login too.” | decision-maker, tool-stack |
| P7 | “I pick the price from the last similar job. I scroll back through old invoices.” | workaround, goal |
The patterns we found
Plotting eight participants on five behavioural axes produced two clear clusters:
- Cluster A (5 of 8): captures evidence in seconds on mobile during the day, but does all structured data entry in one weekly desktop session.
- Cluster B (2 of 8): delegates all admin to a partner or bookkeeper and only reviews totals.
- One participant did not fit either cluster, and we logged that as an open question rather than forcing the data.
Cluster A immediately answered our decision: the mobile need is capture, not entry. A full mobile invoicing flow would have been months of wasted work.
The finished one-page persona
Name: Dan, the Sunday Night Batcher
Behavioural label: daytime mobile capture, weekly desktop processing
- Context: Sole trader, 6 to 9 jobs per week, works from a van, customer often physically present during the job. Partner sometimes has shared access.
- Primary goal: Get every job invoiced before Monday without missing billable materials.
- Trigger and frequency: Capture happens ad hoc, many times a day. Processing happens once per week, Sunday evening, 60 to 120 minutes, on a laptop at home.
- Tools and workarounds: Camera roll as an inbox, WhatsApp messages to self, a notes app, old invoices used as a price reference, spreadsheet for unpaid tracking.
- Blockers: Will not type in front of a customer (P5). Does not trust forms that can lose data without signal (P1). Reconstructing a job from a photo three days later causes missed line items (P2, P6).
- Decision criteria: Works offline, visible proof nothing was lost, no monthly commitment before seeing value.
- Quotes: “Sunday night is paperwork night.” (P3) / “If I stop to type on site the customer is standing there watching me.” (P5)
- Design implications:
- Mobile = two-tap capture (photo, voice note, job tag) with offline queue and a visible sync state.
- Desktop = a batch processing queue that turns the week’s captures into draft invoices, not a blank form.
- Surface previous similar jobs as pricing suggestions during the batch session.
- Support a second seat with limited permissions for the chasing of unpaid invoices.
- Confidence: Based on 8 interviews (Q3 2026), 1,400 support tickets and 90 days of analytics confirming a Sunday 19:00 to 22:00 session peak. Open question: how this changes for traders with one or two employees.
Compare that to “Dan, 42, married, enjoys football and DIY”. One of those documents reorders a roadmap. The other does nothing.
How Many Personas Should You Create?
Fewer than you think. Practical guidance:
- One primary persona that the core experience is designed for, chosen deliberately
- One or two secondary personas whose needs you accommodate without compromising the primary
- Optional anti-persona: the user you are explicitly not building for, which is often the most useful document of all for saying no
If you end up with six personas, you probably segmented on demographics or on job titles rather than on behaviour.
Common Mistakes When Creating User Personas
- Starting from a template. The template dictates what you collect. Collect first, format later.
- Segmenting by job title. Two people with the same title can have completely different workflows, and two different titles can behave identically.
- Interviewing only happy current users. You will build a persona of people who already tolerate your product’s flaws.
- Leading questions. “Would you use a feature that did X?” produces polite lies. Ask about past behaviour instead.
- Adding personality fluff for “empathy”. Empathy comes from real quotes and real constraints, not from invented hobbies.
- Letting them expire silently. Put a review date on the page. If it is more than 12 months old, treat it as a hypothesis, not evidence.
- Confusing personas with marketing audience segments. Related, but built for different decisions.
Quick Checklist: How to Create a User Persona
- Write the decision the persona must support
- Run 5 to 8 interviews per suspected segment, mixing users, churned users and non-users
- Keep one row per observation, with participant codes
- Code for behaviour: triggers, workarounds, blockers, goals, context
- Plot participants on behavioural axes and look for clusters across 3 or more axes
- Write one page per cluster, with quotes, design implications and a confidence note
- Pressure-test for traceability, falsifiability and decision usefulness
- Embed it in tickets, critiques and onboarding, and review every 6 months
FAQ
What is a user persona in UX design?
A user persona in UX design is a research-based model of a user group, describing their goals, behaviours, context and frustrations. It is built from interviews, observation and behavioural data, and its purpose is to give a team a shared, concrete reference point when making design and product decisions.
What is the difference between a user profile and a persona?
A user profile is a factual description of a segment, usually demographic or firmographic: company size, role, location, plan type. A persona is a narrative model focused on behaviour and motivation, designed to drive decisions. A profile tells you who signed up. A persona tells you how they work and what will make the product fail them.
How many interviews do I need to create a user persona?
Five to eight per suspected segment is a solid starting point. You are looking for the point where new interviews stop producing new codes, which in practice often arrives between participants 6 and 10. Validate the resulting patterns with quantitative data before treating them as settled.
How do I create a client persona for marketing?
The method is the same, but the behavioural axes change. Instead of task workflow, you code for buying triggers, information sources, objections, who else is involved in the purchase and what evidence builds trust. Sales call recordings and lost-deal interviews are your richest raw material.
Can I use AI to create user personas?
Use it to accelerate the mechanical steps: transcription, first-pass coding suggestions, clustering help, formatting. Never use it to generate the persona content itself from a prompt. A model with no access to your users will produce exactly the plausible fiction this method exists to eliminate. Always have a human verify every code against the transcript.
How often should personas be updated?
Review every six months and after any major change to your product, pricing or market. Add a “last validated” date directly on the page so anyone reading it knows how much to trust it.
Do personas need a photo and a name?
A name helps, because teams refer to “Dan” more naturally than to “Segment 2”. A photo is optional and carries risk: it imports demographic assumptions you did not research. If you use one, choose something neutral, or use an icon or illustration instead.
Final Word
Learning how to create a user persona is not about mastering a template. It is about building a disciplined chain from a real person’s words to a decision on your roadmap. Collect raw evidence, code it for behaviour, cluster the patterns, write one defensible page, and delete anything you cannot source.
Do that, and your persona stops being a poster on the wall and starts being the reason you shipped the right thing.