Keep a design decision log that explains the tradeoff
Record consequential design choices with their context, options, evidence, rationale, owners, and review triggers so a future teammate can understand the decision without reconstructing a meeting.
Preserve why the team made a choice
A design decision log preserves why a team chose one approach over another. Without it, a future teammate may see a workshop-booking pattern and mistake a temporary constraint for a permanent principle. Record decisions that have meaningful consequences, rather than attempting to document every minor adjustment made during design.
Record context, options, and review triggers
Keep the entry concise: the question, context, options considered, relevant evidence, decision, rationale, and conditions for review. Identify who owns the decision and use the actual date when it is made. Separate a confirmed decision from a provisional experiment. Link to supporting artifacts without requiring someone to search an entire meeting recording. Identify who will contribute, who will make the decision, and who will use the resulting artifact. Those roles may overlap, but making them explicit helps prevent a discussion from ending with unowned work. Provide enough context for someone absent from the meeting to understand the next step. Preserve meaningful disagreement and its rationale rather than editing the record into a consensus that participants never actually reached.
Log a filter-update decision
Write an example entry about choosing an explicit Apply filters action for a reference library. Compare it with immediate updates and describe the relevant task and implementation constraints. Mark any assumed benefit as an assumption. Add a review trigger, such as a change in the filter model or evidence that the current behavior obstructs the task. Try reading the artifact after a break, as someone who missed the original conversation might. Look for unexplained terms, unsupported claims, and missing transitions between the question and the proposed action. Ask another person to check the same route. These passes improve the clarity of the working material; they do not justify claims about participant behavior or product performance that the project has not actually investigated.
Revisit conditions rather than defending history
If an entry records only the winning option, it cannot explain the tradeoff. If it treats a stakeholder preference as research evidence, correct the classification. If the underlying condition changes, revisit the decision rather than citing the old entry as authority. The log should preserve reasoning while allowing the product to evolve. A polished output can hide weak inputs. Inspect any confident statement that lacks a traceable source or a clearly labeled assumption. If the team cannot explain its basis, turn it into a question and assign a next step. This is more useful than softening the wording while leaving the same unsupported conclusion in place. Presentation should make the state of knowledge clearer rather than lend authority to uncertainty.
Check that another person can follow the reasoning
Review a sample entry by asking a colleague to explain the choice and identify when it should be reconsidered. Remove unnecessary meeting detail while preserving consequential disagreement or uncertainty. Keep the log findable beside the project artifacts. Its value is continuity of reasoning: people can modify the product deliberately without repeatedly rediscovering the same constraints or defending an obsolete choice.
Worked decision
Record why Apply filters was chosen, which alternative was considered, and what changed condition would justify revisiting the decision.
References & further reading
Examples and exercises in this guide are original teaching scenarios.
