The design approach described in User Story Mapping adds additional dimensions to my own conception of design processes, which has been shaped primarily by design thinking and lean startup methodologies. Chapter 1 illuminates the reason Agile environments call features ”user stories” and shows how powerful stories are for capturing the big picture. The book emphasizes that rather than starting with the small tasks, it is important to have the big stories in mind and then use story mapping to “break them down as you tell them.”
Story mapping as an exercise seems like it could be valuable when performed periodically to break a big product concept down and realign goals and priorities. Considering where story mapping could fit into a larger process such as design thinking, I believe it could be beneficial both in the needfinding and ideation stages. In the needfinding stage, it is a useful exercise to help lay out a user’s beginning-to-end journey in order to find holes, and in the ideation stage, I think story mapping would be helpful in narrowing the big picture down. From a general perspective, I admire the “top-down” approach of story mapping, but I also worry that it may be difficult to break down many stories into actual features that could be developed. Additionally, although story mapping can help achieve shared understanding, the understanding that is reached might be too one-dimensional and might not be reflective of what users actually want.
I think the most useful aspect of the book’s design approach that can be applied to many different contexts is the “think-write-explain-place” habit. The book explains that one of the things that goes wrong during discussions is that ideas are said but simply vaporize. Writing down the idea after the fact helps, but one thing I learned was that writing down a few words prior to explaining it but immediately after thinking it can also make sure you don’t forget your own idea. I really like the concept of externalizing ideas so that they don’t get lost.
