Note: The screen recording for this session failed (womp womp), so it has been recreated for illustrative purposes only. I will do another session in future doing the exercise itself.

ℹ️ Skip to key parts of the session by clicking on the chapter dots along the timeline.

In this Live Session, we do a run through of a Journey Map from Workshop Tactics.

👉 View the Miro board for this session

Session highlights

Like a Chicken Tikka Masala, there are different kinds of Journey Maps, with varying detail, scope, and weight of evidence.
A Journey Map's X-axis are the steps in a product or service.
A Journey Maps Y-axis is level expectation.
- Exceeding expectations = delight
- Meeting expectations = indifference
- Not meeting expectations = frustration
Over time, unexpected things become expected.
The gap between 'expectations met' and 'expectations exceeded' is what we call 'innovation'.
A Journey Map is a prioritisation tool. It helps your team see the frustration parts of the journey that you should prioritise to move to be “indifferent” at least. “Remove the creases from the journey.”
When everything feels important - use “Very important > important” to prioritise what to work on first.
Journey Maps can be as simple or detailed as you need. The simpler they are, the easier to share with others. Big detailed maps are useful for creating a shared understanding of complex services. But as they become more complex, they become less effective at communicating clearly to the outside of your team.
Focus on frustrating steps first. You must eliminate all frustration from a journey as a bare minimum. Even an “MVP” should not cause frustration.
A Journey Map is a model, not reality. There’s a trade-off between modelling reality, and making it clear to others.

How and when to use a Journey Map

By yourself for your own understanding - like being a “mystery shopper” from your own perspective. Use yourself to play the user’s role (but understand that you may have different expectations to your users). If it caused you frustration, it would quite likely cause it for someone else.
Speculate on what the steps are to get your assumptions down. It’s better to start with something, as it gives you an anchor to test against. “Is it really this way? Let’s go and find out!”
Using insight, customer interviews and research to feed into a living map that reflects the current experience.
Simon suggests you should use all these ways of mapping. Doing it by yourself helps you understand it and creates questions you might want to ask. It can help you challenge the status quo - or what frustrating elements we’ve gotten used to

Tips on research

When you observe someone, record them narrating their actions. It’s an excellent way to get people to express what they’re doing. You can learn the language they use, which helps you develop the content design.
Observational data is the most useful. Seeing someone being frustrated is vital, as they might always report to you that they felt that way.
Alternatively, you can use surveys to get a sense of it.

Journey Map steps

1. Start with two points, slightly in from the start and the end.

a) The moment your users interact with your product
b) the moment they achieve what they set out to do.

2. Get everyone to write down all the steps that happen before, during and after these two points.

3. Move the sticky notes and alter their colour to reflect if that step is frustrating or delightful. Either based on speculation or research.

4. You should now have a clear picture of where your potential areas of improvement are to remove frustration.

Questions from the session

Q: What's the next step? Test with audience/customers if these 'pain points' are accurate?

A: Yep! If you've done this on your own or with your team based on assumptions, it's now a useful artefact to evolve and update as you learn.

-

Q: What if there is a lack of agreement on the map, or what falls "in scope" for the team?

A: Disagreement is good, as it creates a catalyst to validate/invalidate your assumptions. No one can argue against research. In regards to scope, it's always good to see the whole picture, and be mindful of what is within your control to change.

-

Q: How do we consider things outside the core journey that are also dependencies?

A: This probably starts to demand a map with more depth, such as a Service Map. Being aware and paying attention to these external dependencies is sometimes enough. To not be aware of them at all can be disastrous. When you see opportunities to improve things outside the core journey, that's where these maps become valuable communication tools. They can be shared with other teams and disciplines, to reveal how they can contribute to creating a great user experience.

Have you got a question, or an additional answer? Comment below 👇