Ask for Three Designs Before You Pick One

A design pattern where you ask Claude to propose three distinct approaches to a problem — with their trade-offs — before it writes any code or commits to one, then you choose and only then build.

Ask for one design and you get the first plausible one, anchored to whatever Claude reached for first. Ask for three genuinely different ones and you force the solution space open: a simple version, a scalable version, a ship-it-today version. Seeing them side by side surfaces trade-offs you'd otherwise discover halfway through implementation.

Decisions that are expensive to reverse — data models, API shapes, sync-vs-async boundaries, where state lives. Anywhere the second-best option is nearly as good and you want to choose deliberately.

Small, reversible choices where any reasonable design works. Generating three options for a helper function is ceremony that slows you down.

I need to design <the thing>. Constraints: <list>.

Propose three genuinely different approaches. For each, give: the core idea in two sentences, what it optimises for, its main downside, and when it stops working. Make them real alternatives, not the same design with cosmetic changes. Do not write implementation code yet — end by recommending one and saying why.

For a notifications system you get: (A) synchronous send on request, simplest but couples latency to email; (B) an outbox table drained by a worker, more moving parts but resilient; (C) a hosted queue, least code but a new dependency. You pick the outbox, and Claude's implementation already knows the trade-off it's honouring.

Add a required 'do nothing / defer' option as a fourth. Forcing Claude to argue for not building the thing yet often reveals that the real constraint is unknown, and the best next move is a spike or a measurement rather than a design.

• Accepting three options that are secretly the same design — push back and demand a real spread across the trade-off axis.
• Letting Claude jump straight to code on option two before you've compared all three.
• Choosing the most sophisticated option by default; the simplest one that meets the constraints usually wins.