Personas are design tools, not stock characters. This companion draws on Cooper, Pruitt and Adlin, Goodwin, Holmes, and the empirical literature that has tested whether personas actually improve design outcomes.
A persona stands in for a segment of real users when the team cannot have those real users in the room. It is a tool for design decision-making, not a description of any single person.
Alan Cooper, who introduced personas to interaction design, calls them user models and emphasises that "personas are not real people, but they are based on the behaviours and motivations of real people we have observed and represent them throughout the design process" (Cooper, Reimann, Cronin, and Noessel, About Face, 4th ed., 2014). The persona is a hypothesis about a kind of user, grounded in research, given a name and a face so the team can refer to it concretely.
Three confusions to clear up immediately.
Market segments group people by what they buy, how much they spend, where they live, or which demographic boxes they tick. Personas group people by what they are trying to do, how they currently do it, what frustrates them, and what would help. Two users who fit the same market segment can have entirely different personas; two users in different market segments can share a persona.
A stereotype assumes traits from category membership ("students are forgetful", "older users are slow"). A persona is built from observed behaviour patterns in a specific research sample. Where stereotyping fills in gaps with assumption, personas mark gaps explicitly and either close them with more research or restrict the design's claims accordingly.
Real users vary; a persona is a synthesis. Pruitt and Adlin (The Persona Lifecycle, 2006) describe the persona as "a composite character based on patterns observed across many users." Treat any single observation as data that may revise the persona rather than as the persona itself. Conversely, the persona is no substitute for ongoing user research; it is a way of carrying research into the design conversation.
"Personas are not real people, but they represent them throughout the design process. They are hypothetical archetypes of actual users."
Alan Cooper, Robert Reimann, David Cronin, and Christopher Noessel. About Face: The Essentials of Interaction Design, 4th edition. Wiley, 2014.Personas were not the product of an academic programme. They emerged from design consultancy in the 1990s, were popularised through a trade book, were adopted internally at large software companies, and only later acquired an academic literature.
Cooper has described introducing personas in his consultancy work as a response to a recurring problem: software teams designed for "the user" as an abstraction, which in practice meant designing for themselves. In The Inmates Are Running the Asylum (1999), he argued that designing for everyone produces software that no one particularly wants, and proposed personas as a discipline that forces a team to commit to a specific kind of person.
Cooper's approach moved into the academic and industry mainstream through three channels:
Goodwin's Designing for the Digital Age (2009), written from inside Cooper Interaction Design, gives a closely related but slightly different methodology emphasising behavioural variables and the synthesis step. Modern textbook treatments tend to blend Cooper's, Pruitt and Adlin's, and Goodwin's formulations.
The sequence matters because personas were a practitioner artefact before they were a research subject. Some of the criticism the method has received (see Section ix) is, in part, that it was widely adopted before it was empirically validated.
Every field on a persona either changes a design decision or it does not belong there. The seven components below appear consistently across Cooper, Goodwin, and Pruitt and Adlin.
A specific name and a representative photograph anchor the persona in the team's memory. The cognitive effect is documented: teams refer to "Aysha" in design reviews where they would otherwise say "the user", and the conversation becomes more concrete.
How this person currently does the task. Frequency, sequence, tools used, workarounds adopted. The behavioural pattern is what distinguishes one persona from another and what most directly informs design decisions.
Cooper distinguishes three layers: end goals (what they want to accomplish in the task), experience goals (how they want to feel), and life goals (what they care about beyond the task). Most design decisions hinge on end goals; experience goals shape tone and pacing.
Where the task happens, on what device, under which constraints. A booking task done one-handed on a phone in a hospital corridor is a different design problem from the same task at a desk on a wide screen.
What currently fails for this person. Each frustration is a design opportunity, and a persona without explicit frustrations tends to drift toward an idealised user the product cannot serve.
A short verbatim quote from research (or a paraphrase clearly labelled as such) that captures this persona's voice. The quote provides a sanity check during design reviews: would this person actually say this about our proposed feature?
The relevant technical literacy, domain expertise, and assumed prior knowledge. This is the field that most often distinguishes primary from secondary personas in the same domain.
It is easier to specify what a persona should not contain than to enumerate every possible field. The test is the same test for any field: would changing this information change a design decision? If not, omit it.
Cooper's terminology distinguishes design personas from marketing personas. The two have different fields because they support different decisions. Conflating them is a common pitfall (Section x).
Cooper's classification is widely adopted and gives a useful vocabulary for prioritising design decisions when more than one persona is in play.
| Type | Definition | Design implication |
|---|---|---|
| Primary | The persona whose needs cannot be met by designing for any other persona on the list. Cooper insists that "primary" is a relationship, not a popularity contest: a primary persona requires its own dedicated interface. | The design is built for this persona; every decision is justified against their goals and behaviour. |
| Secondary | A persona who would be satisfied by the primary's interface, but has additional needs not directly served by it. Secondary personas accept compromises on the primary's behalf. | Address their additional needs where doing so does not weaken the primary's experience. |
| Supplemental | A persona whose needs are entirely covered by a combination of needs already addressed for primaries and secondaries. | No specific design effort required; mentioned for completeness. |
| Customer | A person who decides to acquire or pay for the product but does not use it. An IT director purchasing software for the team. | Their concerns (security, cost, manageability) shape parts of the product they themselves do not touch. |
| Served | People affected by the product without using it. The students of a teacher who uses grading software; the patients of a doctor using an appointment system. | Their interests should constrain decisions even though they will not see the interface. |
| Negative (anti-persona) | A persona explicitly not designed for. Used to make the design's exclusions visible. | Useful when a project under pressure to "serve everyone" needs to legitimise scoping choices. |
On the primary persona. A project should usually have exactly one primary persona. If there are two, the project probably needs two products, or the design will end up serving neither well. Cooper is firm on this point because adopting it tends to clarify projects rather than constrain them: the discipline of choosing one primary often reveals that two of the supposed primaries are really one secondary and one customer, or one primary and one negative persona.
The published recommendations cluster tightly around the same range. They are not arbitrary: they reflect what teams can actually keep in working memory as they design.
| Source | Recommendation |
|---|---|
| Cooper, Reimann, Cronin, and Noessel (2014) | Typically three to seven personas per project; only one primary. |
| Goodwin (2009) | Rarely more than seven; project complexity is the main determinant. |
| Pruitt and Adlin (2006) | Range of three to six is common; large enterprise products may exceed this, but communication suffers. |
| Industry practice (UX teams) | Three to five primary personas is the modal answer in survey reports across the 2010s. |
Fewer than three almost always means the team has merged distinct user segments that have meaningfully different behaviour. The cost is that design decisions about details that matter to one segment get made against a composite "average user" who does not exist.
More than seven degrades team adoption. Pruitt and Grudin (2003) report that at Microsoft, internal teams found six personas already pushed the limit of what could be discussed in a single design meeting; beyond that, only a couple of personas were referenced in practice and the rest became dead documentation. The empirical study by Matthews, Judge, and Whittaker (CHI 2012) found that even modest persona sets (three to five) were often consulted partially: teams remembered a couple and used those, regardless of how many had been defined.
For a course project of the scale of COMP322 (a single product, three to four students, one semester), two to four personas is appropriate, with one designated primary. Going beyond four for a project of that size usually signals weak segmentation rather than richer user understanding. Naming personas after distinct behavioural patterns, not demographic groups, helps keep the count honest.
Most published methodologies share a common skeleton, even when the details vary. The work that adds value happens between the interviews and the persona cards, where raw observations are reduced to behaviour patterns.
The canonical pipeline, synthesising Cooper, Goodwin, and Pruitt and Adlin, has five phases:
A common error is clustering the codes, that is, grouping the open codes by what they are about rather than by which participants share them. The result is a list of themes ("usability concerns", "scheduling pressure") rather than a set of personas. Personas come from clustering participants, not codes.
The companion piece From interviews to personas takes you through the five phases on a small dataset (six interviewees, five variables, two primary personas). You can see what an open-coded interview looks like, why clustering by codes goes wrong, and how the persona cards are derived from a behavioural-variable matrix.
Open the interactive walkthrough →There is no rigorous answer. Common practitioner heuristics: aim for six to fifteen interview participants per expected persona; stop when additional interviews are no longer revealing new behaviour patterns (data saturation). Nielsen's older guidance for usability testing (five participants reveals most major issues) is sometimes invoked, but persona research has a different goal and the five-user heuristic does not transfer cleanly. Pruitt and Adlin recommend treating early personas as provisional and explicitly labelled as such until further research closes their gaps.
Kat Holmes and the Microsoft Inclusive Design team reframed disability as a relationship between a person and an environment rather than a fixed attribute. The reframing has a direct consequence for persona work.
In Mismatch: How Inclusion Shapes Design (MIT Press, 2018), Holmes argues that exclusion in design is rarely intentional; it follows from designing for a narrow imagined user. The Microsoft Inclusive Design Toolkit (2016) offers a practical antidote in the form of the Persona Spectrum, which represents any given limitation in three forms.
A condition that does not change. A user with one arm, or with congenital low vision, or who is deaf. The product's design must work for this person every time they use it.
A condition that lasts for a bounded period. A user with a broken wrist, a recent eye surgery, or temporary hearing loss after a loud concert.
A condition created by the environment. A user carrying a baby (one arm effectively unavailable), in glaring sunlight (low contrast), in a meeting (no audio output).
The empirical observation behind the Spectrum is that the population of people in any of the three categories is much larger than the permanent group alone, and that design accommodations for the permanent case typically benefit the temporary and situational cases too. Captions designed for deaf users are watched silently on phones; one-handed phone interactions designed for amputees serve parents with infants; high-contrast modes designed for low-vision users serve everyone in direct sunlight.
In persona terms, the Spectrum suggests that for each primary persona the team should also consider a Spectrum sibling. The result is not necessarily a separate persona, but a checklist applied to the existing primary: would the design still work if their permanent condition were a temporary or situational version of someone else's permanent condition?
"When we design for disability first, we often stumble upon solutions that are better than universal. Better, in the sense that when we remove the 'extra-ness' of accessibility, what's left is just plain good design."
Kat Holmes. Mismatch: How Inclusion Shapes Design. MIT Press, 2018.The literature contains both first-person reports from teams that used personas successfully and empirical studies that found their adoption uneven. Both are informative.
Pruitt and Grudin (2003) report on persona use at Microsoft across multiple product groups, including MSN Explorer and Windows. They argue that the visible payoff was not so much in design choices made differently because of a persona, but in cross-functional communication: engineering, marketing, support, and design referenced the same characters when discussing roadmap and trade-offs, which reduced talking past one another.
Their account is candid about limitations. Some product groups adopted personas symbolically, posting the cards on walls without referencing them in decisions. Others over-produced, generating dozens of personas the team could not keep distinct. The teams that benefited most treated personas as a living artefact, revised them as product knowledge grew, and made design decisions explicitly traceable to particular personas.
Long (2009) reports an experimental study with industrial-design students comparing groups who used personas to groups who did not, on a product-design exercise. The persona-using groups produced designs that were judged more usable on several criteria.
The study is one of relatively few experimental designs in the persona literature. Its design has limitations (student participants, short timescale, single product class), and the evidence base remains thin. The most that can fairly be said is that controlled experiments have not contradicted the practitioner consensus, but they have not yet provided the robust quantitative support the method's wide adoption might suggest.
Beyond Microsoft, persona-driven design has been documented across automotive interface work, public-sector service design, and large-scale software products. The published cases consistently report a similar pattern: personas pay off most when they are made traceable to design decisions and when they are kept alive through the project, and they pay off least when they are produced once and shelved.
The persona method has been challenged in the academic literature. The most cited critiques are worth engaging with honestly because they raise practical questions every persona-using team will face.
In a widely cited paper at the Human Factors and Ergonomics Society annual meeting, Chapman and Milham argued that personas, as commonly practised, are not scientific in the sense of being falsifiable. A persona is a composite character; there is no procedure for testing whether the composite is correct. The same data can support different syntheses, and different teams can produce different personas from the same interviews.
The objection is not that personas are useless, but that claims about their accuracy or representativeness need to be made cautiously. The practical response, adopted in most modern treatments, is to distinguish research-based personas (with explicit links to the underlying data) from provisional personas (assumption-based, clearly labelled as such), and to treat personas as design tools whose value is measured by the design decisions they enable, not by their truth value.
Matthews and colleagues interviewed designers and UX professionals about their actual use of personas in industry. Their findings are nuanced:
The study did not conclude that personas should be abandoned, but that they are most useful as one tool among several, calibrated to the team's existing practice rather than imposed wholesale.
Both Chapman and Milham and Matthews and colleagues converge on a practical recommendation that the persona-friendly literature has gradually absorbed: personas need to be grounded in research, kept lightweight enough that the team uses them, integrated with other design artefacts (scenarios, requirements), and updated as the project learns more about its users. A persona that is none of these things is a poster, not a tool.
These are not theoretical concerns; they are the recurring failure patterns documented across the practitioner and empirical literature.
Without research input, personas reflect the team's assumptions about users. They will then validate decisions the team would have made anyway. This is the single most common pitfall and the one Chapman and Milham reserved their sharpest criticism for.
Naming a persona "elderly Aysha" or "tech-savvy Saleh" embeds stereotypes that the persona was supposed to displace. Behaviour patterns, not demographic categories, should drive segmentation.
Beyond seven, teams cannot keep distinctions clear in design meetings. Personas added "for completeness" generally go unused. Most projects need three to five total.
Personas produced after major design decisions are made tend to be tailored, perhaps unconsciously, to justify those decisions. Create personas before, not after.
Glossy persona posters with brand alignments and aspirational quotes drift toward marketing personas. Marketing personas are useful but answer different questions; the design team needs design personas.
"All of our personas are equally important" usually means none of them is. Without a primary, the design ends up serving an average that no real user matches.
Personas drafted at the start of a project but never revised quickly diverge from a maturing understanding of users. Pruitt and Adlin's lifecycle model is the canonical answer (Section xi).
Personas should leave a trace. Major design decisions should cite which persona they prioritised and why. Personas that never appear in design rationale are not being used; they are decoration.
Pruitt and Adlin's The Persona Lifecycle (2006) treats persona work as a multi-phase process that begins before research and continues past product launch. Even on smaller projects, the lifecycle framing usefully discourages the "draft once, forget" pattern.
| Phase | What happens |
|---|---|
| Planning | The team decides which design questions personas will help answer, who needs to be interviewed, what behavioural variables matter. The plan is a hypothesis open to revision. |
| Conception and gestation | Research is conducted (interviews, observation, contextual inquiry). Raw data is coded; behaviour patterns are identified; provisional personas may be sketched. |
| Birth and maturation | Personas are formalised on cards, validated against stakeholders and additional users, and circulated through the team. This is where the persona becomes a shared artefact rather than the lead researcher's private knowledge. |
| Adulthood | Personas are used in design reviews, prioritisation meetings, and feature scoping. Design decisions cite the persona they prioritise. Conflicts between personas surface trade-offs the team must resolve. |
| Retirement | Personas no longer matching the user base are explicitly retired. New personas may be created. The team learns which personas were predictive and which were not; that knowledge informs the next round. |
A persona that is never validated against new evidence drifts. Validation does not require a heavyweight study; the most useful checks are continuous and lightweight:
The persona, in this view, is not a one-off deliverable. It is a piece of the team's working memory of its users, maintained with the same care as any other long-lived artefact.
The seven components are easier to recognise on a finished card than to construct from scratch. The example below is a research-grounded synthesis for a hypothetical online-banking redesign; every component is the kind of statement that would, in real work, be traceable to specific interview or observation notes.
I do my banking between meetings on my phone. If it takes longer than the lift ride, I will not finish.
Checks balances three or four times a week, almost always on her phone in short bursts (under two minutes). Pays utility bills in batches at the start of each month. Transfers money to family members several times a year, always with a note. Reviews monthly statements at her laptop on Sundays, alongside her household ledger spreadsheet.
Mostly used on a phone, one-handed, in transitional moments (waiting for a meeting, walking to her car, between bedtime stories). Occasionally on her work laptop in the evening for monthly reconciliation. Network conditions vary; the app sometimes loses connection in the building's lift.
High financial literacy (accountant); high digital literacy generally; comfortable with web forms, less comfortable with new app patterns she has not seen before. Knows what an IBAN is and can read a statement; does not need the app to explain those.
Read against the seven-component anatomy from Section iii, the card includes only fields that change a design decision. The age and location are present because the bank's branch network and the regulatory regime depend on them. The number of young children is present because it explains why short-burst use dominates and why one-handed operation matters. The mention of the household ledger is present because it constrains the receipt and statement workflows. The fact that Layla speaks Arabic and English changes localisation and right-to-left layout decisions.
Equally, the card does not contain her favourite colour, the names of her children, or her preferred coffee. None of those would change a design decision; they would simply make the card feel novelistic. Pruitt and Adlin (2006) call this the "fact-fiction distinction": persona fields should be facts about a class of users (synthesised from research), not fiction about a single character.
Two publicly documented cases are worth knowing in detail because they show what success looks like with personas of this form.
Microsoft, across product groups (Pruitt and Grudin, 2003). Pruitt and Grudin's DUX 2003 paper is the most widely cited industry account of persona use. They report that the teams that benefited used personas as cross-functional communication aids: engineering, marketing, support, and design referenced the same named characters in roadmap meetings, which reduced talking past one another. The visible payoff was less in any single design decision and more in how the team scoped, prioritised, and reviewed work. The characters themselves were named, with photos, demographics, and behaviour patterns built from large research samples, much like the Layla card above.
Microsoft Inclusive Design Toolkit (2016). The Toolkit, published openly by Microsoft Design, contains a now-canonical set of inclusive personas built around the Persona Spectrum (Section vii): a person with one arm; a person with a temporary arm injury; a parent holding a baby; a person carrying groceries. Each character is presented with a name, an illustration, and a short behavioural description. The Toolkit was adopted across Microsoft and influenced accessibility-driven design in many other companies because it gave designers concrete characters to reason about, not abstract guidelines.
In both cases the success pattern is the one Section viii identified: personas grounded in research, used continuously, integrated with other artefacts, and revised as the team learned more.
The same Microsoft groups produced personas that nobody used. Pruitt and Grudin are candid about this: some teams adopted personas symbolically (printed them, pinned them to walls, then ignored them), and some over-produced (dozens of personas the team could not keep distinct). The Matthews, Judge, and Whittaker CHI 2012 interview study found the same patterns industry-wide: personas frequently competed with other artefacts, were sometimes felt to oversimplify users misleadingly, and were rarely used in the rigorous, sustained way the textbook recommends.
The lesson is not that personas of Layla's form are unreliable. The lesson is that the form is necessary but not sufficient. A well-constructed persona that the team does not consult is the same as no persona at all, and a well-constructed persona used to decorate a slide deck has the same effect as a wrong persona used in earnest.
A finished persona is not the end of the design process; it is the beginning of the next stage. The card above generates scenarios (what does Layla actually do on a Tuesday morning?) and from those, requirements (what must the system measurably do or be to support her?). That pipeline is the subject of the next companion: Scenarios and requirements.
For the step-by-step construction of a persona like Layla from raw interview data, the From interviews to personas walkthrough takes the same banking research scenario through eight stages of synthesis.
Layla's card answers who the design is for. The next companion takes that answer and turns it into what the system must do, by way of scenarios and verifiable requirements.
Open companion →The citations below are the works directly referenced in the text above. The course textbook and recommended further reading are marked.