Personas, and what they are missing

What a persona is

A persona is a fictional individual, described as though they were real, standing in for a group of users. It has a name, a photograph, an age, a job, a level of confidence with technology, and above all a set of goals. Teams write two or three of them and then design for those characters rather than for an abstraction.

The technique comes from Alan Cooper, who introduced it in The Inmates Are Running the Asylum in 1999 to solve a specific problem he called the elastic user. When a team says “the user”, the phrase stretches to fit whatever the speaker wants: the user is expert enough to cope with this interface, and novice enough to need that wizard, in the same meeting. Naming a character stops the stretching. Someone can be asked whether a design suits that person, and cannot silently redefine them halfway through the argument.

That is a real problem and personas do solve it. Most of the criticism that follows is not about whether the technique does anything; it is about what the technique licenses people to claim.

Personas are asked to do three jobs and succeed at them unequally. The first is communication, giving a team a shared referent that is harder to bend than a category. The second is empathy, making designers care about somebody who is not themselves. The third is decision, settling arguments about what to build. The methodological literature is largely a fight about the third.

The methodological objection

The standing critique is Chapman and Milham’s, from 2006, and its title tells you the tone: The Personas’ New Clothes. Their argument is that a persona is a fiction, and a fiction cannot be verified or falsified, so it has no demonstrable validity. They set out three failures.

A persona cannot be checked. There is no observation that would show a persona to be wrong, because there is nobody it is a description of. A persona’s relationship to a real population is unclear: it is impossible to say how many actual users, if any, a given persona resembles. And inference from a highly specific individual is unsound, because the specificity that makes a persona vivid is exactly what makes it unrepresentative.

Two years later the same group made the third point numerically. Working across six survey datasets ranging from 268 to 10,307 respondents, they measured how many real people match a persona-like description as attributes are added to it. The expected prevalence falls away rapidly. A persona described richly enough to feel like a person describes, in the limit, nobody at all.

That result is not an argument against detail. It is an argument against detail combined with a claim of representativeness, which is precisely what a persona makes when it says it stands in for a group. The trouble is not that Sarah has a name and a job. The trouble is asserting that Sarah is the users.

Chapman and Milham draw a further consequence. Because personas cannot be settled with data, disagreements about them get settled by seniority instead. A method meant to end arguments about the elastic user becomes a new thing to argue about, with no evidential procedure for resolution.

The case in favour

Pruitt and Grudin (at Microsoft) were promoting use of personas back in 2003, with Pruitt and Adlin setting the method out at book length in 2006, the same year as the above criticism rather than in answer to it. They ground the practice in a documented process: real research feeding persona creation, explicit assumptions written down, and ongoing use throughout a project rather than a poster made once and forgotten. Their position is that a persona is a communication artefact whose value lies in being used, and that judging it as though it were a statistical estimate is a category error.

The one piece of evidence that does come after the criticism is Nielsen and Storgaard Hansen’s 2014 study, which tested the practice empirically at scale and found personas genuinely in use and considered applicable by the teams using them. That is evidence about adoption rather than about validity, and is offered as such.

Both positions are reasonable and neither closes the hole. If a persona is a communication artefact rather than an estimate, then it cannot settle a question that needs evidence, and nothing in the method marks where the one use ends and the other begins. Twenty years on, the objection has not been answered on its own terms.

The data-driven answer, and its limits

The modern attempt to close the hole is to stop inventing personas and start deriving them. Jansen, Salminen and colleagues build personas by factorising very large behavioural datasets, tens of millions of interactions, into a small number of representative profiles, then attaching human attributes to the result. If a persona is a cluster centroid, the question “how many users does this represent” has an answer.

This is a real advance and it inherits two problems, of which the better known is the milder. Clustering tells you about the people in the dataset, and the people who could not use the product well enough to generate data are the ones an accessibility argument is about. A method that derives its users from engagement logs will under-represent anybody the current design already excludes.

The second problem is not an accident of collection, which is what makes it the harder one. These methods work by reduction. They look for the few profiles that account for the most variance and treat what is left as residual, and how many profiles to produce is a number somebody picks. Picking a small one is the entire point, because a hundred personas would be no more usable than the raw data was.

A minority is exactly what that arithmetic absorbs into a neighbouring cluster or discards. So disabled users are not merely under-collected in large datasets, they are pushed out by an analysis whose purpose is to find what most people have in common. The two problems compound: the data holds fewer of them than it should, and then the method is built to look past the ones it holds.

The same group has since worked on transparency, on explaining to practitioners where a generated persona came from, which suggests they know the inference is doing more work than it looks.

Personas and disability

The best-known accessibility use of personas is Microsoft’s persona spectrum, from Kat Holmes and the inclusive design work. It takes a limitation and draws it three ways: permanent, as somebody with one arm; temporary, as somebody with a broken wrist; and situational, as somebody holding a baby. The pitch is that designing for the permanent case serves all three, so inclusive design is not charity but reach.

It has done a great deal of good in getting the subject taken seriously, and it draws three criticisms.

It flattens. Disability arrives as one bullet on a card. A person is blind, and that is the whole of what the team knows, which is not enough to design anything and is enough to feel finished.

It essentialises. A categorical label collapses everyone it names into a supposed common experience, and misses how disability intersects with everything else about somebody.

The situational case crowds out the permanent one. This is the sharpest criticism and it comes from inside the practice. Once a team has understood that captions help in a noisy bar, it is easy for the noisy bar to become the working example, because it is the one everybody in the room has experienced. The person who has been Deaf since birth becomes a rhetorical device for making a point about everybody else.

