What I found really interesting in this article was the idea of using stories to effectively convey ideas, through different mediums, and the differences and similarities of using them. Building a shared understanding is not necessarily the same thing as simply reading the same document detailing a process together, and instead involves a deeper approach towards being on the same page.
The example of the vacation photo rings especially true in this case. Having gone through the experience themselves, the author easily recalls the memory captured by the picture, and can recall minute details such as the drive over and the turtles on the beach. However, just showing the photo to a stranger would likely not evoke these memories, being a snapshot of a moment instead of capturing a memory.
This reminds me of how historically documentation is done, and how I did documentation in the past. Usually, it would just be pages and pages of instructions, of terminal screenshots and expected program return values. While this is helpful, it’s not necessarily the most effective way of communicating what my program did. In fact, it’s not necessarily what we want to do in the first place. Trying to crank out autowritten documentation isn’t helping many people — often being confusing, and difficult to understand. Instead, we should be creating our stories in a way that’s user intuitive, and offers the greatest amount of impact than just following a series of requirements blindly.
This idea of a story complements the use of documentations and requirements nicely. You no longer have a series of steps you must follow, instead, you build an understanding of what’s necessary, and what provides the greatest amount of impact to the most amount of people.
