Personas

10 min read

Personas

A fictional character based on real research that represents a key type of person who will use your product — their goals, behaviours, frustrations, and context.

What is a persona?

A persona is a research-based portrait of someone who will use what you build. It is not a demographic profile. It is not a guess. It is a composite character distilled from real conversations, observations, and data about the people you are designing for.1

Alan Cooper, the software designer who introduced personas to the industry in 1999, developed the method because he noticed that teams kept designing for an abstract “user” — a word so vague it meant something different to every person in the room. When he replaced “the user” with a named character with specific goals and frustrations, the team stopped arguing about opinions and started solving for a real person.2

A persona typically includes:

ComponentWhat it capturesExample
Name and contextWho this person is and their situation”Amara, 34, runs a community garden cooperative”
GoalsWhat they are trying to achieve”Coordinate volunteer schedules without spending hours on admin”
FrustrationsWhat gets in their way”Current tools assume technical knowledge she doesn’t have”
BehavioursHow they currently work”Uses WhatsApp groups and paper sign-up sheets”
ContextWhen, where, and how they interact”Manages everything from her phone between tasks”

The point is not the fictional name. The point is that every design decision can now be tested against a specific person: “Would Amara understand this screen? Would this solve her problem or add to it?”

In plain terms

A persona is like a casting brief for a film. Before you shoot a scene, you need to know who the character is — their motivations, their obstacles, their daily life. Without it, the actors improvise and the scene goes nowhere. A persona gives your product a character to design for.

At a glance

How do personas work?

Research comes first

A persona without research is a guess in a costume. The whole point is to replace assumptions with evidence. The research does not need to be expensive or academic — even five conversations with real users reveal patterns that no amount of brainstorming can produce.3

Common research methods:

MethodWhat it revealsEffort
User interviewsGoals, frustrations, mental models, language5-10 conversations, 30 min each
ObservationWhat people actually do (often different from what they say they do)Watching users in their environment
SurveysPatterns at scale: frequencies, preferences, demographicsOnline form sent to existing users
AnalyticsBehavioural data: what pages they visit, where they drop offRequires an existing product
Support logsReal pain points expressed in the user’s own wordsReview existing tickets or messages

Think of it like...

A doctor doesn’t prescribe treatment based on a hunch. They examine the patient first. Interviews and observation are your examination. The persona is your diagnosis.

Build from patterns, not individuals

You do not create one persona per person you interview. You look for patterns across multiple people — shared goals, shared frustrations, shared behaviours — and synthesise those into a composite character. If eight out of ten interviewees manage everything from their phone, that becomes a defining trait of the persona.1

The recommended number is small: one primary persona per product, with one or two secondary personas only when their needs meaningfully differ. More than four personas and the team cannot hold them in mind, which defeats the purpose.3

Goals over demographics

The most common mistake: defining personas by age, gender, and income instead of by what the person is trying to accomplish. Two people can be demographically identical and have completely different needs.4

A widely cited example: two men born in 1948, both raised in Britain, both wealthy, both famous, both married twice. One is King Charles III. The other is Ozzy Osbourne. Their demographic profiles are nearly identical. Their goals, frustrations, and behaviours could not be more different.4

The goal-first rule

A useful persona is defined by what the person wants to achieve and what stands in their way — not by their age, job title, or how many social media accounts they have. Demographics provide context. Goals drive design.

Proto-personas vs research-backed personas

Not every project starts with a full research cycle. A proto-persona is an assumption-based first draft — what the team believes about its users before doing research. It is useful as a starting point but dangerous as an endpoint.4

graph LR
    A[Proto-persona] -->|validated by| B[Research]
    B --> C[Research-backed persona]
    A -->|used without research| D[Educated guess]

    style C fill:#5cb85c,color:#fff
    style D fill:#e74c3c,color:#fff

Proto-personas are honest about their limitations: “We think our user is like this. Let’s find out if we’re right.” The problem arises when teams skip the finding-out part and treat assumptions as facts.

Rule of thumb for proto-personas

A proto-persona is a hypothesis. Treat it like one: state it clearly, then test it. If you have spoken to zero users, your persona is a proto-persona regardless of how detailed it looks.

UX personas vs marketing personas

These serve different purposes and should not be confused:3

UX personaMarketing persona
Core questionWhat does this person need to accomplish?What does this person need to hear to buy?
FocusBehaviour, goals, frustrations, contextDemographics, purchasing triggers, messaging
DrivesProduct design, feature decisions, information architectureAd targeting, content strategy, pricing
Research sourceInterviews, observation, usability testsMarket research, sales data, analytics

