Story mapping is a method of visualizing user stories to create a clear, birds-eye view of the user experience from end-to-end. Think Post-It notes or pieces of paper, all lined up — chronologically — from left to right, to storyboard the steps a user must take in their overall workflow with your product.
Before we dive in, it’s worthwhile defining a user story as well.
User stories are brief, distilled descriptions of a feature or product functionality, usually written from a user’s point of view: As a [description of user], I want [functionality] so that [benefit to user].
For example, one user story for the music streaming app might be: "As a dance teacher, I want to make a playlist of high BPM music so that I can keep the energy high in my dance classes".
So where does this user story sit in the overall user journey of the music streaming app? Likely, quite early on in the process, but the user would still be required to set-up an account, add card details to subscribe, search for songs, etc. before they can create a playlist as in the user story above.
Similarly, underneath this "create a playlist of high BPM" story, you will need to list the features and functions that are required to make that action possible. For one, you need a search feature — but how will this dance teacher come across songs with high BPM?
When story mapping, you need to take a step back and put yourself in the user’s shoes. It’s not quite as simple as "search for high BPM". Sure, that’s one way to do it but that task is likely to be long and arduous and not all that great for the user experience.
So instead, you list all the possible ways that action could be made possible. One is by typing in "high BPM music" into a search field, another could be going through artists/albums the user already knows and likes, another could be by browsing already made playlists to find collections of high BPM songs, and so on.
These various features and functions can then be listed — in order of necessity — from top to bottom underneath the user story. For example, building a search feature into the app is absolutely essential for this user’s action to be performed, so it should sit at the top of the vertical axis.
By listing these different means of achieving the same end goal, a story map quickly helps you identify your minimum viable product — i.e. the top of the vertical list — and subsequent releases and feature updates.
In this way, story mapping is a very powerful tool for strategic prioritization, and the detail explored within a story map should be exported directly into a product roadmap.
In order to develop a meaningful story map, you need to really understand the experience of using your product from a user’s point of view.
Often, especially when you are very close to the product, it can be a challenge to take off your product manager or ‘developer’ hat and see through a user’s eyes.
Thing is, failing to be empathetic and understanding of the genuine user experience may result in your story mapping exercise being a waste of energy.
Inaccurate story mapping doesn’t help prioritization, and can actually lead to biases being reinforced. This could come in the shape of a non-valuable feature that the product team loves, because it’s sleek and sexy. Or a misunderstanding of how tech-literate the end-user really is — if the product team understands how to use this feature, why wouldn’t they?
That’s why it can be helpful to involve an element of user research or feedback in the story mapping process, to validate that your map mirrors the actual user experience.
At the least, try to bring someone from a different department in to sense-check your story map — are there any gaps in what you’ve laid out? Would they understand how to progress from one action to the next? Where has your product team bias slipped in slightly?
Getting user feedback on your story map is particularly important if you are mapping out an entirely new product for development.
Another key challenge in story mapping is time.
Story mapping isn’t a quick exercise. And it requires plenty of physical space, too.
You may need to work hard to convince stakeholders that this activity is worth the time and resources.
Where possible, try to create your story map in a place where it lives on display for the organization to see. This way, not only will the team be synergized and have a clear view of what they need to build for each release and why, but it’s helps encourage the understanding that a story map is a living, breathing piece of documentation.
Story maps are works in progress. They are never "done". As builds are completed, new features will get prioritized and — as always — user feedback and changes in the marketplace will glean new insight into where your map is taking you.
We can thank Jeff Patton for the concept of story mapping.
For Patton, the story mapping exercise was invaluable in ensuring a product actually meets the needs of the end-user — both by prioritizing the most important features, but also by bringing the team together in one shared vision.
Story mapping was first introduced as a concept in 2005, but wasn’t named until 2008. Since then, organizations the world over have used story mapping to deliver high quality products to market.