What is a user persona?

A user persona is a fictional but research-based representation of a key type of user. It synthesizes patterns from real user research — interviews, observations, surveys — into a character that teams can reference when making product and design decisions.

Personas are not guesses about who might use a product. At their best, they are a distillation of real data: the goals, behaviors, frustrations, and mental models that researchers have observed across many actual users. A well-constructed persona makes it easier for product and design teams to build empathy and make consistent decisions, even when users are not in the room.

Research-based vs. assumption-based personas

Not all personas are created equal. The most important distinction is whether a persona is grounded in research or built from assumptions.

Assumption-based personas are created by teams using their existing knowledge — or guesses — about who their users are. They feel productive to create and they look polished, but they reflect the team's biases rather than users' realities. Decisions made using them often miss the mark.

Research-based personas are built from qualitative data gathered directly from users. They are messier to create — they require recruiting participants, conducting interviews, and analyzing patterns across many sessions — but they represent what is actually true about the user population, not what teams assume to be true.

The difference matters enormously. A product built for a research-based persona is built for a real human. A product built for an assumption-based persona is built for a mirror.

What a user persona typically includes

While the format varies by team and tool, a user persona usually includes the following elements.

Name and photo. A fictional name and a stock photo help humanize the persona and make it easier to reference in conversation. "What would Priya think of this?" is more natural than "What would User Type 2 think?"

Role and context. The persona's job title, industry, and organizational context. This grounds the persona in a recognizable situation and helps teams understand the environment the user operates in.

Goals. What the user is trying to accomplish — both in relation to the product and in their broader work or life. Goals explain the "why" behind behavior and are the most important element of a persona.

Frustrations and pain points. The specific things that make the user's current situation difficult. These are often the best starting points for product opportunities.

Behaviors. How the user currently approaches the problem the product addresses. What tools do they use? What workarounds have they developed? What habits shape their workflow?

Mental models. How the user thinks about the domain. What vocabulary do they use? What assumptions do they bring? Understanding mental models helps teams design interfaces and messaging that match user expectations.

Quotes. Direct quotes from research participants that capture the persona's voice and perspective. Quotes make personas more believable and help teams connect the data to real human experience.

User persona vs. marketing persona vs. buyer persona

These three types of personas are often confused, but they serve different purposes and are used by different teams.

A user persona represents someone who uses the product. It focuses on tasks, goals, and the experience of using the product. It is built for product managers, designers, and researchers.

A marketing persona (also called a buyer persona or customer persona) represents someone who might be a customer. It focuses on who to reach, how to reach them, and what messages will resonate. It is built for marketing and sales teams.

A buyer persona in B2B contexts often represents the economic decision-maker — the person who signs the contract — who may be entirely different from the day-to-day user. Understanding both the buyer and the user is essential for B2B products.

How to create a user persona

Step 1: Conduct user research

Personas should be built on qualitative research, typically user interviews. Aim for at least five to eight interviews per major user segment, though more is better. Observe users in their natural environment where possible, and ask about their goals, workflows, frustrations, and the tools they currently use.

Step 2: Identify patterns across participants

After collecting research, look for recurring themes. Which goals come up again and again? What frustrations do multiple users share? Where do users' mental models diverge from how the product actually works? Group participants by the patterns that emerge, not by demographic characteristics.

Step 3: Draft the persona

Translate the patterns you've identified into a coherent persona narrative. Write in the first person where helpful — "I need to be able to share findings quickly because my stakeholders don't read long reports" is more vivid than "this user values brevity." Include real quotes from research to anchor the persona in actual data.

Step 4: Validate with your team

Share the draft persona with the researchers, designers, and product managers who will use it. Check whether it matches their understanding of users. Identify any behaviors or goals that feel off. Iterate based on feedback.

Step 5: Keep personas current

User needs evolve, products change, and research accumulates. A persona created two years ago may no longer reflect the current user base. Plan to revisit and update personas whenever significant new research is completed or when the product changes substantially.

Common mistakes when creating user personas

Making them too demographic. A persona that is primarily defined by age, gender, and job title tells teams very little that is actionable. Focus on goals and behaviors, not demographics.

Creating too many. A set of twelve personas is impossible for a team to keep in mind. If your research reveals many distinct user types, prioritize the two to four that matter most for current product decisions.

Building them without research. Assumption-based personas feel useful but mislead teams. If you don't have research yet, it's better to acknowledge the uncertainty than to present guesses as facts.

Never using them. Personas that live in a slide deck and are never referenced again don't improve decisions. For personas to be useful, they need to be embedded in the team's workflow — referenced in design critiques, product reviews, and roadmap discussions.

How to use user personas in product and design work

Personas are most valuable when they are used consistently as a reference point for decisions. Some effective practices:

Post personas in shared team spaces where they are visible during design and planning work. Reference them by name when discussing tradeoffs: "Given what we know about Marcus's workflow, will this feature add friction or reduce it?" Use them to prioritize features — ask which persona a proposed feature primarily serves and whether that aligns with strategic priorities. Include them in design critiques as a lens for evaluating whether a solution serves real user needs.

A persona is not a constraint — it is a tool for building shared understanding. When a team agrees on who they are building for, decisions become faster and more consistent.