User Story Mapping

This article points out some great points for me to be careful when designing things. First, the author talked about communication. A lot of times we have discussed and nodded our heads while others are saying, but it turns out in the end we have some underlying hypotheses that weren’t shared with each other. The author suggests talking, sketching, writing, using sticky notes and cards to communicate, and then photographing and shooting videos to document and align our thoughts. I can imagine that this would be clean and clear for communication. Take an example of mechanical design, when you have a mechanism in mind, most of the time it is difficult for people to fully understand without sketching it out. 

The author brings up a point that “Stop trying to write perfect documents”, this differs from what I have done. I prefer writing down all the things that we need to know (in a structured way) in the documents. Anyone who comes and reads the documents can fully understand what we were discussing. The author says that our shared understanding is filling in details that aren’t in the document. However, I think humans’ memory is limited, and it is hard for everyone to always remember the shared understanding without it being documented. Here is where I think people will start to diverge and have different understandings. If not written, after time pass by, people will try to interpret the idea in their own understanding.

I resonate that “requirements actually mean shut up“. When it is said to be a requirement, people will start to assume the requirement is validated by a lot of people or agreed upon by a higher management level, but not think about “why is this a requirement?” Though the author chooses to say it less, it would be a better if the listener try to understand the rationale behind the requirements. And then bring up doubts or implement it accordingly.

Avatar

About the author