How (Not) to Work With Personas in Journey Management

Personas occupy an interesting position in service design: almost universally used, frequently criticized, and rarely applied in the way their proponents intended. In journey management specifically, they create more problems than they solve — unless they are used in a single, well-defined moment with a clear expiration date.

Why Personas Become Problems Over Time

The original purpose of a persona is to give teams an empathetic anchor — a human face to design for. In the right context and moment, this is genuinely useful. The problem is not the persona itself. It is what happens to it after the workshop.

Personas stay. They get printed, framed, posted on walls, referenced in presentations, and gradually invested with meaning that the original research never supported. The "beginner user" becomes "the one who needs everything explained twice." The "busy professional" becomes an excuse to deprioritize accessibility. The "power user" becomes the de facto primary audience, regardless of what the business actually needs to serve.

Personas are narratives, and narratives take on lives of their own. Once a character exists with a name, a photo, a set of personality traits, and a backstory, teams start relating to that character as if it were a real person whose preferences and behaviors are known. This is the goal — but it can lead to designing for the persona rather than for the actual diverse range of people the persona was meant to approximate.

The specific risk is stereotyping: when a persona representing a particular demographic characteristic becomes associated with a particular capability limitation, the design implications can actively harm users who share the demographic but not the limitation.

"I once worked on a project where a persona representing lower digital proficiency was a middle-aged woman. She was meant as an archetype, but she gradually became 'the one who doesn't get it.' The stereotype stuck."

The One Context Where Personas Work

There is exactly one moment where personas are appropriate in journey management: immediately before a workshop where participants need an empathetic anchor for ideation.

In this context, a persona functions as a storytelling device — a quick, narrative shortcut that helps participants inhabit a user's perspective for the duration of a creative session. It is introduced at the start of the workshop. It is set aside at the end. It is not a deliverable, not a persistent artifact, and not a reference tool for future decisions.

Used this way, a persona does what it is supposed to do — create momentary empathy — without accumulating the distortions that persistent personas develop. The team spends an hour designing as if they understood a specific human experience. Then they return to the evidence.

What to Do Instead

The durable alternative to personas is a combination of Jobs-to-Be-Done and hashtag tagging, as described elsewhere. Each insight is tagged with the job or role it relates to, and teams can filter by tag to focus on specific user populations when designing specific interactions.

This approach is more durable because jobs change more slowly than demographic profiles. More inclusive because it does not assume that a job is performed by a particular type of person. And more operationally useful because a job tag is directly actionable (a team designing for #first-time-buyer knows what problem they are solving) while a persona description requires interpretation before it becomes actionable.

The test is simple: if removing the persona from the journey map changes how the map is structured, used, or interpreted, the persona is doing important work. If it is primarily decorative — adding personality to a map that functions the same way without it — the maintenance burden is not justified.