Experience Mapping for Agile teams
I was asked to talk at this month’s Agile on the Bench about Experience Mapping and how it can be used as a framework for teams and things beyond describing a users experience of a brand (its more usual application).
Experience Mapping is a great tool for providing us with a view of our working processes, how we work together as a team and how we deliver the things that we make. The idea being that if we can see those things objectively, then we can find ways to make them better.
To begin, let’s think about Experience Mapping as a way of describing interactions and emotions in any given scenario. It’s more than what’s happening; it’s how we’re feeling and when.
It’s important that we consider multiple touchpoints as we attempt to describe the interactions on a users journey; instead of focusing on a single device or channel, Experience Mapping should include as many touchpoints as are useful. Devices, systems, but also people, objects, places; anything that might give us insight into the overall experience we’re trying to explore.
How do we go about putting an experience map together?
As we’re describing a journey, it’s helpful to imagine the map as a timeline; it might contain some loops, but generally we’re describing a journey moving forwards in time. As we move forwards we’re likely following a “double diamond” thinking pattern through discovery, research, commitment, delivery and support, a bit like this:
You might want to try different words for your own purposes which better reflect your own journey, but these are a good place to start.
On our journey we can also think of what’s happening in terms of:
- what we’re doing — Tasks
- things we’re unsure of — Questions
- how we’re feeling — Emotions
- thing’s we’re interacting with — Touchpoints
The final layer on the map is the Ideas channel. This might also be referred to as “opportunities” or “weaknesses” but I prefer to use “ideas” as I think it’s a more constructive term.
If you’re trying this out, set yourself up with a big wall space with the timeline headings across the top and the four “happening” headings down the side. The ideas channel sits over the top of all of this in the most banging coloured post-it notes you can find. You could use a spreadsheet, but a wall is much more beneficial and fun.
Hooray! We now have a framework for thinking about our experiences.
How do we research and document our experiences?
It’s useful to start by collecting observations and stories which give a broad view of events – it might be something overheard by the water cooler, something you’ve seen happen frequently, or even something you’ve experienced first hand. Use the headings on the map to describe and record the experience. Try to include pictures if you can as your team is probably a mix of visual and verbal thinkers.
When you have some loose events, you can then interrogate them in more detail through questions, trying things out for yourself, and by talking to users who are directly involved. This will help to give us a detailed view of the experience from as many view points as is useful.
The final piece of work (and one which will be ongoing) is the ideas layer. While we’re putting our experience map together, it’s likely that ideas will have already emerged through talking about the events. I’m a big fan of a “Yes, and…” approach to help build collaborative ideas and create solutions that have shared ownership (and are more likely to succeed).
I hope this approach might help you to improve the way that your team is working. It’d be great to hear what you think, especially if you give it a go.