Skip to content
Product Lifecycle Templates

User Persona

beta  ·  Family discovery-docs  ·  Phase discover  ·  Sizes lean, full  ·  ~2,150 tokens

The document that says who a product is being built for, grounded in user research rather than in invention. Lean names a specific person’s identity, goals and pains; full adds how they behave in context, a scenario, and the evidence tier a reader needs to know how much research actually stands behind the picture.

How to tell whether you need one, how to pick lean or full, and how to grade what comes back before a team starts designing against it.

Before you start: is this the right document at all?

Section titled “Before you start: is this the right document at all?”

Write a user persona when a product or design decision is being argued from an average user or a guess, and you need to argue it from a specific, researched person instead. Nielsen Norman Group states the standard this document exists to meet: a persona must be based on user research to accurately represent a product’s users, not on what a team assumes a user wants.

Write something else if:

You actually need Because
a buyer persona you need insight into a purchase decision, the attitudes, concerns, and decision criteria that drive someone to choose you, a competitor, or the status quo. A profile that only lists individual characteristics reveals nothing about how to influence that decision, which is exactly what a buyer persona is built to do and a user persona is not
an anti-persona you want to name the customer type a team deliberately does not want, built from its own data the other way around. It ships as a separate document once a positive persona exists, not a section inside this one
a market segment you need a strategic, faceless grouping tool for a strategy that already exists. This document is a tactical, humanized single-character tool used early, to see the product through one representative person’s eyes before a strategy is set
an empathy map you need a single-session workshop canvas for understanding a stakeholder in one specific context. It is a structurally different artifact from this document, and choosing one does not rule out the other

Write nothing at all if no design or product decision is actually turning on knowing who this person is. The document exists to let a team argue from a specific person instead of a vague average; if nobody is going to make that argument, there is no argument to ground.

One posture worth adopting before you start. The evidence behind a persona is a spectrum, not a pass or fail: a proto-persona built from workshop assumptions with no new research sits at one end, and a statistically clustered persona built from a large survey sits at the other. Neither is illegitimate. What is illegitimate is labelling one tier while the document actually rests on the other, so decide, honestly, which tier you are building before you fill in a single field.

Picking a variant

Section titled “Picking a variant”

Lean carries Who They Are, Goals and Motivations, and Pains and Barriers: enough to name a specific person and ground a design conversation in someone other than the designer. Use it when a team needs a shared reference point fast and a full research programme has not run yet.

Full adds Context of Use, Scenarios, and Evidence Basis, the three sections a reader needs to see how this person actually behaves and how much research stands behind the picture. Use it once a decision genuinely turns on knowing this person’s situation, not just their goals and pains, and once you have enough behind you to fill Evidence Basis honestly rather than leave it a guess wearing a field’s shape.

The signal to move from lean to full is not a calendar, it is a question: does the next decision depend on where, when, or how this person actually uses the product, or on seeing a concrete path they take through it? If the answer is no, lean is not a smaller version of the job, it is the whole job for that decision.

A persona untouched for years is not automatically wrong, but named triggers exist for revisiting one: a business change, a competitive change, or a shift in who is actually using the product. Build the revisit trigger into Evidence Basis on the full variant rather than leaving the decision to whoever next remembers the document exists.

The rubric

Section titled “The rubric”

Score each row 0, 1 or 2. Under 11 out of 16 on a full persona, and a team will design against a situation or a research claim that is not actually there, which is a worse failure than designing against no persona at all. Under 6 out of 8 on a lean persona, and the document is not yet a specific person, it is a set of labelled boxes a reader still has to fill in themselves before they can argue anything from it. The lean variant scores against fewer rows because it does not ship the three sections a behavioral or evidentiary decision depends on; the scope table below says which.

