review · Feedback, Decision Making · 30–60 min · 3-20 people · low energy

Design Doc Review

Before building something significant, the author writes a short document: context and scope, goals and non-goals, the proposed design and the alternatives considered with their trade-offs. Close colleagues help iterate on it, then a wider group reviews it in comment threads. A live review meeting is used only when comment threads cannot settle a point.

When to use Design Doc Review

Use for any significant plan, not just software, where mistakes are cheap to fix on paper and expensive to fix later.

What it solves

Teams discover design problems after the work is built, because nobody outside the team saw the plan in time.

How to run Design Doc Review, step by step

  1. The author writes the doc: context and scope, goals and non-goals, the design, alternatives considered and trade-offs (2-6 hours, author only).
  2. Quick iteration with two or three close colleagues to reach a stable first version (async, 1-3 days).
  3. Share with the wider review group and a deadline. Reviewers comment in threads (30-60 min each, async).
  4. The author answers every thread, changes the doc or explains why not.
  5. If threads stay unresolved, hold a short live review on those points only (30 min).
  6. Record the decision at the top of the doc and keep it updated if the plan changes during delivery.

Materials needed

  • Shared document with comments
  • Doc template
  • List of reviewers and a deadline

Facilitator tips

  • Non-goals matter as much as goals. They prevent long debates about things nobody intends to do.
  • Ask for the most important feedback early and do not let a slow review block all progress.
  • Keep reviews proportionate. A small change does not need a formal review meeting.

Common pitfalls

  • The doc describes the chosen solution but not the alternatives, so reviewers cannot judge the trade-offs.
  • Review becomes a gate that takes weeks, and teams start skipping it.

Variations

  • Use the same structure for non-technical proposals such as programme designs or policy changes.

Running it online or hybrid

Runs mostly async in comment threads on a shared document, with an optional live review meeting for contested points.

What it produces

A reviewed design document with resolved comment threads, recorded trade-offs and a decision.

Origin

Described by former Google engineer Malte Ubl in Design Docs at Google (2020), covering how Google teams write and review design docs. — source

Build a session around Design Doc Review

METODIC places Design Doc Review inside a complete, timed session plan — agenda, worksheets, facilitator guide and slides — matched to your group and goal.

Generate a session with Design Doc Review · Try METODIC free