“Shared documents aren’t shared understanding.” This statement, from the section “Read This First” in User Story Mapping, underpins the idea that different people have different ways of thinking, and written words might not do justice to each individual’s interpretation. Author Jeff Patton emphasizes that externalizing ideas–with speech and visual-based stories, with energy and interactiveness, and with other people–goes a long way in promoting true shared understanding and stakeholder alignment.
Patton’s approach complements design processes I have used before. I appreciated his emphasis on outcome and impact, rather than output, as the ultimate goals for building a product or feature. In other words, what fundamentally matters is the effects that a released product has, rather than the product itself. Have people changed some aspects of their lives? Have we made their lives better? By centering the process on who users/customers are, and why they want something or feel a certain way, rather than jumping right into what a possible solution might be, the company that is building a product or feature can make its users/customers happy, which is likely to have a positive impact for the company in long-term.
I also enjoyed Patton’s explanation (in Chapter 1: “The Big Picture”) of story maps as a way to better understand an entire product or feature. He first illuminated the point that the reason stories are termed as such is because of “how they should be used, not what should be written.” Yet while stories help move towards shared understanding (rather than the unreliable communication from merely using shared documents), stories by themselves may make it difficult to see the big picture. Story mapping helps to bring back big-picture insights to Agile processes. To do so, Patton explains that the idea is to have a conversation, and then organize key points like a map. During story-telling, key points should be externalized by writing them down on cards or sticky notes, which should then be put into a shared space so everyone can see, add to, and move them. Patton has a concise characterization for this process: “talk and doc.”
I found his outline of what to consider when story mapping especially helpful, and thus have included a summary below:
- Frame your idea. Why are we building this product idea? What problems does this solve for people? What are the benefits for us?
- Describe your customers and users. Who are the customers who’ll buy this product? Who are the users who’ll use this product? How would different types of people use the product, and what benefits would they get? If we were to focus on just one type of potential users, who, and why?
- Tell your users’ stories (starting with breadth before depth). What is the user flow–what are the steps that a user would take when using the product?
- Explore details and options. At a given step in the user’s story, what are the specific things they’d do? What are alternative things they could do? What happens when things go wrong?
