Design doc review is the highest-leverage time you spend on a project. Catching the wrong-approach problem here saves weeks of rework. The questions you ask shape what kind of reviewer you are.
Is the problem stated clearly?
Half of design docs jump to solutions. Push back if you can't summarize the problem in one sentence after reading. 'Reduce checkout p99 from 800ms to 200ms because cart abandonment correlates with latency' is a clear problem. 'Refactor the cart service' is not.
What are the alternatives?
Any decent design considered at least two approaches. Why was this one picked? If alternatives aren't documented, the author probably didn't seriously consider them — which means the chosen approach is whatever felt natural. Push for the comparison.
Where does this break?
Capacity at 10x, at 100x. Failure modes — what happens when X is down? Operational story — who pages when this breaks? Migration story — how do we get from current state to here? Docs that skip these are aspirational.
What are the new dependencies?
New library, new service, new database. Each is operational debt. Each one needs justification. 'We'll use Redis because we already have it' is good; 'We'll use ScyllaDB because it's fast' needs a much higher bar.
Reversibility check
If we ship this and find out in 3 months it was wrong, what's the rollback? Schema changes are hard to reverse. New protocols are hard to reverse. New behaviors users depend on are very hard to reverse. Bias toward reversible decisions for risky areas.