A research-based, fictional stand-in for a key segment — built for behavioural specificity, not demographic accuracy. It makes an abstract market a person the team can design for.
▸ Try the interactive toolA persona is a fictional, research-based representation of a key user segment. It makes abstract segments concrete, memorable, and emotionally resonant for the team. The goal isn't demographic accuracy — it's behavioural specificity: what this person actually does, feels, and struggles with when they encounter the problem your product solves.
A good persona is built from real research (interviews, segmentation) and earns its place by changing decisions: when the team debates a feature, the persona settles it by asking “would this person actually use it, given how they behave?” A persona stuffed with demographics but no behaviour is a poster; a persona grounded in real goals, frustrations, and context is a decision-making tool.
Not just age and job title, but: the goal they're trying to achieve, the frustrations blocking them, their behaviour and context around the problem, and how they'd judge success. Behaviour over demographics.
Personas fail in two ways: too vague to guide anything, or too demographic to predict behaviour. The template aims at the behavioural middle.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Designing for “the user” | An abstract average user leads to compromise designs that fit no one. | A concrete persona gives the team a specific person to satisfy. |
| Demographics-only personas | Age and job title don't predict how someone behaves with your product. | Behavioural specificity — goals, frustrations, context — actually guides design. |
| Invented, unresearched personas | A made-up persona just encodes the team's assumptions. | Research-grounded personas reflect real users, not internal bias. |
| Too many personas | A dozen personas guide nothing; the team can't hold them all. | A small set of well-chosen personas keeps decisions focused. |
Build each persona on a segment identified through segmentation and validated in research — not on a hunch. One persona per priority segment.
What is this person actually trying to accomplish when they meet your product's problem? Frame it as an outcome, echoing JTBD, not a feature wish.
What blocks them today? What's their situation, environment, and constraint? This behavioural detail is what makes the persona usable.
Include demographic detail only where it actually affects behaviour. Resist filling in a profile picture's worth of irrelevant facts.
Test the persona against real product debates: does invoking it actually settle questions? If it doesn't change any decision, it's decoration — sharpen it.
A team had a glossy persona — name, age, stock photo, hobbies — that never came up in a single product decision. It described a demographic but predicted no behaviour, so it sat on a wall doing nothing.
Rebuilding it from interview data, they stripped the irrelevant demographics and centred it on one behavioural truth: this user tried the product in stolen moments between other tasks and abandoned anything that took more than a minute to show value. Suddenly the persona had teeth — it killed several heavyweight features and justified a fast-value redesign.
The deliverable is a one-page card per priority segment — goal, frustrations, behaviour, context — light on demographics, heavy on what predicts decisions.
| Element | Weak version | Strong version |
|---|---|---|
| Identity | Name, age, stock photo | A segment-grounded behavioural profile |
| Goal | “Wants a good experience” | A specific outcome they're hiring you for |
| Frustration | Generic gripes | The real blocker, from research |
| Test | Looks nice on a wall | Actually settles product debates |
A persona earns its keep by ending arguments. If invoking it doesn't change what the team decides to build, it's a decoration — and most demographic-heavy personas are exactly that.
The shift that makes personas work is from who the user is to how the user behaves around the problem. Demographics are easy to gather and feel concrete, but they rarely predict whether someone will adopt a feature. Behaviour, context, and the job-to-be-done do. A persona grounded in those — and validated by checking that it actually resolves real decisions — becomes the team's shared shorthand for the customer, which is the entire point.
Age and title rarely predict product behaviour. Lead with goals, frustrations, and context.
An unresearched persona just hardens the team's assumptions. Ground it in interviews.
More than a handful and the team can't use them. Focus on priority segments.
If it never changes a decision, it's a poster. Validate that it has teeth.
Each persona makes one chosen segment (Tool 05) concrete and human.
The empathy map (Tool 14) goes deeper into one persona's inner world — what they think, feel, see, hear.
When personas want different things, the primary/secondary/negative framework (Tool 13) decides who wins.
The persona's goal is the job-to-be-done from Module 1 — personas and JTBD are complementary views.
Take any persona (yours or a template). Cross out every demographic detail that doesn't change how the person behaves with the product. See what survives.
What's left should be goals, frustrations, and behavioural context. If almost nothing survives, the persona was decoration.
The test of a persona isn't how complete the profile looks — it's whether what survives this strip-down could actually settle a real product debate.