Personas are one of the few UX artefacts that have managed to be wildly popular and almost universally bad at the same time. Most designers I know have a folder full of them — handed over from previous teams, agency engagements, or stakeholder workshops — and most of those folders sit untouched because the personas inside don't help with any actual design decision.
The problem isn't with personas as a concept. It's with how they get made. Here are the five recurring failure modes, why they happen, and what to do instead.
1. Demographics-as-personality
The most common failure. The persona reads:
"Sarah, 34, lives in Bristol with her partner and two kids. Drinks oat lattes. Loves the Great British Bake Off. Drives a Mini."
None of which tells you anything useful about how she'll use your product. Her age and location don't change what size your form fields should be. Her preference for the Bake Off doesn't tell you whether she'll trust an unverified review. The Mini is just there to be charming.
Why it happens: stakeholders find it easier to imagine a "real" person than to articulate observable behaviours. Demographics are concrete and easy. Behaviours are abstract and require research.
The fix: demote demographics to a single line of context. Spend the rest of the persona on what they do, what frustrates them, and what they're trying to achieve. If a piece of demographic information wouldn't change a design decision, cut it.
2. Aspirational rather than observed
The second most common failure. The persona describes the user the team wishes they had — engaged, articulate, eager to provide feedback, willing to read documentation. None of which describes the actual user, who is harassed, distracted, on a phone in transit, and deeply unwilling to read anything.
Why it happens: aspirational personas feel optimistic and generative. They sidestep the awkward conversation about whether the team's product is actually good for the people who use it. They make stakeholder presentations easier. They are also useless.
The fix: bias toward inconvenient truths. The persona should surface frustrations, hesitations and limited capacity. If reading your persona doesn't make at least one stakeholder mildly uncomfortable, it's probably aspirational. Specifically:
- Replace "values quality" with "skips reviews if there are more than three"
- Replace "tech-savvy" with "uses ten apps a day, none of them deeply"
- Replace "engaged with the brand" with "remembers your brand if reminded; otherwise doesn't"
3. One persona to rule them all
A team has built a product used by hundreds of thousands of people across half a dozen real customer segments — and they've compressed all of them into a single persona called "the user". Every design decision then gets made against this composite person, who is in fact nobody.
Why it happens: making one persona is easier than making three. Stakeholders feel that having multiple personas means having no single answer about who the product is for, which is uncomfortable. Designers, exhausted, often go along with this.
The fix: three to five personas, deliberately chosen to disagree with each other. Generate one for the segment that uses the product most. Generate another for the segment that pays the most. Generate a third for an underserved segment you'd like to serve better. The tensions between them are exactly the design tradeoffs your product is making — make them visible.
This is one reason the persona generator is designed to be cheap to re-run. Don't generate one persona; generate three and look at where they conflict.
4. Static and never updated
The persona was generated in a workshop two years ago. The product has since pivoted twice, lost half its users, and gained an entirely new segment via an unexpected use case. The persona is still on the wall.
Why it happens: persona artefacts are made of expensive workshop time. Once they exist, nobody wants to admit they need redoing. The persona becomes a sunk-cost monument.
The fix: treat personas as living documents, not artefacts. A team that's serious about user-centred design refreshes its personas at least annually, and immediately when a new segment becomes meaningful. The cost of this used to be a multi-day workshop. With a structured generator, it's an afternoon.
One concrete habit: at every quarterly planning, look at the personas. Ask: did anyone actually reference these in a design decision this quarter? If not, they're not earning their keep, and either the personas need redoing or the team needs reminding why they're there.
5. Confusing personas with archetypes (or with segmentation)
Three different things often get conflated:
- Personas describe the user and their needs in ways that drive design decisions. A persona is a research artefact.
- Archetypes describe roles (the "novice", the "expert", the "skeptic") that exist in many products. Archetypes are useful for thinking about the diversity of users, but they don't anchor a specific design decision.
- Customer segments describe groups in marketing terms — pricing tier, acquisition channel, geographic market. These are commercial categories, not design categories.
Confusing them produces personas that look like marketing decks (segments dressed as personas) or that look like Jungian character types (archetypes dressed as personas). Both fail at their actual job, which is to make design decisions less abstract.
The fix: if you're being asked to "make personas", ask what they're going to be used for. If the answer is "marketing campaigns", you're being asked for segments. If the answer is "to make brand voice decisions", you're being asked for archetypes. Both are legitimate; neither is what most designers mean when they say "persona".
For design decisions specifically, use the JTBD-anchored persona format — what is this user trying to accomplish, in what context, and what's blocking them. That's the version that earns its keep.
What good looks like
A genuinely useful persona is short, specific, and slightly inconvenient. It anchors a Job to be Done, lists three to five observable behaviours, names two or three frustrations, and includes accessibility considerations relevant to the segment. It fits on a single side of A4 with room left over.
It does not contain coffee preferences. It contains the things that, if the team forgot them, would lead to a worse product.
That's the format the persona generator produces by default, because that's the format that earns its keep. Generate three, let them disagree with each other, and revisit them quarterly. That's most of what makes the difference between personas that help and personas that gather dust.