In short
A user persona is a fictional but research-based profile representing a group of users who share goals, behaviours and needs, used to keep a team designing for real people rather than for themselves. A useful persona is built from interviews and data and focuses on goals, context, tasks and frustrations; a useless one is invented in a meeting and focuses on age, hobbies and a stock photo. Small teams with direct customer contact often do better with a one-page summary of jobs, contexts and pain points than with formal personas.
What a persona is for
Everyone on a product team carries a picture of the user in their head, and the pictures differ. The developer imagines someone like themselves; the founder imagines the enthusiastic early customer; the designer imagines the person from last week's usability test. Decisions get made for whichever picture is loudest that day.
A persona replaces those private pictures with a shared, written one, based on evidence. "Would Maria understand this?" is a question a team can ask and answer together, provided Maria is a faithful summary of real people rather than a mascot.
What belongs in one
The useful content is behavioural, not demographic:
- Goals. What they are trying to accomplish, in their terms, and why.
- Context. Where and when they use the product, on what device, under what pressure, with what else competing for attention.
- Tasks and frequency. What they actually do, how often, and what they do around it.
- Knowledge and confidence. What they already understand, what vocabulary they use, where they hesitate.
- Frustrations. What goes wrong today, with your product or the alternative.
- Decision factors. What makes them choose, stay, or leave.
- A representative quote or two, verbatim from research.
- A name and a short description, so the persona is easy to refer to.
What does not belong, or belongs only if it affects the design: age, income, family status, hobbies, a stock photograph, a favourite brand, a life story. These are the parts most templates lead with, and they are the parts that make personas feel like fiction because they usually are.
The research it requires
A persona is a summary of data. Without data there is nothing to summarise, and the exercise produces a portrait of the team's assumptions with a name attached, which is worse than no persona because it looks like evidence.
The minimum: interviews with a handful of real users or prospective users per suspected group, looking for patterns in goals and behaviour; supporting data from analytics, support tickets, sales conversations and surveys; and a synthesis that groups people by what they are trying to do rather than by who they are. Two or three groups usually emerge. Each becomes a persona.
The number of interviews needed is smaller than people fear. Five to eight per group reveals the pattern; the pattern is the persona.
Where personas fail
Invented in a workshop. The most common failure. The team brainstorms who the users probably are, picks names and photos, and the document is cited for years as though someone had checked.
Demographic rather than behavioural. "Sarah, 34, marketing manager, likes yoga" tells the designer nothing about what Sarah needs from the checkout flow.
Too many. Seven personas is a taxonomy nobody can hold in their head. Two or three that genuinely differ in goals is the useful number; if two personas would make the same decisions about the product, they are one persona.
Frozen. Users change, products change, and a persona from three years ago describes a market that may not exist.
Decorative. Printed, laminated, pinned to the wall, and never consulted when a decision is made. A persona earns its keep only when someone asks "what would this person do here?" in a design review.
The alternatives
Jobs to be done. Instead of describing a person, describe the job: "when I receive an invoice from a new supplier, I want to check it against the order without leaving my inbox, so that I can approve it in under a minute." Jobs are behavioural by construction and avoid the demographic trap. Many teams find them more directly useful than personas.
A one-page user summary. For each user group: who they are in one sentence, what they are trying to do, where they do it, what goes wrong, and three quotes. Less ceremony, same purpose.
Proto-personas, explicitly labelled as assumptions to be tested, used to plan the research rather than to replace it.
Direct contact. A small team whose founders talk to customers weekly may not need a written persona at all; the persona is the founders' memory, kept current by conversation. The document becomes necessary when the team grows beyond the people who have that contact.
When to bother
Build personas when several people who do not talk to users are making design decisions, when the user groups genuinely differ in what they need, and when there is research to base them on. Skip them when the team is small and in constant contact with customers, when there is one user type, or when there is no research and no time to do it, in which case do the research first or use a job statement honestly labelled as a hypothesis.
The product design process needs a shared picture of the user; a persona is one form that picture can take, and a good one is a research deliverable, not a design one. If you would like help turning existing customer conversations into a persona set the team will actually use, book a call.
Common questions
What should a user persona include?
Goals, context of use, tasks and their frequency, knowledge and vocabulary, frustrations, decision factors, and a verbatim quote or two, plus a name for easy reference. Demographics, hobbies and stock photographs add little and are the elements that make personas feel fictional. Everything in it should trace back to research.
How many user personas should you have?
Two or three that genuinely differ in goals and behaviour. If two candidate personas would make the same decisions about the product, they are one persona. More than three or four becomes a taxonomy nobody uses, and usually indicates grouping by demographics rather than by what people are trying to do.
What is the difference between a persona and a target audience?
A target audience is a market segment described in aggregate, often by demographics and firmographics, used for marketing and positioning. A persona is a concrete, research-based portrait of one representative user type, focused on goals and behaviour, used to make design decisions. A target audience may contain several personas.
Are user personas still relevant?
Yes, when they are built from research and used in decisions. Their reputation suffered because so many are invented in workshops and decorated with demographics. Many teams now prefer jobs-to-be-done statements or a one-page behavioural summary, which serve the same purpose with less ceremony; either way, a shared, evidence-based picture of the user remains essential.
How do you create a user persona without research?
You should not, except as an explicitly labelled proto-persona, a set of assumptions written down to be tested. Interview five to eight real or prospective users per suspected group, gather analytics, support and sales evidence, and group people by what they are trying to do. A persona built without that is a portrait of the team's guesses.
