What Is a User Persona? Definition and Examples

A user persona is a short, realistic profile of a type of person who uses your product, written so your team can make decisions with that person in mind. It describes who they are, what they are trying to get done, what gets in their way and how they behave, and it is based on research with real users rather than on guesswork. If you have ever asked "what is a user persona, and is it just a made-up customer with a stock photo?", the honest answer is: a good one is a summary of evidence, and a bad one is fiction with a name.

This guide covers the user persona definition in more detail, what goes into one, the main types, worked user persona examples, and the mistakes that make personas end up ignored in a shared drive.

User persona definition

A persona is a model. It compresses what you have learned about a group of users into one memorable character, so that people who were not in the research sessions can still reason about those users.

The idea was popularised in software by Alan Cooper in the late 1990s, as part of what he called goal-directed design. His point was simple: if you design for "the user", everyone on the team pictures someone different, usually themselves. If you design for a specific person with a specific goal, arguments get shorter and decisions get sharper.

A useful persona has three properties:

• Grounded. It comes from interviews, usability tests, support tickets, analytics or sales calls. Every important claim could be traced back to something a real person said or did.
• Specific. It describes goals, context and behaviour in enough detail that you could predict how this person would react to a design.
• Shared. The whole team knows it and uses its name in conversation ("would Priya find this?").

If a persona is missing any of these, it tends to become decoration.

What is a user persona in UX, compared with a marketing persona?

The phrase "persona" is used by both marketing and product teams, and they are not quite the same thing.

The two overlap, especially on a marketing website where the visitor is both a potential buyer and a user of the site. But user persona UX work cares less about age and income and more about what the person is trying to achieve, what they already know, and how much patience they have.

What goes into a user persona

There is no single required format, but most effective personas cover the same ground. Here is a practical list, roughly in order of importance.

1. Name and one-line summary. "Sam, the time-poor founder." The summary does more work than the name.
2. Goal. What they are trying to achieve, in their words. Not "use our product", but "find out if this tool will save my team a day a week".
3. Context. Where they are, what device they use, what they were doing before they arrived, who else is involved in the decision.
4. Motivation. Why this matters to them now. A deadline, a pain, a boss asking questions.
5. Behaviour. How they actually act: skims or reads, compares tabs, searches first or browses, asks a colleague.
6. Frustrations and barriers. What has gone wrong for them before, and what would make them leave.
7. Knowledge and skills. Domain expertise, technical confidence, familiarity with your category.
8. Patience. How long they will give you before giving up. This is often the most useful single attribute for design decisions.
9. A quote. A real or representative line that captures their attitude.

Things that are often included but rarely help: favourite brands, hobbies, a stock photo, a precise age. Add demographic detail only when it changes behaviour. "Uses a screen reader" matters. "Enjoys hiking" usually does not.

If you want a ready-made structure to fill in, see our user persona template and step-by-step guide.

User persona examples

Below are three user persona examples for a hypothetical B2B software company's website. Notice that each one is defined mainly by goal, behaviour and patience, not by demographics.

Example 1: The time-poor founder

"I heard about you once. Tell me what you do in ten seconds or I'm gone."

• Goal: Work out what the product does and whether it is relevant to them.
• Context: On a phone, between meetings, arrived from a link a friend shared.
• Motivation: Curious, but has no urgent problem today.
• Behaviour: Reads the headline and first screen, maybe scrolls once. Does not open the navigation.
• Frustrations: Vague headlines, jargon, having to watch a video to understand the basics.
• Patience: Very low. Under a minute.
• Design implication: The value proposition has to be clear above the fold on mobile.

Example 2: The budget owner

"I need a number I can take to my boss."

• Goal: Find the price, what is included, and how it compares with the alternative.
• Context: Desktop, at work, has two or three competitor tabs open.
• Motivation: Has been asked to recommend a tool by the end of the week.
• Behaviour: Goes straight to pricing. Reads plan details carefully. Looks for proof that other companies use it.
• Frustrations: "Contact us for pricing", unclear plan limits, no evidence of trust near the price.
• Patience: Moderate, but leaves quickly if pricing is hidden.
• Design implication: Pricing should be one click from anywhere, with what each plan includes set out clearly.

Example 3: The technical evaluator

"Fine, but does it actually work with our stack?"

• Goal: Check technical fit, security and how hard setup will be.
• Context: Desktop, asked by a manager to vet the tool.
• Motivation: Does not want to be blamed if the tool causes problems later.
• Behaviour: Looks for documentation, requirements, security pages. Uses search. Reads closely.
• Frustrations: Marketing copy with no specifics, documentation behind a sign-up wall.
• Patience: High for detail, low for fluff.
• Design implication: Link to docs and technical specifics from the main navigation, not just the footer.

These three people could all land on the same homepage in the same hour. A design that works for one can fail the other two, which is exactly why personas are useful: they make those trade-offs visible.

