The Intent Ledger
← All articles

Stop Rework: 6 Field Decision Memo Template for Design Teams

Stop Rework: 6 Field Decision Memo Template for Design Teams

Architect comparing material samples for a decision

A decision memo template, in design work, should be a single, source-backed ILM Record that names the decision in one sentence and links directly to the meeting or transcript that produced it. Use lightweight records for reversible, low-stakes calls, and switch to a full template once a decision touches budget, infrastructure, or the user experience at scale. Every record needs at least one linked artifact, whether that’s a meeting timestamp, a transcript snippet, or a piece of client feedback, so nobody has to reconstruct the reasoning from memory six months later.

TL;DR:

  • Use lightweight decision records for simple, reversible choices like design tweaks, requiring only six fields and minimal effort.
  • For major decisions affecting budget or infrastructure, adopt the full template that includes context, evidence, and consequences, typically taking longer to document.
  • Store decision records in accessible locations such as code repositories, Notion, or design comment tools, ensuring easy retrieval and lifecycle management.
  • Attach specific source links like meeting timestamps, transcript clips, or feedback threads to maintain traceability and prevent future re-litigations.
  • Write the decision sentence first and keep records honest and concise, avoiding bundling multiple decisions or vague reasoning to ensure clear auditability.
Theintentledger
Keep Every Design Decision Traceable
The Intent Ledger turns conversations, feedback, and meeting notes into source-backed records that preserve the reasoning behind design decisions.
Explore The Intent Ledger

Table of Contents

What Fields Belong in a Decision Memo Template?

A decision record only works if it forces you to answer the same questions every time. Skip a field and you get a memo that reads like a to-do note instead of a record anyone can audit later.

Every ILM Record needs these components:

  • Title: a monotonic number plus a short label, like “0014 vertical login stack,” so records stay browsable and tooling can sort them.
  • Date: when the decision was made, not when someone got around to writing it up.
  • Decision: one sentence, stated as a headline, not a summary of the debate.
  • Status: proposed, accepted, or superseded, with a link to whatever record replaced it.
  • Context or problem: the constraint that forced a choice in the first place.
  • Alternatives considered: two to four options, each with a short reason it lost.
  • Rationale and evidence: linked artifacts, not paraphrased memory.
  • Consequences and risks: what this decision trades away.
  • Owner and reviewers: who is accountable and who signed off.
  • Linked artifacts: meeting notes, a transcript clip, client feedback, or a critique thread.
  • Revisit conditions: the trigger that should force a second look.
  • Outcome or linked metric: filled in later, once the decision has had time to prove itself.

Keep one decision per record. Teams that have logged over 200 decision records across three years found that bundling multiple choices into one document makes evaluation nearly impossible, because nobody can tell which part of the reasoning applies to which outcome. Write the decision headline first, then support it with bullets, the same inverted-pyramid structure Martin Fowler recommends for architecture decision records. A reviewer should understand the call in the first ten seconds, not after reading four paragraphs of backstory.

Pro Tip: Write the decision sentence before you write anything else. If you can’t compress the call into one clean sentence, you probably haven’t actually decided yet.

For a longer breakdown of these fields and how they map to source conversations, see this record of decision guide.

Which Decision Memo Template Should You Use?

Not every choice deserves a full write-up. The trick is matching the format to the stakes, not defaulting to whichever template is open in your browser tab.

The lightweight template works for craft-level calls: spacing tweaks, a component variant, a copy change. It needs only six fields, similar to the six-field decision log format many design teams already use informally.

  1. Decision: one sentence.
  2. Why: one to three sentences.
  3. Alternatives: one line each, no elaboration.
  4. Date: when it happened.
  5. Owner: who made the call.
  6. Revisit-if: the condition that reopens the question.

A real example: “Decision: use a 48px tap target for the mobile nav, not 40px. Why: usability testing flagged mis-taps at 40px on three of five sessions. Alternatives: 40px (rejected, too many mis-taps), 56px (rejected, crowds the header). Revisit-if: nav item count grows past six.”

The full template is for decisions that change infrastructure, contracts, major user flows, or budget. It includes everything the lightweight version has, plus context, evidence links, consequences, linked artifacts, and a revisit schedule tied to an outcome metric.

A real example: “Decision: migrate the design system tokens to a single source of truth in Figma variables. Context: three teams maintained drifting token sets, causing visual inconsistency across four products. Alternatives: keep per-team tokens (rejected, drift will continue), build a custom sync script (rejected, adds a maintenance burden with no owner). Evidence: linked Figma audit and engineering time estimate. Revisit: check adoption rate at 90 days.”

The line between the two isn’t length. It’s reversibility. If undoing the decision costs an afternoon, go lightweight. If undoing it costs a sprint, write the full version.

