What goes in, and what does not

A design document exists to get a decision made, which means it is an argument rather than a description. Context first: what is happening and why now. Then requirements with numbers, constraints including cost and deadline, and only then the proposed design, ideally one diagram and the prose that explains the arrows. If a reader has to reach page three to learn what you are proposing, the document has failed at its job.

Rejected alternatives is the section that distinguishes a real document from a rationalisation. Two or three genuine options, each with why it was rejected and under what condition it would win. If every alternative is a straw man, reviewers correctly conclude the decision was made first and the document written afterwards, and they will start looking for what else you have hidden.

Finish with the parts that make it executable: failure modes and what the user sees, the metrics that will say whether this worked, the rollout plan including how to turn it off, and the cost. Keep it to a few pages. A forty-page document does not get reviewed, it gets approved, and those are very different outcomes.