Keep a Decision-Documentation Trail

Workflow area: Design Ops · Tier: Foundation · Hands-on time: ~25 minutes per project milestone

Design decisions evaporate. Six months later the file shows only the winner, the critique notes are in someone's dead Slack thread, and a new PM asks "why don't we just do C?" — a question that costs a week to re-answer from scratch. The raw material for the answer already exists: version history, archived exploration pages, critique comments. AI is good at assembling scattered raw material into a narrative draft. You are the only one who knows if the narrative is true — the drafted "because" is a hypothesis about your own reasoning until you confirm it.

When to use — and when not to

• Use it at every design milestonedirection chosen, handoff shipped, feature killed; the trail is written at the moment of decision or never.
• Use it when archiving explorationspb-04's throwaway pages plus harvest notes are exactly the input this recipe consumes.
• Use it for your portfolio pipelinea year of decision records is a case study that writes itself, with real reasoning instead of retrofitted narrative.
• Skip it for trivial callsbutton-color-level decisions don't need records; documenting everything means the important records drown.
• Skip AI drafting for politically sensitive decisionsa record of why the CEO's pet direction lost gets written by a human, carefully, or deliberately not at all.

The recipe

1. 1.

   Gather the raw material at the decision moment. Screenshot the explored directions (including the dead ones), export or copy critique comments from the Figma file, and pull any decision messages from Slack or meeting notes. Ten minutes of collection — the drafting is only as good as this pile.

2. 2.

   Draft the decision record. In Claude or ChatGPT:

   Copy

   Draft a design decision record from these materials.
   
   Decision: [ONE LINE — e.g. "approval-flow direction for Q3 expense
   feature"]
   Directions explored: [LIST A/B/C WITH ONE-LINE DESCRIPTIONS,
   ATTACH SCREENSHOTS]
   Critique notes & comments: [PASTE]
   Constraints in play: [e.g. "no new API work this quarter"]
   
   Structure:
   1. CONTEXT — the problem and the forcing constraints (2-3 lines)
   2. DIRECTIONS — each direction: what it was, its core bet, why it
      was set aside or chosen. Use only reasons present in my notes.
   3. DECISION — what we chose and the 2-3 decisive reasons
   4. REVISIT-IF — conditions under which this decision should be
      reopened
   5. EVIDENCE LINKS — [I will fill these in]
   Where my notes don't state a reason a direction died, write
   [REASON NOT RECORDED — CONFIRM] instead of inventing one.
   

3. 3.

   Correct the "because" — this is the step that matters. The model will produce plausible reasoning; plausible is not what happened. Good output after your edit looks like:

   Copy

   DIRECTION C — chat-based approvals. Set aside: [REASON NOT
   RECORDED — CONFIRM]
   → edited to: Set aside because support data showed approvers
   distrust conversational confirmations for money (see Q2 tickets),
   NOT because of engineering cost — worth re-testing if trust
   changes.
   

   Every [CONFIRM] gets resolved from memory while memory exists. Every drafted reason gets read with the question "is that actually why?"

4. 4.

   Attach the record where the decision lives. A page in the Figma file next to the archived explorations, plus the same text in your team's Notion/Confluence decision log. Fill in real links: the exploration page, the critique thread, the research it leaned on (pb-03's evidence-linking discipline applies here too).

5. 5.

   Make "revisit-if" do real work. The record's most future-valuable line is the condition that reopens it — "revisit if mobile usage passes 40%," "revisit if the API constraint lifts." When a new teammate proposes direction C next year, the record either says why that's still wrong or admits the conditions changed. Both outcomes are wins.

Make it yours

• Notion AI inside the decision log: if your team logs decisions in Notion, draft the record there directly — Notion AI can summarize the linked critique page as input, and the record lands pre-indexed in the workspace search that new hires actually use.
• Claude Project per product area: accumulate the decision records in a Project and ask cross-cutting questions — "what constraints keep killing our mobile ideas?" — turning the trail into design-strategy memory, not just archaeology.
• Meeting-notes pipeline: if design reviews are recorded (Granola or similar per pb-10), route the notes into step 1 automatically — the biggest failure mode of decision records is the gathering friction, and this removes most of it.

Quality check

• Every reason is one that actually happenedthe drafted narrative is coherent by construction; check it against memory and notes before it becomes the official past.
• Dead directions kept their dignityrecords that flatten losers into strawmen teach the next reader nothing; the real bet and the real reason it lost is the value.
• Every [CONFIRM] was resolvedan unresolved placeholder becomes a permanent hole exactly where the question will land later.
• Evidence links are real and reachablea decision record citing an unshared file is a decision record that will fail its first reader.
• Revisit-if conditions are observable"revisit if priorities change" is decoration; a condition someone could actually notice firing is the standard.