The Persona Trap: Why Most User Personas Go Unused

A user persona is usually born in a kickoff workshop, pinned to a conference room wall, and taken down again the day the project ships. “Min-jun Kim, 32, drinks iced Americanos, scrolls Instagram on the subway” sounds vivid and specific, but when a real decision is on the table, almost nobody goes back to reread it. Personas exist so a whole team can hold the same mental image of the people they’re building for — yet somewhere along the way, making the document became the goal instead of using it.

1. Why personas end up gathering dust

The most common cause is that the persona lives completely outside the actual decision-making process. It gets built in a single day during the kickoff workshop, and after that there’s no built-in moment to open the file again — not when prioritizing features, not when sketching a new screen. When someone asks “do we really need this?” in a meeting, the room answers from gut instinct instead of pulling up the persona. The bigger the gap between the effort spent creating it and how often it actually gets referenced, the faster a persona turns into decoration.

2. The risk of a persona built on guesswork

A deeper problem shows up when a persona is filled in with the team’s imagination instead of real user data. Specific details — age, job, hobbies — make a persona feel alive, but details with no evidence behind them can quietly steer the team in the wrong direction. Once “someone like this would probably want this feature” starts getting treated as research, the persona stops being a tool for insight and becomes a tool for rationalizing whatever the team already believed. This is exactly why real quotes and behavior patterns gathered through user interviews need to come before the persona is drafted, not after.

3. What goes wrong with more than one persona

As a product grows, its user base diversifies, and teams respond by sketching out three or four personas to capture that range. The trouble starts when those personas sit side by side with no ranking between them — the moment a feature debate breaks out, everyone reaches for whichever persona happens to support their own position. “Persona A needs this feature” and “Persona B finds it actively annoying” can both get argued in the same meeting, and at that point the persona has stopped being a tool for alignment and become a tool for justifying whatever conclusion each person already wanted.

The fix is agreeing on a clear priority or weighting among personas ahead of time. Naming one primary persona that represents your core user base, and marking the rest as reference material, gives an argument somewhere to return to when it stalls.

That priority should also rest on something concrete — share of revenue, frequency of use — rather than a gut feeling that “this user just seems more important.” Ranking personas by intuition is just another unfounded guess, which puts you right back at the original problem.

4. Building a persona that stays alive

Keeping a persona in active use takes three habits. The Interaction Design Foundation’s overview of personas also points to goal-driven narratives as the core principle.

Write around goals and friction points rather than demographic trivia — “what are they trying to do, and where do they get stuck” connects far more directly to real decisions

Add a standing question to every feature discussion: “which persona’s goal does this decision actually serve?”

Keep the interview notes or data behind each persona attached to it, so anyone can go back and check the evidence later

Three habits that keep a persona in active use

💡 Pro tip — Just adding one standing question to every feature meeting — “which persona’s goal does this decision serve?” — is often enough to pull the persona off the wall and back onto the table.

Closing thoughts

A persona isn’t a permanent asset. When your user base shifts, or the market has moved since the original research, it’s worth rebuilding without hesitation. Reciting an outdated persona out of habit is no better than working from unfounded imagination in the first place. Logging when and why a persona was revised — alongside a decision log that records the reasoning behind changes — makes that judgment easy to trace later. On consulting projects, it’s generally safer to run a quick check at every major milestone: is this persona still holding up?

A living persona

Its evidence sources are documented, and there’s a visible trail of it being referenced in recent feature decisions.

A sleeping persona

Built once at kickoff, now surviving only as a poster on the wall that nobody opens again.

Which one does your team’s persona look like right now?

Does the persona list the interviews or data behind it?

Do goals and friction points come before demographic details?

Was the persona actually referenced in a recent feature decision?

How long has it been since the persona was built, and has anyone checked whether it still holds?

If there’s more than one persona, is the priority between them clear?

A quick persona health check

A persona should be a tool you actually open during a meeting, not a poster made for the wall. Start with something small: pull up the persona document at your next feature discussion, and see whether it still feels alive.

Design Daily Life · Notes on design, daily

한국에 온 외국인 친구가 있나요? 메뉴 번역·택시 요금·약국 카드가 한 앱에 있는 K-OREA를 알려 주세요.

Visiting Korea? K-OREA puts menu scanning, taxi fare guidance and a pharmacy card in one app. Get it on the App Store.

댓글 남기기