How does [user story mapping] differ or complement design processes you’ve used before?
Compared to the design-thinking I used in 147/247 and the PM skills I learned in my internship, Patton’s process of story mapping spends more time getting the big picture, before diving into and mapping the specifics. User story mapping is also a great complement because it works as a pattern rather than a rigid process, which allows you to apply these patterns to get stuff done — even if you’re using a process like design thinking along the way.
[The Design Thinking Process: Empathize –> Define –> Ideate –> Prototype –> Test]
I was surprised to read about the approach of writing stories that Patton introduced in chapter 1, specifically ones that “focused on the big picture.” When thinking about what kind of product to make, Patton’s team started with the big picture, to really understand the background. On the other hand, the first step of the design thinking process is to empathize, which — at least in 147/247 — often involves lots of 1-1 interviews and asking for specific instances within your domain of interest. From these specific user experiences that you gather, you then try to make more holistic conclusions about your problem space to define your project. Patton’s process also lasers in on what to prioritize and gets to the specifics before building, but it takes the extra step and dedication to big picture, too.
Compared to the PM tasks I had this summer (namely defining product vision and then delivering), it seems like user story mapping is a lot more team-oriented. In Patton’s book, he describes how Gary was excited to tell certain parts of his user’s story, and this excitement might not have arisen if Gary was sitting alone with his thoughts. The process of story sharing, rearranging, having someone else to ask questions, seems very encouraging of getting the whole picture; someone else can discover the holes, bring out the highlights, and so on. Since I was the only PM working on my specific project and I didn’t want to ask for a heaping amount of my manager’s time, I wasn’t able to go through this kind of collaborative product process with other PMs. I certainly got a lot of input from higher-ups and other roles throughout, but this isn’t the same as this kind of Talk-and-Doc process that allows you to map from the ground up, together.
The Talk-and-Doc component seems like a fantastic complement to most steps of the design thinking process. In empathizing, defining, ideating, and prototyping, it makes sense to go through the flow of [Think –> Write –> Explain –> Place], allowing you and your team to better share and remember ideas. Since you can rearrange and build around sticky notes in all directions, story mapping doesn’t neglect the context nor the details. It feels like a screen view that you can choose to zoom in or out on, both perspectives contributing to the final result.
