Why User Personas Only Work When Someone Actually Uses Them

Walk into almost any product team’s shared drive and there is a good chance a set of personas sits there, complete with a stock photo, a made-up name, and a paragraph of “goals and frustrations” nobody has opened since the workshop that produced them. The problem is rarely that the personas were badly written. It is that they were built as a deliverable rather than a decision-making tool, and a document nobody consults during a roadmap argument was never going to change what gets built.

Key Takeaways

A persona only earns its place in a project if it gets referenced during actual decisions, such as prioritising a feature or resolving a disagreement about scope, not just at the kickoff workshop.
Personas built from real user research behave differently to those built from internal assumptions, because the former surface behaviours a team did not already expect.
A small number of well-differentiated personas, built around goals and behaviours, guides decisions better than a large set built around demographics alone.
Personas need revisiting as a product and its user base change, since a persona frozen at launch quietly stops representing anyone within a year or two.
The value of a persona is the shared reference point it gives a team, not the fictional biography itself; teams that skip straight to the biography often produce personas nobody uses.

None of this is an argument against personas. It is an argument against treating them as a workshop output rather than a working tool, and the difference between the two shows up less in how a persona is written than in how it gets used afterwards.

Personas exist to settle arguments, not to decorate a wall

The clearest test of whether a persona is doing its job is whether it gets pulled into a live disagreement. When a team is debating whether a feature request from one loud customer should jump the roadmap, a persona built on real research can answer the question a raw request cannot: does this reflect what most users in this segment actually need, or one person’s edge case. Nielsen Norman Group’s writing on personas makes exactly this point, describing their purpose as making a user group memorable enough that it gets considered automatically, without someone having to re-argue who the product is for every time a decision comes up.

That only works if the persona is specific enough to disagree with. A persona description so generic it could describe almost anyone settles nothing, because both sides of an argument can read their own assumption into it. The Government Digital Service’s user research blog documented this failure mode in 2016, noting that personas built on assumption rather than on activity actually observed in research tend to become a waste of everyone’s time rather than a useful reference point.

Two colleagues reviewing a clipboard of notes together at a table with laptops open

Research-built personas surface what a team did not already believe

There is a meaningful difference between a persona built from interviews, analytics, and support tickets, and one built from a room of stakeholders describing who they assume the user is. The second version tends to reflect the team’s existing mental model back at itself, which means it rarely produces a genuine surprise. Research-built personas are more likely to surface a behaviour or motivation the team had not considered, precisely because they come from outside the room.

A persona that only confirms what the team already believed was never worth building in the first place.

The Interaction Design Foundation’s overview of personas is explicit that this grounding in real data is what separates a persona from a stereotype, and that skipping the research step to save time tends to produce a document that looks credible without actually being informative. The technique itself traces back to a specific source: Alan Cooper first described personas as a method for modelling fictitious users in his 1999 book The Inmates Are Running the Asylum, and the research-grounded version of the idea has held up far better over the following decades than the assumption-built version he was arguing against.

Fewer, sharper personas beat a crowded set

It is tempting to build a persona for every segment a market research report identifies, but a set of six or seven personas rarely survives contact with a real sprint planning meeting, because nobody can hold that many distinct people in mind while making a decision. This is not just a hunch: Forrester’s 2010 research on the return on personas found that teams using a small, well-crafted set saw a measurable productivity gain over teams redesigning a product without any persona work at all. Two or three well-differentiated personas, built around distinct goals and behaviours rather than demographic slices, tend to get used far more consistently than a larger set that blurs together after the first week.

Demographic detail, an age range, a job title, a rough income bracket, is the easiest part of a persona to write and usually the least useful part in practice. Two users of very different ages can share the same goal and the same friction point, while two users of the same age and job title can want completely different things from a product. A persona anchored on behaviour and motivation travels better across a design discussion than one anchored on who the person is on paper.

A wall entirely covered in colourful handwritten sticky notes

A persona has a shelf life

Products change, and so do the people using them. A persona written for a product’s first release, built around early adopters comfortable with an unfinished experience, usually stops representing the mainstream users who arrive once the product matures. Teams that treat personas as a one-time artefact from an early workshop tend not to notice this drift, because nothing prompts them to revisit the document once it has served its initial purpose.

Usability.gov’s guidance on persona development frames this as an ongoing part of user research rather than a single deliverable, recommending personas be checked against fresh research data periodically rather than assumed to still be accurate. Nielsen Norman Group’s 2016 survey of 156 UX professionals found a clear split on this: the group that revised personas quarterly or more often rated them meaningfully more impactful than the group that left personas untouched for five years or longer. A persona review does not need to be a full research project each time; even a light check against recent support tickets or analytics can reveal whether the described goals and frustrations still match what real users are doing.

Hand-drawn wireframe sketches on paper notes surrounded by pencils and a phone

Personas sit inside a wider design practice, not apart from it

Personas work best as one part of a broader user-centred approach rather than as a standalone exercise bolted onto the front of a project. A team that builds careful personas but then skips usability testing, or ignores analytics that contradict the persona’s assumed behaviour, ends up with a document that looks rigorous while quietly drifting from reality. A clear grounding in what user-centred design explained actually involves helps a team see personas as one input among several, checked against real behaviour rather than treated as a finished answer.

Teams that keep personas connected to ongoing research, rather than filing them away after the workshop that created them, tend to be the ones still referring to them a year later.

Frequently Asked Questions

How many user personas should a product team build?

Most teams get more value from two or three well-differentiated personas than from a larger set, because a smaller number is easier for a team to hold in mind during real decisions. A crowded set of personas built around every demographic slice tends to blur together and stop getting used within weeks.

Do personas need to be based on real research?

Yes, ideally. Personas built from interviews, analytics, or support data surface behaviours a team did not already expect, while personas built purely from internal assumptions tend to reflect the team’s existing mental model rather than add anything new.

How often should personas be updated?

Personas should be checked against current user data periodically rather than treated as a one-time deliverable, since a product’s user base shifts as it matures. A lightweight review against recent support tickets or analytics is often enough to catch when a persona has drifted from reality.

What is the biggest mistake teams make with personas?

The most common mistake is treating personas as a workshop output rather than a tool used in later decisions. A persona that never gets referenced during a roadmap discussion or a scope disagreement was never actually doing its job, regardless of how well it was written.

Should personas focus on demographics or behaviour?

Behaviour and goals generally make a persona more useful than demographic detail such as age or job title, because two users with very different backgrounds can share the same underlying need. Anchoring a persona on what a user is trying to do travels better across design discussions than anchoring it on who they are on paper.