# Criterion 0 1 2
1 Goals are sourced A goal appears with no evidence column filled in, or the column says only “user research” with nothing a reader could go check An evidence column names a method, but not enough for a reader to find the actual thing it points to, no count, no date, no way to locate it A reader could go find the interview, ticket pattern, or observation named and see this exact goal for themselves
2 Quote earns its place No quote, or a quote that reads like a mission statement anyone in the role could have written A quote exists, but nothing in it or the background could not apply to any person in that role at any company The quote states something specific enough that only someone who actually talked to this population would have produced it, and the background places the person without extra demographic fields
3 Barrier paired with cost A pain or barrier is listed with no stated impact and no evidence An impact is stated, but it is generic enough to describe any frustration (“communication could be better”) The barrier names a concrete cost to this specific person, is paired with the goal it blocks, and states where it was observed or heard
4 Field earns its place Fields are stacked with no bearing on a design decision, and nothing states why they are there Some fields beyond the essentials are present, but nothing in the document says what decision any one of them would change Every field, if removed, would change what a reader could confidently decide or build; nothing in the document is there because a template elsewhere had it
5 Context changes a decision (full only) A context row restates the persona’s role, or answers a yes/no question with no detail behind it A context row states a real fact, but nothing about it would change what actually gets built At least one context row, if it were wrong, would change a real design or engineering choice, and you can name which one
6 Scenario has an outcome (full only) The scenario is a single sentence, or walks through product screens with no want and no outcome The scenario has a beginning, middle, and end, but you could swap in a different persona’s name and nothing would need to change The scenario names a specific want, a specific path through the product tied to that want, and an outcome that could plausibly have gone the other way
7 Tier matches its basis (full only) The evidence tier is a label like “research-backed” with no basis stated underneath it A tier is named and a basis is stated, but the basis does not actually support the tier claimed, for example “qualitative” with zero interviews behind it The stated tier and the stated basis agree, and a reader could check the basis against a plain definition of that tier and reach the same label
8 Revisit trigger stated (full only) No revisit trigger is stated, or it names a fixed calendar date with no reasoning behind it A trigger is named, but it is generic enough to apply to any persona for any product (“when things change”) The trigger names a specific kind of event, a business change, a competitive change, or a shift in who is actually using the product, that a reader would recognize the moment it happened

Which rows apply to what. Full ships all eight rows because a design decision that depends on situation, path, or research strength depends on all of them. Lean ships only the four rows that do not require a section it does not carry.

Document Rows Maximum Score against
lean 1, 2, 3, 4 8 6
full all 8 16 11

Anti-patterns

Section titled “Anti-patterns”

Treating an unresearched persona as though it were evidence-backed. A proto-persona built openly from workshop assumptions is not a lesser document, it is this same format used honestly. The failure is not building one at the lightest tier, it is labelling it as though it sat at a heavier one.

Adding fields past what changes a decision. A persona’s population coverage shrinks combinatorially as attributes accumulate, worked through to roughly 134 people in the whole United States for a 21-attribute example. Every field added makes the persona describe fewer real people, and each one should earn its place by changing what a reader would build or decide.

Citing the 900 percent statistic, or figures like it, as fact. The widely circulated persona-effectiveness number traces to a single uncontrolled case study that bundled persona work with a full site redesign, a content overhaul, and an email-automation change, with no comparison group and no isolation of the persona variable. The number is real; it supports nothing about personas specifically, and repeating it in your own document does not make it more credible.

Treating the persona as an isolated UX deliverable. The documented account of why personas fail in practice is organizational rather than method-level: not an endeavor undertaken by one team and unveiled like a piece of artwork, and not a stack of handouts nobody actually opens. A persona that nobody outside its authors ever consults has already failed, whatever its content says.

Building a persona to justify a decision already made. Persona use has been documented as serving primarily to justify decisions made on other grounds rather than informing them. If every goal in the table happens to match a feature already on the roadmap, that is worth noticing, not celebrating.

Letting a persona go stale. Named triggers exist for revisiting one: a business change, a competitive change, or a shift in who is actually using the product. A persona left untouched for five or more years is, in the field’s own description, performing about as well as a dull knife on steak, and a stated revisit trigger is what keeps that from happening quietly.

Writing pains and barriers that quietly exclude disability. Naming, imagery, and accessibility are three concrete bias vectors in how pains and barriers get written. A persona for a broad user base that never names a disability-related barrier is making a choice, not an omission, and the choice should be a deliberate one, not a default.

Letting a persona harden into a marketing segment wearing a person’s name. This pattern has a name in the field’s own literature: marketing segments masquerading as personas. It is a different failure from an unresearched persona, the document still looks like a persona, but the research behind it has quietly been replaced by a market category, and a reader has no way to tell from the page alone.

