User Journeys (the real hero's journey)
How to extend and understand the context of your user throughout your business.
A while ago I wrote (you could say ranted) about the Hero’s Journey, and why it’s a horrible framework for storytelling in a business context. There’s one case where it does kinda fit — but not in the way you think.
If you’ve been in product management more than a second, you’ve probably heard most of the following:
The advertising adage that it takes several exposures till someone engages
The marketing funnel where prospects are first made aware, and then move through stages till the buy
Onboarding! Onboarding! Onboarding!
(In Enterprise software) The buyer isn’t the end-user
Your product sucks because of several clicks and seconds too many to get stuff done
As a believer in visualisations and storytelling, I thought we’d cover another technique that’s applicable to all of the above: user journeys.

What are user journeys?
User journeys map the touch-points and interactions you may have with a prospect or a customer over time. The idea is to list out and then map all those interactions, so you can evaluate the process, what the user feels, and how complex it is for them to achieve their goal.
They are traditionally presented as a table, with the user progressing from one column to the next and the rows representing their state (goals, actions, feelings) as rows. You can get fancier, but that’s the essence: what makes them progress from one state and interaction to the next. Adding some stock emojis for user’s mood and stock clip-art for the activity goes a long way into making them visually interesting and memorable.
When you have the whole journey mapped, you can examine the overall picture for insights into the user’s overarching goals, as well as on how does each step flow: what are the prompts to do a specific action? How well does the output lead the user to the next interaction? What is the friction? It becomes easier to identify bottlenecks and other issues where you can improve the flow to get the user to their goal (thus providing value, for which you expect to get paid).
The idea is to look about the experience of the user over time as they strive towards a goal, but focusing on the points where you interact with them and have a chance at affecting behaviour. How many steps do they need? What interactions might not be clear, or disappointing? It’s a tool to gather and communicate insights, to help you understand where there is friction that could/should be addressed.
A similar type of mapping is for user flow. That usually refers to the interactions the user has with the system. It is usually more detailed about the specific steps, and may include notes on what the system (product) does in the response. They are often represented as a flow-chart of some kind, and useful for designing the specifics of each interaction.
How is it related to the Hero’s Journey?
The only relation to the Hero’s Journey is not about that storytelling framework’s (highly dubious) stages. Rather, it’s the philosophical observation that everyone is the hero of their own story. This is useful in writing fiction when designing complex characters and interactions, and it’s useful here to get us out of the technical world and into the user’s mind.
Laying out all the touch-points a prospect customer has with you as they move through your acquisition funnel, or mapping all the tasks a user needs to do to achieve their goal, helps you keep their desired outcomes and frame of mind in focus.
You start with what outcome the user desires. You show each point of interaction and what moves it to the next one in achieving their goal. And at the end, you can put yourself in the user’s place and ask whether that makes you feel like a hero — or just exhausted?
We often focus on the user flow, on what the system does is response to an input (user clicks “submit” which then causes a flurry of activity like so…) This is useful for developers, but consider inverting the viewpoint: everything the system does is black box; what are the users emotions and goals going in and coming out of the interaction?
This is very common in marketing, where the journey maps represents the customer as they move from having a problem, through becoming aware of your solution, to the final decision (and process of) buying your product and services. Customer maps include feelings/emotions as well as actions and goals.
You will need to strike the balance in specificity with your audience and needs, whether you are talking about customer acquisition, onboarding interactions, or just a flow to a specific outcome. Just remember that it’s the user’s journey, and they are the hero of their own story. The interactions with your product should help them on their quest.
How to visualise?
In any way that makes sense 😁
OK, that’s probably not very helpful. There are an approximate gazillion examples when you run an image search for user journeys, and formal notations like BPMN or UML for user flows that you could use. In reality, unless you’re a BA with highly specialised knowledge and needs and talking to other BAs with the same knowledge, you don’t need all the complexity these often bring.
Anything from a simple table with nice graphics & emoji for journeys, or really simple flow chart (stick figures, boxes, diamonds for decisions, and a few annotated arrows) is usually enough to start with.
At one workplace, we simply evolved our own visual language. We started with the basics, added shapes when we needed them, added a few colours when we started to break things down (now/later, or functional areas). The point was it was quick to get started, it showed the flow, and all of us together built something that all of us together understood and could use.
You can also use any collaborative tools for that. Miro / Mural are good and come with templates you can grab. Draw.io or a similar diagramming tool would work as well. Pick whatever is easiest for you and your team. My advice would be to pick something and start quickly with the basics, and refine later: don’t try to specify everything up front (all the columns & rows, all the shapes), just add them as the need arises. When diagrams get complex, break them down to linked documents to help you keep each one focused on what you are trying to convey.
In user flows, it is sometimes helpful to put swim-lanes or columns for different actors. This may be useful when you have very complex interactions with a group of people (eg the user needs actions from the admin, the system, and responds asynchronously to the consumer), but it gets messy very quickly. Often, it’s worth simplifying and isolating sub-journeys as much as possible, so you don’t get bogged with what looks like spaghetti splatter.
You’ll also find that different journeys have different characteristics. You are always looking to gain or share insights, but the best way to represent these will warrant varying the visualisation and presentation.
For example, a customer’s journey through a funnel is often asynchronous and non-linear. You may imagine a ‘golden path’ along the sequential columns, but practical experience would be different between users. A loose diagram of stickies with circles around topics and some loose arrows (eg the webinar vs email campaign as one group, leading to the trial, signup and on-boarding as a second group) might be better than a flow chart. Conversely, when talking to engineers you may need to be more precise about inputs and outputs and where the decision points are.
Remember!
This is a communication tool. It should aid the exchange of ideas by clarifying and presenting the essential view, not a way to capture every single detail and sub-routine. You can tell a story about your user’s journey with a page of text (and you probably should!) and then match it with a more formal journey diagram to delve deeper into details and background info.
Don’t over-analyse or over-prescribe it. Just use it with the audience to enable better ideas exchange. Start simple, and evolve as needed. (If you look up samples by running an image search for “user journeys,” just remember that there are no silver bullets and all frameworks are evil — you’d get much more mileage by picking something and running it with it, than agonising over the “right” way to do it).
Was that useful?
I purposefully didn’t include visual samples, because I wanted to focus on the “just do it” aspect, on the minimalist aspect of throwing something on a canvas and having a shared discussion (even if with yourself) about what you can learn when you’re in the user’s shoes. Think of what they are trying to achieve (the outcome), what they have to know and do to get there (the journey), and where there is friction you can improve on.
If you do want some samples, this is a nice and simple article on the concepts, this and this are deeper dives, and this has an awesome collection of templates. Just don’t get analysis paralysis: a quick skim and learning by doing and collaborating will get you further, quicker.
Let me know what you think in the comments!
!
Interesting article! Mind you, I'm just an end user of such processes. And I had to google 'product manager'. Atlassian gave me the following definition. "A product manager is the person who identifies the customer need and the larger business objectives that a product or feature will fulfill, articulates what success looks like for a product, and rallies a team to turn that vision into a reality."
I just bought a unit in a retirement village and can on hindsight recognise the process used to get me to the table.