There is also careful academic work on doing it better. Schulz and Fuglerud have written specifically on creating personas with disabilities, and there is a growing practice of co-creating personas with disabled people rather than about them, which addresses the invention problem at its source even if it leaves the representativeness problem where it was.

Where this work fits

I did not set out to fix personas. I set out to describe people to computers, in a capability model and a preference model. Reading the persona literature afterwards, the fit is closer than I expected, and specifically it is closest at the point the literature has been stuck on.

Two of those need more than a table cell.

The narrative I left out was left out for this reason. The eighteen worked profiles behind my capability model have no name, no age, no occupation and no story, because those invite generalising from a character to a population. I wrote that before reading Chapman and Milham, and it is their third objection arrived at from the opposite direction: they measured what specificity costs, and I had removed the specificity that was not earning anything.

A template is a constructor, not a classifier. The essentialising criticism lands on assigning somebody to a category and stopping. A generic profile here is a surface to build from: Fred is like Jim except, and the exceptions are recorded as a sequence of changes against the template. The mechanism that makes a template usable is the same one that moves away from it, so using it at all commits you to individualising it. That is structural rather than a promise, which is what makes it an answer rather than an apology.

It also produces a number personas cannot report. Not how many people this represents, which the model rightly declines to answer, but how much of this profile is this person: the changes against the template are readable, so the parts nobody ever asked about are visible as inherited rather than known.

Where it does not fit

A capability profile is not a persona and does not do a persona’s work. Three gaps matter.

Goals are missing entirely. What somebody is trying to achieve, what they know about the domain, how often they use the thing, what they are afraid of: none of that is in my capability model or my preference model, and a great deal of what personas are for lives there. A model of what a person can do and would rather says nothing about what they came to do.

Empathy is not served by a property table. The narrative I removed is the part that makes a designer care. A profile is a substrate; it is not a replacement for the thing that gets a room to take somebody seriously.

There is no population dimension. The data-driven school can say how common a profile is and this cannot. For prioritising work across a whole product that matters, and the honest answer is that population data is a different instrument, better suited to measuring what a design demands than to describing who is using it.

What I would actually propose

Not that capability models replace personas. That claim would be too strong and would lose the two things personas are good at.

A persona becomes a narrative laid over a checkable profile. The narrative does the communicating and the caring, and is explicitly not evidence. The profile is what a system reads and what a claim can be tested against. The two are kept apart in the way capability and preference are kept apart, and for the same reason: they answer different questions, and merging them lets one borrow authority it has not got.

That gives the practice something it has lacked since 1999. A designer can still say Sarah would struggle here, somebody can still ask what that claim rests on, and the answer is now a set of properties that could be taken to a real person and checked, rather than a paragraph nobody can argue with.

It also makes the invented parts visible as invented. A persona today mixes observation and invention in one paragraph with no seam. Separating the layers means the seam is where you can see it, which is the whole of what falsifiability asks for.

The risk in doing this

A table of properties looks more authoritative than a sketch of a person. The essentialising criticism bites hardest where a description gets mistaken for a verdict, and a formal profile is far easier to mistake that way than a paragraph about somebody called Sarah. Formalising the substrate raises the stakes on the rule rather than retiring it: the profile is an attempt to describe somebody from outside, it advises and does not decide, and the person it describes outranks it.

The other half of that rule is on the preference page, where a handset chosen during my master’s research had neither the largest keys nor the largest text, and I would not have predicted it from the profile I had recorded. A formal model is not a better oracle. It is a more honest record, and those are different things.

References

The method and its origin

• Cooper, A. (1999). The Inmates Are Running the Asylum. Sams Publishing. The origin of personas and of the elastic user.
• Pruitt, J. and Grudin, J. (2003). Personas: practice and theory. Proceedings of the 2003 Conference on Designing for User Experiences (DUX ’03). doi:10.1145/997078.997089
• Pruitt, J. and Adlin, T. (2006). The Persona Lifecycle: Keeping People in Mind Throughout Product Design. Morgan Kaufmann.
• Nielsen, L. and Storgaard Hansen, K. (2014). Personas is applicable: a study on the use of personas in Denmark. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI ’14), 1665–1674. doi:10.1145/2556288.2557080

The methodological critique

• Chapman, C. N. and Milham, R. P. (2006). The Personas’ New Clothes: methodological and practical arguments against a popular method. Proceedings of the Human Factors and Ergonomics Society Annual Meeting, 50(5). doi:10.1177/154193120605000503
• Chapman, C. N., Love, E., Milham, R. P., ElRif, P. and Alford, J. L. (2008). Quantitative evaluation of personas as information. Proceedings of the Human Factors and Ergonomics Society Annual Meeting, 52(16), 1107–1111. The prevalence study. doi:10.1177/154193120805201602

Data-driven personas

• Jansen, B. J., Salminen, J., Jung, S. and Guan, K. (2021). Data-Driven Personas. Synthesis Lectures on Human-Centered Informatics, Springer. doi:10.1007/978-3-031-02231-9
• Salminen, J., Santos, J. M., Jung, S.-G. and Eslami, M. (2019). Persona transparency: analyzing the impact of explanations on perceptions of data-driven personas. International Journal of Human–Computer Interaction. doi:10.1080/10447318.2019.1688946

Disability and inclusive design

• Holmes, K. (2018). Mismatch: How Inclusion Shapes Design. MIT Press. The persona spectrum.
• Schulz, T. and Fuglerud, K. S. (2020). Creating personas with disabilities. arXiv:2003.11875. arxiv.org/abs/2003.11875
• Microsoft Design. Inclusive Design. The published toolkit and activity cards. inclusive.microsoft.design