Design rationale, critique and decision records · Proficient · Lesson 80 of 99 · about 3 hours
Keeping design decision records
After this you can write a design decision record (context, options, decision, consequences, status) and run a lightweight decision log a team actually uses.
Why it matters
Engineering teams have long used architecture decision records: short, dated documents that capture one significant decision, the context it was made in, the options considered, and its consequences. The same practice transfers directly to design and is starting to be adopted by design-system teams. It stops the most expensive pattern in product work (relitigating a settled question every time someone new joins) and it lets you reopen a decision cleanly when its context changes. Focus on keeping each record short and writing it when the decision is made. Trap: a decision log that records what was decided but not why, which is the part anyone actually needs later. There is no good free video on design-specific decision records; the written sources below are the best available, and they come from engineering.
How to use this resource
The reference hub for decision records, with the common templates (including Michael Nygard's original). Written for software architecture; read it with 'design decision' in mind: the structure transfers unchanged.