In my last blog post on the Design Studio method, I talked about the importance of collaboration between team members and building a shared understanding of the functionality they’ll be implementing.

User Story Mapping, a method devised by Jeff Patton, is a great tool to achieve this, helping teammates grasp and shape a project’s scope (among other things). UX practitioners familiar with typical user journeys might find a lot of common ground between the two techniques, although the main difference is that this method is optimized for collaboration, not for accuracy. Intrigued? Read on.

When to use it

This method is so versatile that it can be used in many phases of a project. It can be used in the initial product vision workshop, applied on a small feature to provide context, and it can even be used to restructure an endless, meaningless backlog that has lost focus after multiple iterations. In this post, I’ll focus on the first case.

How user story mapping works

Scoping a project requires a lot of work, so plan for a full day and a lot of Post-Its and walls. Oh, and use some butcher paper to stick the cards — you’ll thank me when you don’t have to document everything on the spot and can take it with you to your project room.

The implementing team (yes, developers included) and the client are the participants, and they start by listing the steps a user needs to take to achieve a goal. In this case, a goal as big as a product idea, like “I want to book my vacation tickets”.

These steps could be:

“Sign up for an account”
“Search for airplane tickets”
“Book a ticket”

Write these on cards and stick them horizontally across the wall until you reach the user’s goal. This goal might differ for different kinds of products. If it’s just an app, you might finish with “Receive boarding pass in email”. But if it’s a service that goes beyond that (and to be honest, services are what customers expect nowadays, not just apps or websites) then the journey could finish weeks later with “Write hotel review on website”.

Another tip is to start these cards with a verb, not a noun. A noun could indicate a feature (like “toolbar”, or “carousel”) and you don’t want to limit your thinking with solutions — this will come later. A verb describes an action, and implies a need.

Wait, what? No research?

This is where I can already hear a lot of you yelling “but what about research? Are you just making these steps up?!”.

Well, yes and no. If you have some initial research then that’s perfect — use it to guide your map. But often it’s a luxury not available in the initial stages of a client’s project. And that’s ok.

An experienced team coupled with a domain expert — in most cases, the client — will already have enough combined knowledge to ensure that their guesses are, well, more than just guesses. But plan some time during the project to validate or reject these assumptions and adjust the map accordingly.

When you’re finished with your map’s horizontal backbone, start breaking the steps down into smaller tasks. For example, how might one “Sign up for an account”? Answers could include “Use Facebook account”, or “Enter email & password”. List these vertically below each of the steps, and don’t be afraid to list feature ideas — these will form your backlog’s items later on.

You can also group the steps into bigger groups to indicate themes, which will help with prioritizing in the next step.

Prioritizing work

With your basic map ready, now you can start prioritizing the huge list of tasks. As in user journeys, the most important steps to tackle are the pain points — where the user faces friction, problems, or frustration. Identify these (perhaps marking them with a red dot) and plan to solve them first. And, of course, any previous user research here is valuable.

If you’re working in a volatile environment or building an innovative product, you might want to include some lean principles in this process, indicating the tasks with the highest risk (with a blue dot, for example). Issues that combine high risk and user pain points will be the first to tackle.

Planning release increments

With a very visual representation of your product’s scope and a good indication of prioritized tasks, it’s time to start planning your product increments. Remember: these are neither features nor sprints, but functionality — like this overexhausted image shows.

Draw a horizontal line below the map, leaving above it only the bare essentials needed to either:

run your first experiments to validate that the product works,
have a working prototype to assess technical feasibility,
or launch your beta version, if you’re feeling lucky (I’m guilty of doing this most of the time)

Then draw another line, and leave the tasks above it for the second increment, and so on.

Our experience with some common problems

Multiple user flows in one story map

Often a map might require multiple user personas, so how do you combine them into this one flow? It doesn’t matter. If there’s a sequential relationship, like an editor who needs to write an article so that a reader can later share it, then indicate it in the map. Have the editor’s flow first, but don’t forget to indicate the personas over each flow.

Recurring user tasks

What if there’s a recurring flow, like a freelancer logging in every day to register their hours? You don’t have to repeat it — just add it once, with all the possible task variations. In the end, it doesn’t matter if the entire backbone of your map makes sense as a continuous narrative. More important is the shared team understanding of the users’ tasks. The moments when a teammate walks to the other edge of the wall to point at something and says, “hey, but this user is doing this, remember?” are the ones that stay with you after the workshops and are of most value.

As it is, or as it will be?

This is the question I often stumble upon before starting a workshop: should I focus the map on the current or the future state of a service? If I choose the latter, then how do I indicate and separate current steps from new ideas?

So far I’ve combined both current and future states, but this has led to some waste and noise in my map. I haven’t practiced this a lot, but I’d like to see how I can combine the story map of an existing condition with user scenarios. For that, I’ll write a follow up blog post.

Documenting things

Now you have your backlog ready, it’s time to digitize it and pass it on to your favorite task management app. Unfortunately, so far I haven’t found a good alternative to just typing up what you see on the wall, but once you’re past that step you can use something like StoriesOnBoard. This service also comes with some integration plugins, so you can then import the product increments on your Jira backlog.

Keep it agile

A common mantra of agile is “you are being agile, not doing agile”. I’ve spent so much time agonizing over the aforementioned details and whether I’m “doing it right” that I’ve failed to enjoy the benefits of this method. Even in Jeff Patton’s book, where the Story Mapping method is introduced, you’ll find multiple versions of story maps and different ways of using them.

Don’t stress over the in-betweens. The end result should be a list of functionalities, product increments and, most importantly, common understanding between the team of what value each release will deliver.