A product needs both, but they are different tools for different teams. A marketing persona tells you who to reach. A UX persona tells you what to build for them.

Why do we use personas?

Key reasons

1. They replace “the user” with a real person. “The user wants…” is vague enough to mean anything. “Amara wants to coordinate volunteers from her phone without learning new software” is specific enough to design for.2

2. They align the team. When everyone designs for the same named person, arguments shift from “I think…” to “Would Amara understand this?” Decisions become testable, not political.1

3. They prevent self-referential design. You are not your user. Your technical fluency, your assumptions, your preferences are not theirs. A persona is a constant reminder of this gap.

4. They make AI-assisted building better. When you give an AI tool a clear persona in your requirements, the AI stops generating generic interfaces and produces output tailored to a specific person’s needs and context.5

When do we use personas?

  • Before writing a prd — the persona defines who you are building for
  • Before designing screens — every layout decision should pass the “would this person understand this?” test
  • When building with AI — include the persona in your prompt or requirements document to focus the AI’s output5
  • When the team disagrees about a feature — test the decision against the persona’s goals
  • When prioritising what to build next — the persona’s top frustration is your top priority

Rule of thumb

If you cannot name the person you are building for and describe their top goal in one sentence, you are not ready to design or build anything yet.

How can I think about personas?

The casting brief

Imagine you are producing a short film. Before the cameras roll, you write a casting brief for the lead character: their background, their motivation, what they are struggling with, how they speak, what frustrates them.

A persona is a casting brief for the person who will use your product. The “film” is the experience you are building. Without the brief, every team member imagines a different character — and the product ends up serving none of them well.

  • Research = watching real people live their lives
  • Patterns = noticing what the best candidates have in common
  • Persona = the composite character the team designs for
  • Goals = what the character wants in the story
  • Frustrations = the obstacles the plot must overcome

The compass

A persona is a compass for decisions. When you are lost in the forest of feature requests, stakeholder opinions, and technical possibilities, the persona points north.

“Should we add this feature?” Check the compass: does Amara need it? “Should this button be here?” Check the compass: would Amara find it? “Should we support desktop first?” Check the compass: Amara manages everything from her phone.

Without the compass, every path looks equally valid. With it, most decisions become obvious.

Concepts to explore next

ConceptWhat it coversStatus
user-journey-mappingMapping the complete experience across time, not just screensstub
mental-modelsThe internal maps users carry about how things workstub
design-thinkingThe empathise-define-ideate-prototype-test cyclestub
user-storiesTranslating persona goals into buildable requirementscomplete

Some of these cards don't exist yet

They’ll be created as the knowledge system grows. A broken link is a placeholder for future learning, not an error.

Check your understanding

Where this concept fits

Position in the knowledge graph 

graph TD
    UX[User Experience] --> P[Personas]
    UX --> JM[User Journey Mapping]
    UX --> DT[Design Thinking]
    UX --> MM[Mental Models]
    P --> US[User Stories]
    P --> PRD[Product Requirements]
    P -.->|informs| JM
    P -.->|grounds| DT
    style P fill:#4a9ede,color:#fff

Related concepts:

  • user-journey-mapping — personas are the “who” in a journey map; the map is the “what they experience”
  • design-thinking — personas emerge from the empathise stage and ground every stage that follows
  • mental-models — a persona captures the user’s existing mental model, which the design must align with
  • user-stories — the persona’s goals translate directly into user stories (“As Amara, I want…”)
  • prd — the persona defines who the product is for, which shapes every requirement in the PRD

Sources

Further reading

Resources

Footnotes

  1. Dam, R.F. and Teo, Y.S. (2025). Personas — A Simple Introduction. Interaction Design Foundation. ↩ ↩2 ↩3

  2. Cooper, A. (2020). The Long Road to Inventing Design Personas. Medium. Cooper’s own account of developing the persona method from 1983, formalised in The Inmates Are Running the Asylum (1999). ↩ ↩2

  3. Interaction Design Foundation. (2025). How to Create Research-Backed User Personas. IxDF. Covers UX vs marketing personas, research methods, and the one-primary-persona recommendation. ↩ ↩2 ↩3

  4. Krawczyk, B. (2025). User Personas: Common Mistakes and How to Avoid Them. LogRocket Blog. Includes the King Charles/Ozzy Osbourne demographic equivalence example and the proto-persona distinction. ↩ ↩2 ↩3

  5. Vibe Sparking. (2025). Writing Persona-First Requirement Docs for Claude Code and Cursor. Demonstrates how including personas in AI tool requirements produces more focused, user-appropriate output. ↩ ↩2

Graph View

Backlinks