When it is good enough

Section titled “When it is good enough”

When every goal and pain in the table has a source a reader could actually go check, when no field is on the page because a template elsewhere had it, and, for the full variant, when a reader can point to one context factor or one scenario step that would change what actually gets built.

Then delete every HTML comment, and treat the evidence tier as the honest floor of the document rather than a label chosen to sound more credible than the work behind it supports. That distinction, between what the research shows and what a team would prefer it showed, is what this document exists to protect.

The artifacts

Section titled “The artifacts”

user-persona_template-lean.md · ~2,150 tokens

---
title: "{{persona_name}} User Persona"
persona_name: "{{persona_name}}"
persona_role: "{{persona_role}}"
product_or_team: "{{product_or_team}}"
owner: "{{owner}}"
status: "{{status}}"
last_updated: "{{date}}"
doc_type: user-persona
size: lean
source_template: user-persona
source_template_version: 0.1.0
---


<!--
LEAN USER PERSONA. The smallest persona that is still a real one: who this person is, what they are actually
trying to do, and what gets in their way, each grounded in research rather than invention. Use it to give a
design conversation a specific person to argue from, before you have the interview count or workshop time for
Context of Use, Scenarios, and a declared evidence tier (see user-persona_template-full.md). To grow it into
the full variant, ADD sections after Pains and Barriers; never rename or reorder the ones below, because the
full variant is a strict superset of this one.


WHAT A USER PERSONA IS, AND IS NOT
It says who a product is being built for, grounded in research rather than in invention. It is NOT a buyer
persona (a different artifact answering the purchase decision, not product use), NOT an anti-persona (the
customer type you deliberately do not want, published as its own sibling document once a positive persona
exists), NOT a market segment (a strategic, faceless grouping tool used once a strategy exists, where this is
a tactical, single-character tool used early), and NOT an empathy map (a single-session workshop canvas,
structurally distinct even though the two are often used together). See user-persona_companion.md section 8.


EVERY PERSONA CARRIES AN HONEST EVIDENCE FLOOR, EVEN THIS ONE. This lean variant does not ship a declared
evidence-tier field, but that does not exempt it from having one honestly in mind: if this persona is built
from assumptions rather than interviews, say so out loud when you share it, the same way the full variant's
Evidence Basis section requires in writing. See user-persona_companion.md section 3 (Anatomy > Evidence
Basis) and section 4 (Variants and sizing).


HOW TO FILL THIS IN
1. Read the comment under each heading: WHAT it wants, WHY it matters (with a pointer into user-persona_
   companion.md), guiding questions to ASK, a GOOD and a WEAK example, and the TRAP to avoid. For tables,
   PRIORITY explains the ordering rule and ROW HINT says what a good row contains.
2. Replace each {{placeholder}} with your content. Every goal and every pain needs an evidence column filled
   in with where you actually learned it, not what the product team assumes.
3. If a section does not apply, write "N/A" and one line of why, rather than deleting it.
4. This document should be revisited as your understanding of this person changes, not filed once and
   forgotten. Before you circulate it: self-grade against user-persona_guide.md, then DELETE every HTML
   comment. They are guidance, not content.
-->


# {{persona_name}} User Persona


## Who They Are


<!-- WHAT  The identity block: a name, a role, a short quote in the persona's own voice, and enough
           background to place them, without stacking demographic fields that do not change a design
           decision.
     WHY   This is the near-universal baseline across published persona formats: a name, a role, and a
           quote, and its content stays consistent across sources for a reason, it is the minimum a reader
           needs to argue a design from a specific person's point of view instead of an average or a guess.
           Deep dive: user-persona_companion.md section 3 (Anatomy > Who They Are).
     ASK   Who is this person? What is their role or job? What is one thing they would actually say, in
           their own words, about their work? What context does a reader need to place them, without listing
           every demographic fact you could gather?
     GOOD  "Name: Renata Ibarra. Role: Overnight shift lead, regional distribution warehouse. Quote: 'I
           don't need a report, I need to know who's not showing up before the trucks arrive.' Background:
           Runs a 40-person overnight crew across three loading docks; has covered a no-show shift herself
           four times this quarter. (Quote and detail from the March 2026 shift-lead interviews, n=9.)"
     WEAK  "Renata is a hardworking supervisor who wants to do her job well and values good communication."
           (no quote, no source, and nothing here that could not apply to any supervisor at any company)
     TRAP  Stacking demographic fields, age, marital status, income bracket, because a template elsewhere
           has them. Every field you add narrows who the persona actually describes: the companion's
           curse-of-dimensionality math (section 7) works a 21-attribute persona down to roughly 134 people
           in the whole United States. Add a field only when it would change a design decision. -->