Types of user personas

Teams use a few distinct kinds of persona. It helps to be clear which one you are making.

Proto-personas

A proto-persona is an assumption-based sketch, written by the team in a workshop before (or without) research. It is honest about being a hypothesis. Proto-personas are useful for aligning a team quickly and for deciding what to research, as long as everyone remembers they are guesses and replaces them with evidence later.

Research-based personas

These come from qualitative research, usually interviews and observation with somewhere around 5 to 15 people per segment, then synthesised into patterns. They are the classic UX persona and the most trustworthy for design work.

Data-driven personas

Some teams cluster behaviour from analytics or survey data to find segments, then add qualitative detail. These are good at telling you how big each group is, and weaker at explaining why people behave as they do.

Jobs-to-be-done profiles

Not strictly personas, but closely related. Jobs-to-be-done focuses on the situation and the outcome someone wants ("when I'm asked to cut costs, I want to compare tools quickly so I can recommend one with confidence"), and drops the character entirely. Many teams combine the two: a persona with a clearly stated job.

AI personas

A newer use of the word: personas that an AI model can role-play, so they can attempt tasks or answer questions as that type of user. They can be useful for fast, early testing, but they inherit any assumptions you put into them. We cover this in what is an AI persona.

Why user personas matter

Personas are not an end in themselves. They are worth the effort when they change decisions. In practice they help in four ways.

• Settling arguments. "Would the budget owner find this?" is a better question than "do we like this?".
• Prioritising. If your main persona is the time-poor founder, a clearer headline probably beats a new integrations page.
• Writing better tests. Personas tell you who to recruit and which tasks to test. A usability test with the wrong participants answers the wrong question. See user research methods for how personas fit alongside other techniques.
• Onboarding new team members. A good set of personas is a fast way to share years of customer knowledge.

Common mistakes with personas

Most personas fail for predictable reasons. Check yours against this list.

• Invented, not researched. A persona made in a meeting with no user input is a proto-persona. Label it as one.
• Too many. If you have nine personas, nobody remembers any of them. Three to five is usually plenty, with one or two marked as primary.
• Demographics instead of behaviour. "34, lives in Leeds, two children" does not tell a designer what to build.
• No goal. Without a clear goal, a persona cannot be used to evaluate a design.
• Made once, never updated. Products and markets change. Revisit personas when you learn something that contradicts them.
• Never tested against. A persona that is never used to plan research or usability tests is a poster, not a tool.
• Stereotypes. Personas can quietly bake in assumptions about age, gender or ability. Stick to what the research shows, and include accessibility needs where they are real.

How to use personas once you have them

Creating the document is the easy part. Making it useful takes habit.

• Put them where decisions happen. Link them from your design files, product briefs and research plans.
• Use them to write test tasks. Each persona suggests realistic tasks. The budget owner gives you "Find out how much the plan for a team of ten costs." Our guide to usability testing scenarios shows how to turn these into good tasks.
• Recruit to match. When you run usability tests, screen participants against the persona's key attributes, not just job title.
• Check designs against each persona. For a new page, ask what each primary persona would do in the first ten seconds.

Some teams now also run personas through their product directly. With Phanera, for example, you can describe a persona (or edit ones it suggests from your site), and an AI version of that persona attempts a task on your live website in a real browser while every step and its reasoning is recorded. It is a quick way to see where a persona with low patience gives up. It does not replace talking to real users: an AI persona only knows what you told it and what it can reason from the page, so treat its findings as prompts for further research rather than final answers.

Quick checklist: is this a good persona?

Copy this list and run any persona through it.

• Based on research, or clearly labelled as an assumption
• Has one clear, specific goal in the user's own terms
• Describes context: device, situation, who else is involved
• Describes behaviour, not just demographics
• States frustrations and what would make them leave
• Includes a sense of patience or urgency
• Leads to at least one concrete design implication
• Part of a set of no more than five
• Has a date and an owner, so it can be updated

FAQ

What is a user persona in simple terms?

It is a short profile of a typical user, based on research, that describes their goals, context, behaviour and frustrations. Teams use it to design for real people rather than for themselves.

How many user personas should I have?

Usually three to five, with one or two marked as primary. More than that and people stop remembering them, which defeats the purpose.

Are personas the same as customer segments?

No. A segment groups people by shared attributes, often for marketing or sizing. A persona turns a segment into a specific, memorable person with goals and behaviour, so designers can reason about them.

Can I make a persona without user research?

You can make a proto-persona, which is an assumption-based sketch. It is useful for aligning the team and deciding what to research, but it should be labelled as a hypothesis and checked against real users as soon as possible.

Do personas still matter if we use analytics?

Yes. Analytics tell you what people do and how many do it. Personas, built from qualitative research, help explain why, and turn that understanding into something the whole team can use when making design decisions.