How to Give Feedback That Rejects a Design Doc in English

Rejecting a design doc is a genuinely uncomfortable piece of feedback to give well, because vague disapproval (“I have some concerns”) leaves the author unable to act, while blunt disapproval can read as dismissive of real effort. The vocabulary here is about being specific and direct while still leaving the author a clear, respectful path forward.

Key Vocabulary

Blocking concern — an issue serious enough that the design shouldn’t move forward as written, distinguished explicitly from a suggestion or preference, so the author knows exactly which feedback requires a revision versus which is optional. “I have one blocking concern: the design assumes single-writer access to this table, but we already have two services writing to it concurrently. Everything else in the doc reads well, but this needs to be resolved before we proceed.”

Unaddressed failure mode — a specific scenario the design doesn’t account for, named concretely rather than as a general “what about edge cases” comment, which gives the author something precise to investigate rather than an open-ended worry. “There’s an unaddressed failure mode here: what happens if the second write in this two-phase operation fails after the first one succeeds? The doc doesn’t currently describe any recovery path for that state.”

Alternative not considered — a viable approach the design doc doesn’t mention or rule out, raised as a genuine question rather than a demand, since the author may have already considered and rejected it for reasons not yet in the doc. “I don’t see an alternative considered here — did you evaluate using an existing queue instead of building custom retry logic? If you did and ruled it out, it’d help to add a sentence explaining why, since it’s the first thing I expected to see.”

Path forward — an explicit statement of what happens next, whether that’s a specific revision needed, a follow-up conversation, or a narrower proposal, which is what turns a rejection from a dead end into a concrete next step. “The path forward here is straightforward: address the concurrent-writer issue, and I’m happy to re-review just that section rather than the whole doc again. I don’t think this needs a full rewrite.”

Common Phrases

• “I have a blocking concern, separate from the suggestions below, that I think needs to be resolved before this moves forward.”
• “There’s an unaddressed failure mode I want to flag: what happens if [specific scenario]?”
• “I don’t see an alternative considered for [specific approach] — was that evaluated?”
• “To be clear about the path forward: [specific, scoped next step].”
• “This is strong work overall, and the concern is specific and addressable, not a rejection of the underlying approach.”

Example Sentences

Opening a rejection without being discouraging: “This is a well-written doc, and I appreciate the thoroughness of the alternatives section. I do have one blocking concern that I think needs to be addressed before we move forward, though — let me walk through it.”

Naming a specific gap rather than a vague objection: “My concern isn’t with the overall approach, it’s a specific unaddressed failure mode: the doc doesn’t describe what happens on a partial write failure during the migration step. That scenario needs an explicit answer.”

Ending with a scoped, actionable path forward: “I’d suggest revising just the failure-handling section and looping me in for a quick follow-up review, rather than treating this as a full rejection requiring a whole new doc.”

Professional Tips

• Separate a genuine blocking concern from optional suggestions explicitly, ideally in its own labeled section — burying a real blocker among a dozen minor comments means the author may not realize which feedback is actually required before proceeding.
• Name any unaddressed failure mode as a specific scenario, not a general “what about edge cases” comment — a concrete scenario gives the author something to actually investigate and answer, where a vague prompt just produces anxiety.
• Ask about an alternative not considered as a genuine question, not an implied criticism — the author may have already ruled it out for good reasons that simply didn’t make it into the doc, and framing it as a question invites that context rather than putting them on the defensive.
• Always close with an explicit path forward — a rejection without a next step reads as a dead end, while a scoped, specific path forward reframes the same feedback as a solvable problem rather than a setback.
• Acknowledge genuine strengths in the doc specifically, not as a generic softener — specific praise (“the failure-mode analysis in section 3 is thorough”) is more credible and more useful than a blanket “good work” before delivering the concern.

Practice Exercise

1. Write a sentence clearly separating a blocking concern from optional feedback.
2. Name a specific unaddressed failure mode for a hypothetical caching design.
3. Write a closing path-forward statement that scopes the required revision narrowly.