- Name: {{persona_name}}
- Role: {{persona_role}}
- Quote: "{{persona_quote}}"
- Background: {{persona_background}}


## Goals and Motivations


<!-- WHAT  The goals and motivations that come from actually talking to people in this role, not from what
           the team assumes they want.
     WHY   Nielsen Norman Group states the baseline plainly: personas must be based on user research to
           accurately represent a product's users. This section is where that standard is tested hardest,
           because an invented goal reads exactly like a researched one until someone asks for the evidence
           column. Deep dive: user-persona_companion.md section 3 (Anatomy > Goals and Motivations).
     ASK   What is this person trying to accomplish? Why does it matter to them specifically, not to the
           product team? How do you know, an interview, a support-ticket pattern, a field observation?
     PRIORITY  Order goals by how often they surfaced in your research, not by how well they justify a
           feature already planned. A goal with no evidence column filled in is a guess wearing a goal's
           shape.
     ROW HINT  A good row states a goal a real person would recognize as their own, why it matters to them,
           and where you learned it. A weak row is a goal that only makes sense from the product's point of
           view.
     GOOD  | Know who won't show up before the trucks arrive | A single missed no-show cascades into a
           missed dock window | March 2026 shift-lead interviews (n=9), raised by 7 of 9 |
     WEAK  | Wants better visibility | | |
     TRAP  Writing goals the product team already wants to hear, rather than goals a real interview actually
           produced. If every goal in this table happens to match a feature already on the roadmap, that is
           worth noticing, not celebrating. -->


| Goal | Why it matters | Evidence (how you know) |
|---|---|---|
| {{goal_statement}} | {{goal_rationale}} | {{goal_evidence}} |


## Pains and Barriers


<!-- WHAT  The obstacles and frustrations paired with the goals above, each with enough evidence that a
           reader could go check it.
     WHY   Every published format this research read pairs a goals field with an obstacles field; the pair
           is what turns an identity sketch into something a team can actually design against. This section
           is also the one most exposed to the equity critique the research found: naming, imagery, and
           accessibility are three concrete bias vectors in how pains get written. Deep dive:
           user-persona_companion.md section 3 (Anatomy > Pains and Barriers), section 7 (anti-patterns).
     ASK   What gets in the way of the goals above? What does it cost this person when it happens? Where did
           you observe or hear this?
     PRIORITY  Order by how much the barrier actually blocks the goal it pairs with. A barrier that never
           surfaced in research does not belong here no matter how plausible it sounds.
     ROW HINT  A good row names a specific obstacle, its concrete impact, and its source. A weak row is a
           vague complaint with no evidence.
     GOOD  | The scheduling board only updates from a desktop terminal | Finds out about a no-show after the
           shift has already started, not before | March 2026 shift-lead interviews (n=9) |
     WEAK  | Communication could be better | | |
     TRAP  Writing pains and barriers that quietly exclude disability. A persona that never names a
           disability-related barrier for a broad user base is making a choice, not an omission. -->


| Pain or Barrier | Impact | Evidence (how you know) |
|---|---|---|
| {{pain_statement}} | {{pain_impact}} | {{pain_evidence}} |

Provenance

Section titled “Provenance”

The reasoning, the history and every source, in the repository:

  • Companion - the long-form argument: why these sections, where the sources disagree, and what the bundle refuses to claim
  • History - what changed in this bundle, and when
  • Research log - every source consulted, with what each one actually supports
  • Catalog metadata - the machine-readable record this page is generated from

Catalog record: 6 sections across 1 format(s), methodology design thinking, typically owned by UX Researcher / PMM.