Personas in Service Design: When They Help and When They Mislead
The persona is probably the most recognisable artefact in design. A name, a photograph, an age, a job and a short list of goals and frustrations, usually on a single page. Almost every team has made one, and many teams have a set on a wall that nobody has looked at for a year.
I do not think personas are useless, and I do not think they deserve the trust they are often given. This article looks at where they came from, what the criticism says, why services put them under particular strain, and what I would use alongside them.
Where personas came from
Alan Cooper introduced personas to software design in his 1999 book The Inmates Are Running the Asylum. His concern was that product teams, left alone, design for themselves. A specific imagined person gave them someone else to argue about. A few years later John Pruitt and Jonathan Grudin wrote up their experience of using personas at scale in a paper called Personas: Practice and Theory, and they were clear that the method complements other research methods. It does not replace them.
The Nielsen Norman Group's current definition keeps the original idea. A persona is a "fictional, yet realistic, description of a typical or target user of the product". Fictional and realistic are both doing work in that sentence, and most of the trouble comes from the tension between them.
Three kinds that look the same on the page
Page Laubheimer of the Nielsen Norman Group describes three types. A proto persona is built in a workshop from what the team already believes, with no new research. A qualitative persona is based on interviews. A statistical persona is based on survey data from a large sample.
These are very different levels of evidence, and the finished artefacts are almost indistinguishable. Each has a name, a face and some bullet points. A proto persona that was meant as a starting hypothesis gets printed, loses its caveat and becomes the person everyone designs for.
The first way personas mislead has nothing to do with whether the method is sound.
A persona cannot show its evidence on its face, so a guess and a finding end up looking equally true.
What the critics found
The sharpest academic criticism came from Christopher Chapman and Russell Milham in 2006. Their objection was about verification: "It is difficult to determine how many, if any, users are represented by a persona." Once several attributes are combined into one character, there may be very few real people who match all of them, and there is no simple way to check.
Indi Young made a different point in 2016, about the details teams choose to include. "Demographics can cause assumptions, shortcuts in thinking, and subconscious stereotypes by team members." An age and a job title feel like information. Often they invite the reader to fill in the rest from their own assumptions about people of that age in that job.
Kim Flaherty's analysis of why personas fail, also for the Nielsen Norman Group, lists causes that are mostly organisational. The personas are not used. Leadership never bought in. They were made by one team in isolation, communicated badly or pitched at the wrong scope. In other words, many persona failures are failures of the project around them.
Why services put extra strain on them
A product usually has a user. A service has a cast. The NHS service standard is explicit that the users of a health service include patients, carers, frontline staff and back office staff. A persona set that covers only the people on the receiving end leaves out everyone who makes the service happen, and their needs shape the outcome just as much.
Services also meet people in circumstances that change. The same person behaves very differently when applying for support on a calm afternoon and when applying the week after losing a job. A character sketch built on stable traits cannot hold that. Clayton Christensen and his co-authors made a related argument in Harvard Business Review in 2016, in their work on jobs to be done. People "hire" a product to make progress in a particular situation, and the situation explains their behaviour better than their demographic profile does.
There is a further problem in public services. A commercial product can choose its target customer. A public service has to work for everyone who is entitled to it, including the people for whom it is hardest. A persona of the typical user quietly points the team away from them.
What to use alongside them
None of this means throwing personas away. It means not asking one artefact to do everything.
→ User needs: the UK government's format is As a, I need to, So that, and it insists that good needs are "based on evidence from user research, not assumptions"
→ Situations: describe the circumstances people arrive in, such as doing it for the first time, in a hurry, or on behalf of someone else
→ Staff and partners: give the people who deliver the service the same attention as the people who receive it
→ An evidence label: mark every persona as assumed, interview based or survey based, with a date
The UK guidance itself does not reject personas. It refers to "user profiles or personas that describe groups of users with similar behaviour and needs". The grouping it has in mind is behaviour and needs. An age bracket and a job title do not appear in that sentence.
A fair test for a persona
Before relying on a persona, or making a new one, I would ask three questions. What evidence is it built on, and when was that evidence gathered? What decision has it changed? And if it were taken off the wall tomorrow, what would the team lose?
If the answers are a workshop, nothing and not much, the persona is decoration. If the answers are real, keep it, date it and check it again next year.
A persona is a summary of what a team believes about people, and it can only be as reliable as the evidence behind that belief.
Join The Curious Society Learning Path
Explore practical learning resources designed to help you build deeper knowledge, stronger judgement and real-world capability.