Which Decision Memo Template Should You Use? — overview diagram

Where Should You Store Decision Records?

Storage location decides whether a record gets used or forgotten. Pick a spot your team already opens daily, not a folder that becomes a graveyard.

Three patterns work well for design teams:

  • Markdown files in the repo (a doc/adr folder), which Google Cloud’s architecture guidance recommends for teams working close to code, since the record and the artifact it describes live in the same place.
  • A Notion database, better for cross-discipline teams where not everyone touches the repo, with tags for project, component, and decision type.
  • Figma comments or Linear attachments, useful for design-adjacent calls but weaker for long-term search since they get buried under unrelated threads.

Whichever you pick, keep the monotonic numbering and the proposed/accepted/superseded status lifecycle. When a new decision overrides an old one, link the new record back to the old one and flip its status, rather than editing history quietly. Build a simple cadence: write the record right after the call, get one peer review, attach the artifacts, then return in about two weeks to fill in the outcome field. Tag every record by project and component so filtering by “decision type” actually works when someone searches six months out. A decision log template can give you a starting structure if you’re setting this up for the first time.

A decision record without a source link is just an opinion with a date stamp. Traceability is what turns a memo into evidence.

Attach specific pointers, not vague references:

  • A meeting timestamp, the speaker’s name, and a one or two sentence quote.
  • A direct link to the transcript file itself, with the larger context living there instead of copy-pasted into the record.
  • A critique feedback anchor or comment thread link, if the decision came out of a design review.
  • A support ticket or research doc link, when the evidence originated from user complaints or usability sessions.

Keep the excerpt inside the record short: one or two sentences, timestamp, speaker. Anything longer belongs in the linked artifact, not the memo. When you have a choice of evidence, prioritize first-party tests and session recordings over internal analytics, and treat published research as background context rather than proof.

Pro Tip: If you can’t find the ten-second clip or the exact quote that triggered a decision, that’s usually a sign the decision was made in a hallway conversation nobody wrote down. Fix that at the source, not by inventing a citation after the fact.

This habit does something subtle but valuable: it stops teams from re-litigating settled decisions every few months, because anyone can pull up the original evidence instead of relying on secondhand memory. A tool like automated meeting note capture makes this step nearly frictionless, since the transcript link already exists by the time you write the record.

How Do You Keep a Decision Memo Clear and Short?

The biggest failure mode isn’t missing information. It’s burying the decision under context nobody asked for yet.

Write the decision sentence first, every time, even in your rough draft. If you find yourself explaining the backstory before stating what was decided, flip the order. State conclusions before justifications, the same structure journalists use for a reason: readers who stop after the first sentence should still know the outcome.

Use plain verbs. “We chose X because Y” beats “It was determined that X would be the preferred approach.” Passive constructions hide who actually made the call, which defeats the purpose of an owner field.

Cut adjectives that don’t carry information. Words like “significant,” “robust,” or “optimal” tell the reader nothing about what actually happened. Replace them with the number, the constraint, or the specific tradeoff.

Limit alternatives to the ones seriously considered. Listing five options when only two were realistic just adds noise a future reader has to wade through.

Finally, write the consequences section honestly, including the downside of the choice you made. A record that only lists upside reads like marketing copy, and readers can tell the difference. The experimental research on documenting design rationale found that structured rationale capture measurably improved both individual and team decision quality, but only when the records were honest enough to be useful, not just complete enough to check a box.

What Do Completed Decision Memos Look Like in Practice?

Seeing a filled-out record does more than any field list can. Here are three, compressed to the essentials.

A freelance architect’s material choice: “0007 exterior cladding swap. Decision: switch from fiber cement to reclaimed brick veneer. Alternatives: stay with fiber cement (rejected, client wants texture), use stucco (rejected, doesn’t match neighborhood character per zoning review notes). Evidence: linked client call transcript, timestamp 14:32. Owner: lead architect. Revisit-if: supplier pricing changes again before permit filing.”

A design team lead’s UX call: “0021 checkout flow reduction. Decision: cut checkout from four steps to two. Context: cart abandonment data flagged in critique session. Alternatives: keep four steps with progress bar (rejected, doesn’t address root cause), add guest checkout only (rejected, doesn’t fix step count). Evidence: linked analytics dashboard and critique feedback thread. Owner: design lead. Reviewers: PM, engineering lead. Outcome (filled two weeks post-launch): abandonment dropped, noted in linked metric.”

A design student’s coursework decision: “0002 typography pairing. Decision: pair a serif headline with a grotesque body font. Why: instructor feedback flagged the original pairing as low contrast. Alternatives: two serif fonts (rejected, too similar), two grotesque fonts (rejected, lacks hierarchy). Revisit-if: final critique flags legibility issues again.”

