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.

Navigating Nuances: Specific Language for Non-Native Speakers

Rejecting a design document can feel incredibly delicate. It’s easy to unintentionally sound harsh or dismissive, especially when you’re striving for clear communication. For developers whose first language isn’t English, the nuances of professional feedback – particularly around criticism – can be particularly challenging. The goal is always to offer constructive suggestions that help improve the document without damaging the relationship with the designer or architect. Let’s focus on building a vocabulary and approach that prioritizes clarity and respect.

One key area is using precise language when describing what’s not working. Instead of saying “This isn’t good,” which feels vague, try phrases like “The current architecture presents some scalability challenges,” or “From a maintainability perspective, the complexity here might introduce risks.” Notice the addition of technical terms – ‘scalability,’ ‘maintainability,’ ‘complexity’ – these are common in design discussions and demonstrate you’ve considered the problem deeply. Another helpful tactic is to frame your feedback around potential issues rather than stating them as absolute truths. “It’s possible that this approach could lead to…” allows the designer space to consider alternative solutions. Similarly, avoid judgmental language like “This is a bad idea.” Instead, you might say, “I’m concerned about the potential impact on performance with this particular implementation; perhaps we could explore [alternative suggestion]?”

Furthermore, it’s crucial to acknowledge any positive aspects of the design before raising concerns. Starting with “I appreciate the effort put into outlining this system” or “The initial diagram clearly illustrates the core components” demonstrates respect and sets a collaborative tone. This softens the blow and shows you’re building upon their work, not simply dismantling it. Remember that in Slack conversations, brevity is important, but so is precision. A long, rambling critique can be overwhelming. Crafting concise messages with carefully chosen words will significantly improve understanding.

Finally, always offer a clear suggestion for moving forward. Don’t just point out problems; propose solutions. “Could we investigate using [technology/pattern] to address this?” or “Perhaps we could refactor this module into smaller, more manageable units?” provides actionable guidance. Ending with an open question – “What are your thoughts on…” – encourages dialogue and collaboration rather than a definitive rejection. Remember, the goal isn’t just to reject; it’s to help refine the design towards a better outcome.