User Story Mapping

Communication is difficult! And having to agree on something committal adds another complication. While I personally don’t think that I’ve had any project miscommunications as egregious as writing “Nuts Allergy” on a cake, I resonate with the struggle of everyone agreeing on their version of an idea without realizing the dramatic difference in everyone else’s idea. In CS 147, my team wanted to create an app that matched volunteers together based on their service interests, followed by a paired reflection activity to help people integrate their service goals with their life goals. It wasn’t until weeks into deciding on an idea that we realized that 1.) none of us had any idea of what paired reflection looked like or meant, 2.) when we finally took the time to brainstorm and discuss, even our “agreements” diverged into far different ideas.

I think that in a lot of ways, this article embodies the essence of design process in that its values are aligned with rapid prototyping. Not trying to “perfect a document” and instead taking an abundance of vacation photos is similar to trying to pump out original ideas as fast as possible under self-imposed constraints. I think what differs is that this approach is a bit less user-centric, despite having the same goal in trying to maximize the satisfaction of users. I think that this approach is partial to the idea that giving a genuine effort to listen to users is more than sufficient to satisfy most users. A genuine effort is a bit more nuanced in that it still involves understanding the who and why of the product, but being able to effective take user feedback and incorporate it into designs (even if it doesn’t accommodate for everyone’s needs) will still go a long way for user satisfaction. In the Stanford design process, I don’t think I’ve encountered a rule like this, even implicitly.

Avatar

About the author