Each example stays short because the record’s job is to point somewhere, not to contain everything.

What Mistakes Undermine a Decision Memo?

Most decision memos fail quietly. They get written, filed, and then nobody trusts them enough to check later.

The most common mistake is writing the record after the decision has already been forgotten, weeks later, from memory. Details soften, alternatives get flattened, and the record ends up documenting a cleaner version of events than what actually happened. Write it the same day.

A close second: skipping the “rejected because” reasoning for alternatives. Listing options without explaining why they lost gives future readers no way to tell if circumstances have changed enough to reconsider one.

Bundling multiple decisions into one record is another frequent error, and it’s the one that causes the most confusion during later evaluation, since nobody can isolate which choice led to which consequence.

Leaving the outcome field blank forever is a quieter failure. A record with no outcome update is a promise nobody kept. Set a calendar reminder for two weeks after ship, and treat that follow-up as part of the job, not an optional extra.

Finally, watch for records that never get revisited even after the “revisit-if” condition triggers. A condition with no owner watching for it is decorative, not functional. Assign someone, even informally, to notice when a revisit condition fires.

How Should Decision Memos Differ by Role or Team?

A junior designer and a studio principal don’t need the same template, even when they’re documenting similar decisions.

Individual contributors and design students get the most value from the lightweight, six-field version. The goal at this level is building the habit, not producing exhaustive documentation. A student pairing typography choices or a junior designer picking a component variant should be writing one-paragraph records that take two minutes, not twenty.

Decision memo templates matched to team roles

Team leads and project managers need the full template for anything that affects deliverables, timelines, or client expectations, since these records often get pulled into status reports or client reviews later. At this level, the owner and reviewers fields matter more, because accountability across a team is the whole point.

Studio principals and architects working on material or contractual decisions need the full template with tighter evidence requirements, since these records sometimes surface again during disputes or change orders. Linking the actual client email or transcript, not a paraphrase, protects everyone.

Freelancers sit in an odd middle ground: solo enough that the lightweight template usually covers daily work, but client-facing enough that any decision touching scope or budget deserves the full version, since it doubles as a paper trail if a client questions a choice later. A scope-focused client portal approach pairs well here, since keeping decisions and client conversations in one visible place reduces the back-and-forth that usually triggers scope disputes in the first place.

Why Bother Writing These Down at All

The real payoff shows up months in, not on day one. Teams that keep decision records stop re-arguing settled questions, because someone can pull up the original reasoning instead of relitigating it from memory. That alone saves more time than the records cost to write.

The objection I hear most is time. Fair, but a lightweight record takes less time than the meeting that produced the decision. Start there. Don’t try to backfill your entire project history; start logging from today forward and let the habit compound.

The underrated benefit is trust. A record that honestly says “we were wrong, here’s what changed” builds more credibility with a team, and with future hires reviewing your work, than a record that pretends every call was correct from the start.

— Rajas

How the Intent Ledger Turns Conversations Into Records

Writing a decision record by hand still requires someone to remember which meeting the reasoning came from, dig up the transcript, and paste in the quote. Software available on the market can turn your project conversations, meeting notes, and transcripts directly into structured, source-backed ILM Records, so the traceability this whole approach depends on happens automatically instead of manually.

Theintentledger

The workflow is simple: a meeting transcript gets auto-linked to the moment a decision was made, an ILM Record gets created with the context already attached, you assign an owner, and the outcome field sits ready for you to fill in once the work ships. No hunting through old Slack threads or guessing which call a rationale came from.

If you’re documenting decisions solo or for a small studio, the Working Set product line starts at $12 one-off, and the Working Memory plan runs $29 per month for ongoing capacity as your project record grows. Studios managing multiple active projects can look at Studio Ledger or the Shared Ledger plan for team-wide access. Check current pricing and plans or visit the product page to see how ILM Records work before you commit.

Sources

FAQ

What Is a Decision Memo Template?

A decision memo template is a structured, single-page record that captures one decision, the reasoning behind it, and a link to the source conversation or transcript. In design work, this is often called an ILM Record, built specifically to trace back to meetings, notes, and feedback.

How Long Should a Decision Memo Be?

A lightweight decision memo should fit in six short fields and take a few minutes to write. A full memo for material decisions runs longer but still stays on one page, following the brevity principle behind architecture decision records.

Do I Need a Full Template for Every Decision?

No. Use the lightweight version for reversible, low-impact choices like a component variant or spacing tweak, and reserve the full template for decisions touching budget, infrastructure, contracts, or major user flows.

Attach a timestamp, the speaker’s name, a one or two sentence quote, and a direct link to the transcript or artifact where the fuller context lives. Tools like The Intent Ledger automate this link at the moment a transcript is processed.