7 Reasons to Try User Story Mapping

By: Kate Hopkins  |  November 5, 2018

At Mainsail’s product workshop this fall, portfolio company participants took over most of the available walls in our office to build 8 different user story maps. We were impressed by the number of different use cases for story mapping—here are just a few.

What is a user story map?

Popularized by Jeff Patton, User Story Mapping is a technique for understanding the journey a user takes through your product.  Typically, participants tell the story of a particular user’s experience, documenting the various steps and options with sticky notes as they go.  Story maps ensure that the focus stays on the user and what he or she is trying to accomplish, rather than on features or development requirements.  They’re an incredibly versatile tool that helps with design, prioritization, and communication.

Illustration by Jeff Patton

1) To make sure you know which user you’re designing for

By definition, a user story map needs to be from the point of view of a single user type.  This can be a helpful forcing function if you’re dealing with a B2B2C or marketplace product that has multiple distinct user groups, or if functions within your customer’s company use the product in different ways.  It’s also useful for disaggregating things that are important to internal stakeholders, and things that are truly important to your product’s user.

2)To find a starting point for a big vision

If you’re biting off a big piece of new development, it can be tricky to know where to start and how much is enough for your initial version.  Building a user story map is far, far, less expensive than building a product, so go big.  Map out the entire manual process that your product will replace, or design the full, brilliant, end-to-end solution that you’d build if resources were no object.  Then, zero in on the pieces of the journey are most revolutionary (or the most painful today), and start with those.

3)To Identify what goes into “V1” of a product

Often, it’s not necessary to productize a user’s entire journey at once, and there are often multiple ways to accomplish different steps.  Story maps bring to light which pieces are optional (save those for v2) and different ways to accomplish the same goal (when stretched thin, start with the simplest way).  For instance, if your story included a scheduling step, you might eventually want to have an integrated calendar system, but generating an email that starts a manual scheduling process might do at the start.

4)To prioritize development with a specific outcome goal in mind

Which things you prioritize and de-prioritize depends a lot upon what your user is trying to accomplish.  The best user story maps are anchored not only in who the user is, but also what matters to them.  Is it most important that the process be fast, or that it’s airtight from a compliance perspective, or that that the user is offered the broadest set of options?

5)To build shared understanding in a group

User story maps are visual, which makes them a powerful medium for building shared understanding between different stakeholders.  Verbal (or written) communication has the drawback of allowing people to think that they’re on the same page, when in reality each is imagining something different.  Putting everything up on the wall helps expose hidden misunderstandings.

6)To spot holes in your story

Building a story step-by-step helps you make sure that you’ve thought of everything.  How does a user get from one step to the next?  At what point do you ask them to pay?  How does the journey look different the first time they use the product and the 50th time?  Story maps are supremely editable, so it’s a great point in the design process to find a gap.

7)To call out and decide between alternative development options

If you bring the right people together around a user story map, plenty of technical trade-offs will emerge.  For instance, you may need to choose between a simple but inelegant approach and a much more involved one.  You might also need to determine whether to build up flows for various edge cases, or continue to force some kind of manual intervention.  Discussing these issues early can help ensure that there’s buy-in from all stakeholders on the compromises that have to be made.


More by Kate Hopkins
The statements contained herein that are not historical facts are forward-looking statements. The forward-looking statements are based on current expectations, beliefs, assumptions, estimates, and projections about the industry and markets. Forward-looking statements contained herein are not guarantees of future performance and involve certain risks, uncertainties, and or forecasted in such forward-looking statements. Mainsail Partners is under no obligation, and does not intend, to update any forward-looking statements to reflect changes in the underlying assumptions or factors, new information, future events, or other changes. While the data contained herein has been prepared from information that Mainsail Partners believes to be reliable, Mainsail Partners does not warrant the accuracy or completeness of such information.