Two Tools That Are Often Misused
Personas and customer journey maps are two of the most popular tools in product and design. Most teams have them. Most teams rarely look at them. Most teams cannot tell you whether they have changed any decision in the last year. The tools have a good reputation but a poor track record in actual use.
We are not against either tool. Both can be useful. But the way they are usually built and used produces fancy artifacts that decorate walls and Slack channels without affecting the actual work. This article is about what these tools are good for, the common ways they fail, and how to use them so they actually shape decisions.
What a Persona Is Supposed to Do
A persona is a description of a fictional person who represents a real user type. The idea is that giving the team a specific person to design for, instead of an abstract "user," produces better decisions. When debating a feature, the team can ask would Sarah care about this? instead of would users care? The first question is easier to answer.
In theory, this works. In practice, most personas fail to do their job. They sit in a Confluence page that nobody opens. They include attributes (age, hobbies, favourite TV show) that have nothing to do with how the user uses the product. They get treated as decoration, not as decision tools.
Why Most Personas Fail
They Capture the Wrong Things
A typical persona document has a name, a photo, an age, a job title, a list of hobbies, a quote, and a paragraph about their lifestyle. Of these, only the job title is usually relevant to the product. The rest is filler. The team gets used to ignoring the filler, then ignores the whole document.
What actually matters is what the user is trying to do, what context shapes their behaviour, what frustrations they have, and what success looks like for them. Most personas omit these in favour of demographic decoration.
They Are Built From Imagination
Many personas are created in a workshop, with team members guessing at what users are like. The result reflects the team's assumptions, not real users. The persona looks substantive but is fiction. It then influences decisions in subtle ways, spreading the original assumptions through the product.
They Don't Get Updated
Personas built three years ago describe users from three years ago. The product has evolved, the market has shifted, the user base has changed, but the personas have not. Stale personas are worse than no personas because they create false confidence that the team "knows the user."
They Encourage Stereotyping
Sarah, 35, marketing manager at a tech company, drinks oat milk lattes. The persona produces a stereotype rather than a real user. The team designs for the stereotype. Real users, who are messier and more varied than the stereotype, are less well served.
They Replace Ongoing Research
Once the team has personas, they often stop doing user research. We don't need to talk to users this quarter; we have the personas. The persona becomes the user in the team's imagination, and the real user gets less and less attention. This is the worst failure mode, because it is invisible.
What a Useful Persona Looks Like
If you are going to use personas, build them in a way that avoids these failure modes. The features that distinguish useful personas from decorative ones:
Built From Real Research
Each persona should be grounded in actual interviews, support tickets, and behavioural data, not in workshop guesses. The process of building the persona should involve looking at real users and finding the patterns. The output is a synthesis of what you actually heard, not what you imagine.
Behaviour-Based, Not Demographic
Useful personas are organised around what users do, not who they are. The User Who Researches Carefully Before Buying is more useful than Sarah, 35, marketing manager. The behaviour is what affects the product; the demographic might or might not.
Specific About Goals and Frustrations
The most actionable parts of a persona are: what is this user trying to accomplish, what gets in their way, and what does success look like for them? These three pieces of information, captured concretely, drive most product decisions.
Updated at Least Annually
Re-validate the personas with fresh research at least once a year. Are the patterns still real? Have new patterns emerged? Are some old personas obsolete? Personas that don't evolve with the product become museum pieces.
Limited in Number
Three to five personas is plenty. Some teams produce ten or fifteen, which dilutes attention and means none of them get used. The discipline is to capture the most important patterns, not every possible variation.
A Better Alternative: Specific Recent Examples
We mentioned this in an earlier article and it bears expanding. Personas are summaries; summaries lose detail. A more useful tool, in many situations, is a list of specific recent users.
Maintain a document with five to ten real users from the last few months. Each gets a short profile: their context, what they were trying to do, what worked, what didn't, what they said. Names can be pseudonyms; the rest should be specific. Update this list every quarter.
When making decisions, reference these specific users. This feature would help Mariko, who couldn't figure out how to share with her external team. The specificity makes the decision concrete in a way that personas don't. The team ends up arguing about real users with real situations, which produces better decisions than arguing about a fictional Sarah.
This approach has several advantages. The users are real, so the patterns are grounded. The list refreshes naturally as new users are added. The team stays connected to actual user voices rather than to a year-old persona document. And the list is shorter and easier to keep in mind than most persona libraries.
What a Customer Journey Map Is
A journey map is a visual representation of the steps a user takes to accomplish a goal, often spanning multiple touchpoints and including the user's thoughts and feelings at each step. Done well, it surfaces friction points, emotional valleys, and moments where the experience can be improved. Done badly, it is a complicated diagram that nobody updates.
A journey map for a SaaS product might trace a user from discovering the product, through trying it, through purchasing, through onboarding, through first use, through deeper adoption, to expansion or churn. At each stage, the map captures what the user is doing, what they are thinking, what they are feeling, and where the experience is good or bad.
When Journey Maps Help
Journey maps are most useful when the team has lost the user's perspective and needs to recover it. They force everyone to look at the experience as a whole, not as a collection of features. They surface gaps that no individual team is watching, because the gaps live between teams.
They Are Useful For:
- Cross-team coordination. When the user's journey crosses several teams (marketing, sales, onboarding, product, support), a journey map gives everyone a shared view of what the user is going through.
- Finding gaps in the experience. Steps that no team owns or where the experience drops off because of organisational seams.
- Diagnosing churn or drop-off. A journey map of new users often reveals where they get stuck or lose interest, pinpointing where to invest.
- Onboarding new team members. A journey map gives a newcomer a fast overview of the customer experience that would take weeks to absorb otherwise.
- Aligning on what to fix. When the team has too many issues to address, a journey map helps prioritise by showing where the experience is worst.
When Journey Maps Mislead
Journey maps can also mislead. The most common failures:
Built From Imagination
Like personas, journey maps are often created in a workshop, with team members guessing at what users do. The map looks credible but reflects internal assumptions. Real journeys are messier, more varied, and less linear than the maps suggest. If you haven't talked to users while building the map, you are mapping fiction.
Treated as Comprehensive
A journey map shows one path through the experience. Real users take many paths. The team starts treating the map as the user journey and overlooks variations. Important segments get missed because they don't fit the map.
Built Once and Frozen
The product changes. New features ship. The user journey evolves. The map does not. Within a year, the map describes an experience that no longer exists. Like personas, journey maps need periodic refresh.
Used as Reports, Not Tools
Some teams produce beautifully designed journey maps as deliverables, present them once, and then file them. The map exists; nobody uses it. The form was the goal, not the use. A rough hand-drawn journey map that the team references weekly is more valuable than a polished one that gets filed and forgotten.
How to Build a Useful Journey Map
If you decide to build a journey map, the process matters more than the artifact. The discussion the team has during the mapping is often more valuable than the final document.
Step One: Pick One Specific Journey
Don't try to map every possible user. Pick one specific journey: a particular user type accomplishing a particular goal. A new free-tier user signing up and reaching their first moment of value. Specific scope produces useful maps; broad scope produces noise.
Step Two: Ground It in Real Data
Before mapping, gather what you know: interviews with users who have taken this journey, behavioural data showing where they actually clicked, support tickets from users who got stuck. The map should reflect this data, not pure imagination.
Step Three: Map the Stages and What Happens at Each
Write the stages of the journey across the top: Discover, Sign Up, Set Up, First Use, Routine Use. For each stage, fill in: what the user does, what they think, what they feel, what touchpoints they encounter, and where the experience is good or bad.
Step Four: Mark the Pain Points
Use the map to find where the experience drops. These pain points are the items the team should consider fixing. The value of the map is in surfacing pain points that the team wasn't systematically tracking.
Step Five: Use It to Drive Decisions
Reference the map in roadmap discussions. Tie features to specific pain points on the map. After fixing, update the map to reflect the new state. Without this active use, the map becomes decoration.
Common Mistakes With Both Tools
Mistake One: Treating Them as One-Time Deliverables
Personas and journey maps are most valuable when treated as living documents, not as one-time outputs. The team that builds them, presents them, and never updates them is wasting the investment.
Mistake Two: Letting Them Replace User Contact
Once teams have these documents, the temptation is to stop talking to users. We have the personas; we know the user. Wrong. The documents summarise; they don't replace. Continue the user research practice in parallel.
Mistake Three: Designing Them for the Wall, Not the Work
Beautiful posters of personas, framed and hung in the office. Elaborate journey maps in custom-designed templates. The visual form is irrelevant if the content is not actively used. The energy spent making them look good is energy not spent making them useful.
Mistake Four: Confusing Them With Strategy
Personas tell you who. Journey maps tell you what they experience. Neither tells you what to build, why, or in what order. They feed strategy; they are not strategy. Some teams treat them as if they were the answer rather than as inputs to the answer.
Mistake Five: Skipping the Update Cycle
Set a recurring calendar event. At least once a year, review and refresh both personas and journey maps with new research. Without the cycle, they slowly drift into irrelevance.
A Final Word
Personas and journey maps are tools, not deliverables. Their value lies in changing how the team thinks and decides. If they are doing that, keep them and update them. If they are not, replace them with something that does, even something rougher and less polished.
The most useful tools are usually the ones that get used. A rough document that the team references in every roadmap review is doing more work than a beautiful one that nobody opens. Optimise for the conversation it enables, not the presentation it produces.
Key Takeaways
- Most personas fail because they capture demographic decoration instead of behaviour, are built from imagination, don't get updated, and replace ongoing user research.
- Useful personas are behaviour-based, grounded in real research, focused on goals and frustrations, limited in number, and refreshed at least annually.
- Specific recent users (a list of five to ten real customers with real situations) are often a better tool than personas. The specificity drives better decisions.
- Journey maps are most useful for cross-team coordination, finding gaps in the experience, and diagnosing drop-off. They mislead when imagined rather than researched.
- Both tools should be built for use, not for presentation. A rough sketch that gets referenced weekly beats a beautiful artifact that gets filed.