How to Manage Multiple User Flows in User Story Mapping
In every meetup and webinar I’ve attended about User Story Mapping recently, the same question has popped up: How do we deal with multiple user flows in a single story map?
While it’s easy to take into account two to three different personas within a classic story map, adding multiple flows to the mix can create a complete mess and oftentimes fails to achieve the “big picture” goals you had in mind going into that process. Here’s why.
When we think about User Story Mapping, we generally associate it with a bunch of sticky-notes on a wall. After all, this is how story maps typically come to life in the physical world. However, as User Story Mapping’s author Jeff Patton defines it, this method is fundamentally about “talking about the user’s journey through your product by building a simple model that tells your user’s story as you do.” In short, telling the right story leads to building the right product.
But sticky-notes aren’t the only way to piece together your stories anymore, nor should you feel limited by their relative constraints. Fortunately, there are now better ways to adapt this model in the digital world and account for multiple flows more effectively than ever before.
We learned this first-hand when confronting this same issue head-on at Draft.io a few years back. We had one product, at least two personas, and multiple user flows to deal with.
Here are our tips and tricks for User Story Mapping with multiple user flows.
1. Build the narrative flow with high-level user stories
User Story Mapping exercises are about telling stories about the actions you want your users to take with your products.
To get started, list out what steps you anticipate them taking within a given flow in chronological order. We’ve found that writing each step as a detailed user story is the best way to stay focused on the needs and end goals of your different personas.
For the sake of this example, let’s say we’re developing a collaborative digital board (our “product”) used for facilitating face-to-face and remote brainstorming sessions.
We’ve established two different flows:
- Face-to-face collaborative brainstorming (mostly via large touchscreens, mobile phones)
- Remote collaborative brainstorming (mostly via personal computers)
As you can see in the image above, we’ve built out high-level user stories in chronological order using “chunk notes” instead of sticky-notes. It’s simply a more convenient way for writing detailed user stories.
You’ll also notice that there are two distinct personas involved in this story map: a facilitator and a participant, the traditional roles you would expect in any brainstorming activity.
It shouldn’t come as a surprise that the two flows presented here are quite similar. After all, brainstorming sessions don’t change all that much whether face-to-face or remote.
Depending on your specific use case, you could easily have three or more flows as part of your brainstorming story map. However, for the purposes of this example, two flows are more than enough to explain the logic behind this strategy.
Now that we’ve got the basics covered, let’s dive into the details.
2. Providing granularity with simplified user stories
With the “backbone” of our flows built, it’s easy to see that each high-level user story contains a lot of information. It’s now time to “double click” on the information provided in the user stories by adding shorter sub-user stories.
Let’s take a closer look at the first user story in the face-to-face collaborative brainstorming flow: “As a facilitator, I want to prepare the workshop in advance to make the workshop session more productive.”
To create these short sub-user stories, the question we need to ask at this point is: What actions does this step in the process really entail?
Here, we’ve come up with the following sub-user stories:
- Access the app from outside the workshop space
- Share the board to participants before the workshop
- Enable participants to start contributing before the workshop begins
You might be asking yourself, “Will I need to include all these user stories and sub-user stories in the first release of this product?” Maybe yes, maybe no. We can’t yet determine if this will be necessary at this point in the process. What’s most important now is visualizing the end-to-end flow of the actions that need to be taken throughout the product experience.
Although this may seem like overkill, more detail now is better. But that’s also not an excuse to go overboard. You only need enough detail to ensure the “big picture” is understood at a quick glance.
It can be very easy to get carried away at this stage. To help avoid that, avoid mentioning any user stories that you have absolutely no chance to implement over the next 18–24 months. Doing so would create cognitive overload and wouldn’t help you solve problems or make wise decisions.
That being said, if you have a cutting-edge idea that you don’t want to forget, be sure to jot it down on the side — and away from your direct visual field.
I strongly believe in the power of asynchronous collaboration. Although these first two steps can initially be done by one person, say the Product Owner or the Product Manager, once a first draft of the flows has been completed, it’s a good idea to invite other stakeholders to challenge and enrich the story map.
3. List out the product features
Behind each user story is an endless array of features. These details are important for identifying the product’s ultimate end-user value.
As with the above, avoid every temptation to go overboard with details here and stay focused on only what’s feasible in the product experience in the near- to- medium term. As de Montesquieu once said: “The perfect is the enemy of the good.” No good comes from attempting to be a perfectionist at this point.
In the face-to-face collaborative brainstorming session flow, for example, you may need to identify how users will create and edit sticky notes, as that is a defining factor of the product experience. A lot of this functionality will come down to what devices participants use to contribute to the brainstorm as well as the relative technical constraints of those devices:
- Large touchscreens
- Computers
- Tablets
- Mobile phones
You don’t need to put the features in any specific order. The goal here is simply to list out all the features that could possibly be a part of this user flow. Whatever you do — and this is the most important thing to remember at this stage — don’t forget to leave out any critical or fundamental components of the product experience here.
4. Identifying the end-to-end minimal business value in each flow
Finally, by layering on a simple set of colors to the features within these flows, we can visually identify the ultimate end-user value expected for each of our personas and define the critical path (i.e. the Minimum Viable Product).
In this example, we used shades of blue to highlight the minimum set of features required to deliver meaningful value to our identified end-users and shades of gray to highlight features that are either too complicated or too far down the roadmap to be included at this stage.
Color-coding the features is a great way to reduce cognitive overload — especially when you have a large number of features to work with — and, ultimately, create clearer and simpler flows right from the start.
This also helps us see, at a quick glance, that there’s a little more work involved in creating an optimal end-user experience for face-to-face collaborative brainstorming sessions (vs. remote collaborative brainstorming sessions) based on the devices required to power that experience. Because mobile and tablet devices will likely be used for creating and editing sticky notes in a face-to-face environment, it implies that there would possibly be the need to acquire new technologies or mobile design skills to provide the corresponding features on those specific devices.
This is the point when we have to ask ourselves a couple important questions: Is it worth the effort to develop mobile and tablet features at this stage? Without those features, will we still be able to drive our intended end-user value or will the product experience suffer?
In this case, I would say the answer is “no” to both questions. Developing mobile- and tablet-based features are too far down the roadmap to include at this time and will not detract from the product experience. Most importantly, we need to stay focused on bringing this product to life and ensure it drives end-user value immediately. For this reason, I’ve flagged both of these features in red below.
By using lists (instead of boards full of sticky-notes) and placing the two flows side-by-side, the initial problem of User Story Mapping with multiple flows has essentially worked itself out automatically. In fact, it has become a whole lot simpler, helping us to make more informed and realistic decisions about how to approach the product roadmap in the near-term.
“Solving a problem simply means representing it so as to make the solution transparent.” Herbert A. Simon
As Herbert A. Simon, a Nobel Prize winner in Economics wrote some years ago, “Solving a problem simply means representing it so as to make the solution transparent.” That’s precisely what we did in adapting the original User Story Mapping model to fit our specific (and more complicated) multi-flow situation better.
Offering you a flexible digital environment for doing this kind of comparative story mapping work is what makes Draft.io such a powerful tool for both problem-solving visually and making better decisions.
Want to learn more?
If you’d like to become an expert in UX Design, Design Thinking, UI Design, or another related design topic, then consider to take an online UX course from the Interaction Design Foundation. For example, Design Thinking, Become a UX Designer from Scratch, Conducting Usability Testing or User Research — Methods and Best Practices. Good luck on your learning journey!
Now, it’s your turn to share. Do not hesitate to leave a comment explaining how you’ve dealt with multiple user flows in User Story Mapping in the past or how we could help you tackle this challenge more efficiently with Draft.io.
I would like to thank Fatima-Zahra HAMIL and Alexandre Brebant, Product/Agile Coaches at Publicis Sapient, for their kind and valuable contribution to this article.
