The one-page design doc shape (problem statement, options considered, recommendation), why including a rejected option strengthens the doc, and getting real written feedback before treating anything as final.
Published September 23, 2026
1. Problem Statement — what's actually broken/needed, and why it matters NOW
2. Options Considered — 2-3 real alternatives, each with genuine trade-offs stated
3. Recommendation — which option, and the specific reasoning for choosing it
A design document's value comes almost entirely from making REASONING visible and reviewable BEFORE code gets written — not from being exhaustive. A one-page doc covering these three sections forces real clarity: a problem statement that's actually specific (not "improve the checkout flow" but "checkout currently times out for 2% of users during peak load because X") is itself a useful filter — if you can't state the problem precisely, you likely don't yet understand it well enough to propose a solution. This directly mirrors the 5-step HLD interview framework's insistence on stating requirements explicitly before any design — a design doc IS that same discipline, applied to a real system rather than an interview prompt.
Option A: [chosen] — do X
Option B: [rejected] — do Y instead. Rejected because Z (a real, honest reason)
A design doc that presents only ONE option, framed as the obvious right answer, hides the actual reasoning process behind the recommendation — a reader can't evaluate whether genuine alternatives were considered, or just assess whether the single proposed option sounds reasonable in isolation. Explicitly including at least one REJECTED option, with the actual reason it was rejected (not a strawman version of it, weakened to make the chosen option look better by comparison), shows the REASONING TRAIL — this is what lets a reviewer engage with the actual decision, not just the conclusion, and it's often what surfaces a genuinely better option a reviewer sees that the author missed.
A design doc that's written and immediately acted on, without anyone else's genuine engagement, has skipped the entire POINT of writing it down in the first place — the value isn't the document itself, it's the REVIEW PROCESS the document enables. Written feedback (not just a verbal "looks good" in a hallway conversation) specifically matters because it creates a genuine record of what was actually reviewed and what concerns were raised — directly analogous to Volunteer for PR Reviews' point about review comments being a durable, readable record, applied here to a design decision instead of a code change. A design doc that gets ONE person's quick verbal nod isn't meaningfully reviewed — getting at least one substantive written response, ideally from someone who could reasonably disagree, is the actual bar.
Q: How is a one-page design doc different from a full System Design Interview Playbook-style write-up? A: Scope and audience — an interview design walkthrough demonstrates BROAD reasoning ability across an entire hypothetical system to an evaluator; a real design doc is scoped tightly to ONE actual decision for an actual team that will act on it, deliberately kept SHORT specifically so it gets read and engaged with rather than skimmed past; brevity is a feature of a real design doc, not a limitation.
Q: What if there genuinely isn't a strong alternative option worth including? A: This is itself worth stating explicitly rather than fabricating a weak strawman alternative just to fill the section — 'the main alternative considered was doing nothing / deferring this, rejected because [reason]' is a legitimate, honest version of the options section when the actual solution space is genuinely narrow.
Q: Should a design doc be written before or after some exploratory prototyping? A: Often a mix — enough exploration to state the problem and options CONCRETELY (not purely theoretically) is usually necessary, but writing the doc BEFORE committing to full implementation is the actual point, since the doc's value is catching a flawed direction while it's still cheap to change, not after significant work is already sunk into one approach.
Q: How does a design doc's recommendation differ from just picking whatever the author already wanted to build? A: The options-considered section is the actual check against this — a recommendation that emerges from genuinely engaging with real alternatives and their trade-offs (even if the author suspected the answer going in) reads very differently from, and holds up to review much better than, a recommendation that's really just a justification written backward from a predetermined conclusion; reviewers who ask 'why not option B' are specifically testing for this.