User Persona: Turn Experience Research Into Decisions

Most persona work fails a simple test. Print the persona, hand it to the team, and ask which design decision it settles. If the honest answer is none, what you have made is a poster: a stock photo, an invented name, a favourite coffee order, and a “tech savvy” slider set to four out of five. It cost a fortnight and it will change nothing about the user experience you ship.

A persona is worth building when it compresses real research into something a team can argue with. This page covers the fields that actually settle arguments, the ones to delete, how many personas to keep, and what the 2025 research says about letting a language model invent them for you.

The test every field has to pass

Before a field goes on the persona, ask: if this value were different, would we build something different?

Age rarely passes. “34” and “41” produce identical interfaces. Context of use passes immediately: someone completing your form one-handed on a phone at a bus stop and someone doing it on two monitors with a spreadsheet open need different things from the same screen.

Nielsen Norman Group makes the same point from the other direction, warning against details that overwhelm the ones that matter. Their example is knowing a user’s favourite wine while designing an intranet: charming, irrelevant, and it dilutes the fields the team should be reading. They also caution against taglines written to be witty, which tend to make the persona quotable rather than useful. Their guide to creating personas is the reference worth reading in full.

The five fields that earn their place

1. The job they are trying to finish. Not “wants a modern experience” but the outcome that makes them close the laptop satisfied: get the invoice paid, compare three quotes before the meeting, cancel before the renewal date. Everything else on the persona should support or obstruct this.

2. Context of use. Device, place, time pressure, who else is in the room, how often they are interrupted, what else is open. ISO 9241-210, the human-centred design standard, puts an explicit understanding of users, tasks and environments first among its principles, and environment is the part teams routinely skip.

3. Their current workaround. What they do today without you: a spreadsheet, a WhatsApp group, a competitor, a phone call, nothing at all. This is the most under-used field on any persona, because it tells you the real bar you have to clear. If the workaround is free and takes 30 seconds, a slicker interface will not win.

4. What makes them abandon. The specific thing that ends the session: a mandatory account creation, a price revealed at step four, a document they do not have to hand, a word they do not understand. Sourced from session recordings, support tickets and exit surveys rather than imagination.

5. Constraints that are not preferences. Accessibility needs, a locked-down work laptop, an old Android, a slow connection, no personal email address, needing a colleague’s approval to spend anything. These generate hard requirements, and they are the fields most often replaced by a photogenic stock image.

Anything that does not fit one of those five is decoration. Cut it.

How many personas to keep

As few as produce different decisions. The useful merge test: put two personas side by side and try to name one design choice you would make differently for each. If you cannot, they are one persona with two names, and keeping both spreads the team’s attention across a distinction that does not exist.

In practice most teams land on three to five. The failure mode at the top end is a set of eight personas that nobody can hold in their head, so the team quietly reverts to designing for themselves. The failure mode at the bottom is a single “primary user” that averages away the person your product actually struggles with.

Consider ranking them rather than treating them as equals: a primary persona whose experience you optimise for, secondaries you must not break, and explicitly named anti-personas you are choosing not to serve. That last category prevents more scope creep than any roadmap process.

Where the research comes from

NN/g is unambiguous that personas must be based on user research, and lists field studies, interviews, surveys and longitudinal studies as the sources. In an optimisation team the raw material is usually already sitting there:

• Session recordings and heatmaps for where people stall
• Support tickets and chat logs for the vocabulary problems
• Exit-intent and post-purchase surveys for the abandonment reasons
• Sales and onboarding calls for the workarounds people describe unprompted
• Analytics for which segments exist at all, but never for why

Analytics tells you what happened and personas are about why, so a persona assembled from dashboard segments alone is a demographic average wearing a name badge. Our overview of user research methods and CRO research methods covers how to gather the qualitative half without a six-week study.

If you genuinely have no research yet, build proto-personas: write the team’s assumptions down, label them clearly as assumptions with the date, and treat each one as a hypothesis to be confirmed or killed. A proto-persona that is honest about being a guess is useful. One that quietly hardens into fact over eighteen months is dangerous.

Why AI-generated personas do not pass the test

Asking a language model for five personas is now the default shortcut, and the research on it is not encouraging. A 2025 scoping review of 81 papers on creating and evaluating personas with generative AI, published on arXiv by Amin, Salminen and colleagues, found that 45% of the studies included no evaluation at all and 86% relied exclusively on GPT models.

The sharpest finding is the circularity risk: in a number of studies the same model both generated the personas and judged whether they were any good. That is a closed loop with no contact with a real user, and it produces exactly what you would expect, output that is fluent, plausible and unfalsifiable.

There is a legitimate use, and it is the opposite of the popular one. Point the model at your own transcripts, tickets and survey responses and ask it to cluster and summarise what real people said. That is compression of evidence you hold. Asking it to invent users is generation of evidence you do not, and it will happily supply a persona whose abandonment reason is whatever sounds most reasonable to a model, not what your customers actually do.

Rule of thumb: every field on a persona should be traceable to something a real person said or did. If you cannot name the source, delete the field.

Keeping them alive after the workshop

Personas rot. The market moves, the product changes, and the poster on the wall describes a user from three years ago.

Four habits keep them honest. Date every persona and review it at a fixed interval. Attach a source note to each field, even just “from 12 support tickets, Q1”. Retire personas explicitly rather than letting them fade, so nobody cites a dead one in a design review. And connect them to your test backlog, so that each persona generates hypotheses you can actually run; our conversion rate optimisation guide covers turning those into a prioritised queue.

The final signal that a persona is working is simple. In a design review, someone says “that would stop Priya” and the room knows what they mean and what to do about it. If your personas never get spoken aloud in an argument, they are not doing the job.

Frequently asked questions

What is a user persona in user experience design? A short, realistic description of a target user built from research, covering their goal, context, current workaround, what makes them abandon and their hard constraints. Its purpose is to settle design decisions, not to describe a demographic.

How many personas should a product team have? Usually three to five. The test is whether two personas would lead you to make different design decisions; if they would not, merge them. More than about five and the team stops holding them in mind.

What is the difference between a persona and a proto-persona? A persona is grounded in user research. A proto-persona is the team’s documented assumptions, created before research exists, and it should be labelled and dated as such so it gets replaced rather than quietly treated as evidence.

Can I create user personas with AI? Use AI to cluster and summarise research you already hold, such as interview transcripts and support tickets. Asking a model to invent users produces plausible fiction: a 2025 review of 81 studies found 45% carried out no evaluation and many used the same model to both generate and judge the personas.

Do personas replace user research? No, they are an output of it. A persona is a compression format for findings, and without research behind it the format just makes assumptions look authoritative.

What should I leave off a persona? Anything that would not change a design decision: invented biographical colour, favourite brands, a stock photo doing emotional work, salary where pricing is fixed, and vague trait sliders such as “tech savvy: 4/5”.