Explaining design decisions to skeptical stakeholders
The design is done; now you have to defend it to a PM, an engineer, and a VP who each care about different things. Translating design decisions into the language of user evidence, business goals, and tradeoffs is where a lot of designers lose the room. A tight decision doc, tailored to the audience, keeps the review about the work instead of about opinions.
You are a design lead writing a concise decision document to help a design review go smoothly. Audience and what they care about: {{audience}}. The decision: {{decision}}. The evidence and alternatives I have: {{evidence_and_options}}. Write a one-page rationale with these sections: - Problem: the user problem in one or two sentences, in plain business language. - Options considered: each alternative with its main tradeoff. - Recommendation: the chosen direction and the top three reasons, tied to user evidence and business goals. - Tradeoffs and risks: what we are giving up and how we would mitigate it. - What we would measure: the signal that tells us this worked. Constraints: translate design and UX jargon into language a product manager, an engineer, and an executive would each understand. Use ONLY the evidence I provided — do not invent research findings, usage metrics, user quotes, or competitor facts. Any claim I did not give you must be written as [NEEDS DATA], not stated as fact. Keep it to roughly one page and lead with the recommendation for skim-readers.
Fill in your details and the prompt updates live — then copy.
**Recommendation:** Move verification to after the first save, not before signup. **Problem:** New users abandon at the verification wall before seeing any value (drop-off figure is [NEEDS DATA] — I have not confirmed the exact number). **Why:** (1) Users experience the core flow first; (2) fewer steps before the "aha" moment; (3) aligns with the Q3 activation goal you set. **Tradeoff:** A window of unverified accounts — mitigate with a verify-before-share gate. **We'd measure:** activation rate and share of accounts verified within 24 hours.
The full workflow
- Gather the real evidence and alternatives before prompting — the doc is only as good as its inputs.
- Run the prompt with your audience clearly described.
- Fill or cut every [NEEDS DATA] flag — never present an unverified number as fact.
- Rewrite the recommendation in your own voice, then circulate it before the review.
Watch out for
Never let AI invent research findings, metrics, or user quotes to strengthen your case — fabricated evidence is a serious trust and ethics failure, and it collapses the moment someone checks.
Keep unreleased strategy, roadmap, and confidential metrics out of consumer AI tools; share only what your NDA and company policy allow.
Where this comes from
Every use case on this site is grounded in real reports from working ux designers — not invented by us.