7 Reasons To Try User Story Mapping

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.

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.

This content piece has been prepared solely for informational purposes. The content piece does not constitute an offer to sell or the solicitation of an offer to purchase any security. The information in this content piece is not presented with a view to providing investment advice with respect to any security, or making any claim as to the past, current or future performance thereof, and Mainsail Management Company, LLC (“Mainsail” or “Mainsail Partners”) expressly disclaims the use of this content piece for such purposes.

The information herein is based on the author’s opinions and views and there can be no assurance other third-party analyses would reach the same conclusions as those provided herein. The information herein is not and may not be relied on in any manner as, legal, tax, business or investment advice.

Third-party images, logos, and references included herein are provided for illustrative purposes only. Inclusion of such images, logos, and references does not imply affiliation with or endorsement for or by such firms or businesses.

Certain information contained in this content piece has been obtained from published and non‐published sources prepared by other parties, which in certain cases have not been updated through the date hereof. While such information is believed to be reliable for the purposes of this content piece, neither Mainsail nor the author assume any responsibility for the accuracy or completeness of such information and such information has not been independently verified by either of them. The content piece will not be updated or otherwise revised to reflect information that subsequently becomes available, or circumstances existing or changes occurring after the date hereof, or for any other reason.

Certain information contained herein constitutes “forward-looking statements,” which can be identified by the use of terms such as “may,” “will,” “should,” “could,” “would,” “predicts,” “potential,” “continue,” “expects,” “anticipates,” “projects,” “future,” “targets,” “intends,” “plans,” “believes,” “estimates” (or the negatives thereof) or other variations thereon or comparable terminology. Forward looking statements are subject to a number of risks and uncertainties, which are beyond the control of Mainsail. Actual results, performance, prospects or opportunities could differ materially from those expressed in or implied by the forward-looking statements. Additional risks of which Mainsail is not currently aware also could cause actual results to differ. In light of these risks, uncertainties and assumptions, you should not place undue reliance on any forward-looking statements. The forward-looking events discussed in this content piece may not occur. Mainsail undertakes no obligation to update or revise any forward-looking statements, whether as a result of new information, future events or otherwise.

No representation, warranty or undertaking, express or implied, is given as to the accuracy or completeness of the information or opinions contained in the enclosed materials by Mainsail and no liability is accepted by such persons for the accuracy or completeness of any such information or opinions. For additional important disclosures, please click here.