Persona

A persona is a fictional, archetypal representation of a target user, used in user-centered design and requirements engineering to keep product decisions anchored to the people the software is meant to serve. A persona distills findings from user research – interviews, surveys, and field observation – into a compact description of a representative user: their goals, behaviors, frustrations, environment, and the tasks they are trying to accomplish.

Personas are not real individuals, and they are not average users. Each persona stands for a segment of the audience that shares a recognizable pattern of needs and constraints. A product typically has a small number of personas – often between three and seven – that together cover the bulk of intended users. Each is given a name, a photograph, and a short narrative so that designers, developers, and stakeholders can ask "what would Maya do?" in concrete terms, rather than appealing to an abstract "the user".

The technique was popularized by Alan Cooper in The Inmates Are Running the Asylum (1999). Cooper argued that designing for a specific, vividly imagined persona produces more focused products than designing for a vague, all-purpose user.

Personas, actors, and real users

A persona is easily confused with two related ideas, and the distinction matters.

A use case actor names a role that interacts with the system – "customer", "administrator", "approver" – without describing the person behind the role. A persona enriches that role with motivations and context. The two are complementary: an actor answers "who triggers this interaction?", while a persona answers "who is this person, and why does it matter to them?"

A persona is also distinct from a domain expert. A domain expert understands the business the software models, and may never use the finished product. A persona represents an end user, whose understanding of the domain is often shallow but whose goals and frustrations are exactly what the design must serve.

How personas are used

Personas are a working artifact across several activities, rather than a single deliverable.

• In requirements elicitation, personas help teams prioritize features by asking which persona a proposed capability serves, and what it costs that persona if the capability is absent.
• In usability testing, personas guide the recruitment of participants who match the target segments, so findings generalize to the intended audience rather than to whoever was easiest to recruit.
• In a user story, the canonical "As a <role>, I want <capability>, so that <benefit>" template often names a persona as the role, tying the story to a researched user rather than an abstract one.
• In A/B testing, personas help interpret which segment a variant helps or harms, preventing an average uplift from masking a loss for a key user group.

Pitfalls

Personas degrade when they drift from evidence. The most common failure is inventing personas from the team’s assumptions rather than from user research, which merely dresses up guesswork in a sympathetic name and photograph. The second is letting a persona inventory grow stale: as the product and its audience move on, personas that were once accurate become a fossilized justification for decisions that no one re-examines. A persona is a hypothesis about users, and like any hypothesis it should be revisited against fresh research.

See also

• User-centered design
• Use case
• User story
• Usability testing
• Requirements engineering
• A/B testing

References

• Cooper, A. (1999). The Inmates Are Running the Asylum. Sams Publishing.
• Nielsen, J. (2019). Personas. Nielsen Norman Group.