As part of helping our customers to succeed at doing things they want to do, we want to be thoughtful about what we do and how we do it. Writing our ideas down can help us to clarify, improve, and communicate our ideas—both for ourselves and for each other. By writing down our ideas in design notes (DNs), which is our special term for “design documents”, we can have a central place to keep track of input and feedback in internal discussions which are important for our processes and products, so that they won’t get lost in comments or meeting notes before we can identify specific tasks/projects for them. And, compared to Notion tasks, design notes can organize information about systems and processes in a way that will be easier and more complete for new employees to consume during onboarding. Most importantly, design notes are a place where we can partially capture, refine, and share our mental models and theories underlying the systems we create (as in Peter Naur’s 1985 article Programming as Theory Building).
As precedents, see:
The following are examples of when a DN is appropriate; these are intended to be broad:
DNs can be used to communicate not only technical ideas but also overall company ideas and processes. If you have an idea to improve the way something is being done as a company, you have the power to make your voice heard by making a proposal in a DN or adding to a discussion on an existing DN.
When you start a DN and share it for discussion, it doesn’t have to be polished or detailed. Instead, through the process of reviewing, discussing, and revising a draft DN, we will make it more polished and complete. This is why we call them “design notes” rather than “design documents”.
When writing DNs for determining technical direction and product direction, as well as other ideas, it helps to consider various aspects of determining the right direction: