Definition
A persona is a concise, concrete description of a type of user, built from research, used as a reference point during design decisions. A useful persona states goals, the context in which the person works, their relevant skills and constraints, the behaviors that distinguish them from other users, and what would make the product fail them. It is a communication device, not a statistical summary: the individual described does not exist, but every characteristic should be traceable to evidence from real people. Personas are typically accompanied by a description of the research they came from, so a reader can judge how much weight to give them.
Why It Exists
Personas exist because teams make decisions for an abstraction called the user, and abstractions absorb whatever the speaker wants them to mean. In a meeting, users want simplicity and users want more control can be asserted with equal confidence about the same population. A persona forces specificity: this named type, with these goals and this level of expertise, in this situation. It also serves the elastic user problem Alan Cooper described — when the user is undefined, arguments are won by whoever redefines them most conveniently. A shared, evidence-based description makes it harder to invent a user who happens to want the feature under discussion.
Examples
- →A warehouse supervisor who checks stock on a phone while walking, wearing gloves, in poor signal conditions.
- →A first-time claimant applying for a benefit, unfamiliar with the terminology and anxious about making a mistake.
- →An administrator who configures the product once a quarter and forgets every setting between sessions.
- →A clinician using the system between patients, under time pressure, on a shared machine already logged in as someone else.
History
Alan Cooper introduced personas into software design practice in the 1990s, describing the technique in The Inmates Are Running the Asylum in 1999 as a way of designing for specific, named users rather than for an elastic abstraction. The idea drew on older market research archetypes but differed in purpose: Cooper's personas were derived from interviews and intended to drive interaction design decisions, not to segment a market for advertising. Kim Goodwin later documented a rigorous derivation process in Designing for the Digital Age, building personas from behavioral variables identified across research participants and mapping participants along those variables to find clusters rather than inventing types.
In Modern Design
Personas remain common and remain contested. The serious criticism is that they are frequently fabricated: teams produce a stock photograph, an invented name, an age, a favorite coffee, and a paragraph of personality, none of it drawn from research, and then treat the result as evidence. Such artifacts are worse than nothing, because they launder assumption as fact and can encode stereotypes about gender, age, ability and income. Demographic detail in particular is usually irrelevant to design and invites bias. Many teams have moved toward alternatives: jobs-to-be-done statements, behavioral archetypes without biography, or scenario and journey descriptions. Where personas survive well, they are behavior-based, few in number, and traceable to studies.
Real-World Example
Consider two personas for the same accounting product. One reads: Sarah, 34, marketing manager, enjoys yoga and flat whites, wants tools that make her life easier. It contains nothing that could change a design decision. The other reads: a bookkeeper who reconciles fifty client accounts monthly, works in batches for hours at a time, uses keyboard shortcuts heavily, and needs to prove a figure's origin when a client questions it months later. That second description makes concrete demands — batch operations, keyboard access, an audit trail — and would be contradicted by evidence if wrong. The difference is not writing quality; it is whether the persona was derived from watching people work.
Key Principles
- →Build personas from behavior observed in research, not from demographics or imagination.
- →Include only attributes that could change a design decision.
- →Keep the set small; more than a handful and the team stops using them.
- →Record the evidence behind each persona so readers can weigh its authority.
- →Watch for stereotype — invented biography encodes bias about gender, age, income and ability.
- →A persona is a tool for focus, not a substitute for continuing to talk to real users.
Why it matters
Used well, personas keep a team honest about who they are excluding, because a persona representing someone with low confidence, a screen reader, or intermittent connectivity makes that person's needs impossible to ignore in a planning discussion. Used badly, they do the opposite: they manufacture a convenient fictional customer who agrees with the roadmap and whose invented traits harden into assumptions nobody can question, since there is no evidence to argue with. Learning personas therefore means learning to ask where a description came from. That question — what is the evidence for this claim about users — is the durable skill, whether or not the persona format survives.
Then vs Now
Then
Personas were introduced to give software teams specific, research-derived users instead of an abstraction that could be redefined in any argument.
Now
Many are invented rather than researched, so teams increasingly demand traceable evidence or replace them with behavioral archetypes, job statements and scenarios.
Try it yourself
Interview four people who use the same tool in different circumstances. Do not ask about demographics. Instead, list six behavioral variables you notice — frequency of use, expertise, tolerance for error, time pressure, device, whether they work alone — and place each participant on each scale. Look for people who cluster. Write one persona for each cluster you actually find, restricted to behaviors, goals, context and failure conditions, with a note of which participants it came from. If a cluster is supported by one person, say so in the document rather than smoothing it over.