Persona

Definition

A persona is a fictionalised representation of a target user segment — based on research — capturing goals, behaviours, environment, and constraints in a single profile that design and product teams can reference when making decisions.

A persona is a tool for keeping decisions anchored to a specific person rather than "the user" in the abstract. When a team debates whether to add a feature, the question becomes "would this make Maya's job easier?" rather than "do users want this?". Maya's name, photo, role, goals, and frustrations come from real interview data — she's a composite, not an invention.

Personas have a deserved bad reputation when invented from team opinion. Stock photos, alliterative names (Marketing Maya), and stereotypical pain points produce caricatures that nobody on the team actually consults. Personas earn their keep when they're built from interview transcripts, organised around behavioural patterns the team can validate, and revisited as the user base evolves.

Origin

Developed by Alan Cooper in the mid-1990s and popularised in his 1999 book The Inmates Are Running the Asylum. Cooper introduced personas as a tool for software designers to escape the trap of designing for "the user" — a fiction that lets every team member project their own assumptions.

How it works

Conduct 8–12 user interviews per audience segment, focused on goals and behaviours.
Cluster interview themes — what behavioural patterns repeat across multiple participants?
Each cluster becomes one persona; give it a name, photo, role, and one-paragraph backstory.
Document goals (what they're trying to accomplish), pains (what blocks them), and behaviours (what they actually do today).
Validate the personas by sharing back with interviewed participants — do they recognise themselves?
Use personas in product reviews — every feature decision references which personas it serves.

When to use it

Use when

When the team is making product decisions for an audience they don't share lived experience with.
Before designing a new product line targeting a different segment.
During cross-functional alignment — personas give marketing, sales, and product a shared reference.

Skip when

Without interviews to back them. Invented personas mislead worse than no personas.
On products with one tightly-defined buyer. "Our user is a CTO at a 50–500 person SaaS company" may be enough.

Key metrics

Decisions made with explicit persona reference (signal of adoption).
Persona accuracy — when shown to real users, do they recognise themselves?
Persona freshness — last validated within the last 12 months?

Examples

The B2B persona never opens an email on a phone — that changed the email design entirely.
Personas live or die by the research behind them; invented ones are just stereotypes with photos.
We rejected three feature proposals because none mapped to either persona's goals.

In practice at Makreate

Makreate uses personas as decision filters. On a recent healthtech engagement we shipped two personas — a 34-year-old fitness enthusiast tracking marathon training, and a 58-year-old recovering from cardiac surgery using the same app for prescribed exercise. Same product surface, drastically different needs. Every screen got reviewed against both: the marathon trainer wanted speed and customisation; the cardiac patient wanted reassurance and clear next steps. Several features that served only one segment got de-prioritised in favour of dual-purpose work.

UX Design →

Common mistakes

Building personas from team opinion. That's a stereotype with a photo.
Demographic-only personas. Age and gender rarely predict behaviour the way goals and constraints do.
Too many personas. 2–4 is manageable; 8 is decoration.
Forgetting to update them. Personas decay as the audience evolves.
Using personas as marketing personas (psychographic segments) when you need product personas (behaviour-based).

Frequently asked

How many personas should we have?

2–4 is typical. Each one needs distinct goals and behaviours — if two personas would make the same product decisions, collapse them.

Do we need photos and names?

Yes — they make the persona memorable and human. The team will reference "Maya" in meetings; nobody references "Persona 2".

How often should we update personas?

Revalidate annually, fully rebuild every 2–3 years or whenever the product's audience expands meaningfully.