Writing the Alternatives Considered Section
Entry format, section intro, honest evaluation, recommendation framing, and time-bound rejections
Alternatives Considered essentials
- Entry format: alternative name + advantage + limitation + rejection reason tied to a specific requirement
- Section intro: number of alternatives + names upfront + structure signal
- Honest evaluation: every rejected alternative must have stated advantages — only negatives signals bias
- Recommendation: chosen option + why it wins on deciding criteria + why others fail those same criteria
- Time-bound rejections: "rejected now because X — reconsider when Y" prevents repeated analysis
Question 0 of 5
Which "Alternatives Considered" entry is written most effectively?
Alternative name + advantage + limitation + rejection reason tied to a specific requirement. Alternatives Considered entry formula:
- Alternative name: "MongoDB" — clear label
- Advantage: "flexible schema suits unstructured event data" — honest credit; shows the team evaluated it seriously
- Limitation: "lacks ACID transactions; high migration cost" — specific technical reason tied to the system's actual requirements
- Rejection reason: "payment integrity requirement is non-negotiable" — links the rejection to a requirement, not a preference
- It demonstrates rigorous evaluation, not bias
- A future reader who wants to challenge the decision can see exactly what was weighed
- If the requirements change (e.g., payment processing is removed), the reader knows MongoDB becomes viable again
How should you introduce the Alternatives Considered section in a Design Doc?
Open with the number of alternatives + name them + signal the structure. Alternatives Considered section intro formula:
- Count: "three approaches" — tells the reader how much to expect; also signals the evaluation was bounded and rigorous
- Named upfront: "[A], [B], and [C]" — allows the reader to jump to the one they care about
- Structure signal: "trade-offs and the reason it was not selected" — tells the reader what each entry will contain
- There are almost always alternatives — if you can't name them, you likely didn't look hard enough
- Writing "no alternatives" signals to reviewers that the author may have a bias toward the chosen approach
- Exception: if the design is constrained by a decision already made (e.g., "we must use the existing Auth service — this is not a choice we can change"), say so explicitly
A Design Doc's Alternatives Considered section lists three options, all of which are described negatively with no advantages. What is the problem?
Honest evaluation: every considered alternative had a reason it was considered — find and state that reason. Signs of biased Alternatives Considered:
- Every alternative has only weaknesses, no strengths
- The advantages of the chosen approach appear in the alternatives' weakness section ("unlike Approach B, Approach A has...")
- Alternatives are described in vague terms while the chosen approach gets technical detail
- Understand what was possible at the time
- Re-evaluate if requirements change
- Trust that the chosen approach was selected through rigorous analysis, not preference
Which recommendation sentence in an Alternatives Considered section is most effective?
Recommendation = chosen option + why it wins on the deciding criteria + why others fail those same criteria. Recommendation sentence formula:
- What: "Option B (event-driven async processing)" — named and characterised
- Why it wins: "the only approach that meets our two non-negotiable requirements" — links to the Goals section
- The deciding criteria: "sub-100ms API response time; zero message loss" — explicit, testable
- Why others fail: "Option A fails response time at scale; Option C violates our SLA" — closes the loop on each rejected option
- The requirements (argue in the Goals section)
- The evaluation of how options perform against requirements (testable claim)
When should a rejected alternative be "kept on record" for future consideration, and how should this be noted?
Flag time-bound rejections: "rejected now because X — reconsider when Y". Constraint-bound rejection language:
- ❌ "Option C rejected — too complex." — permanent-sounding rejection for what may be a temporary constraint
- ✅ "Option C (Kafka) rejected: our team lacks Kafka operational expertise. Revisit when the platform team is onboarded in Q3 — at that point the operational burden moves to them and the complexity concern is resolved."
- If the constraint is resolved and the team adopts Kafka, a reader wondering "why didn't we use Kafka from the start?" gets the answer
- It prevents the same analysis being done again when the constraint lifts
- It signals intellectual honesty: "this was the right choice now, not forever"