Most engineering design docs are too long, too detailed, or worse — too short and too abstract. The good ones land at one of two sizes: short (1-2 pages, focused) or long (5-10 pages, comprehensive). The bad ones are everything in between.
Lead with the problem
One paragraph: what's wrong with current state, why it matters, what success looks like. If you can't write this paragraph, you don't understand the problem yet — go back to research. Most design docs start with the solution and lose the reader.
Two or three solutions, compared
List 2-3 plausible approaches. Pros, cons, tradeoffs of each. State why you picked the chosen one. This section convinces reviewers the decision wasn't 'we picked the first thing that came to mind'.
Detailed design — only what matters
Schema changes, API contracts, sequence diagrams for the non-obvious flows. Skip the obvious. Don't include code unless code is the point. If the doc reads like a tutorial, it's too detailed.
Failure modes and operational story
What breaks under load? What happens during deploys? Who pages when it fails? What's the rollback path? This section is short but absent in 70% of design docs. It's also what experienced reviewers ask about first.
Open questions
Things you haven't decided yet, things you need input on. Honest open questions invite engagement; pretending you've decided everything ends in surprise objections during implementation.