If you typed design rationale example into a search bar, what you are really asking for is the one sentence you can defend when the room gets loud — the written half of defending a design decision. Not the process, not every path you tried, not the storyboard buried on slide 27. One sentence that names the change, the reason, and the check. Everything else is decoration or evidence, and neither survives the meeting.
The pressure to fill space is real because a generator will happily fill it for you. It will write the deck, the alt concepts, the slightly different modals, and it will do that faster than you can tell it not to. What it will not do is decide why the chosen one should exist. Your job is the why, and the rationale is where you write it down.
What a rationale actually is
The whole claim fits in a line: change X because Y, and we will know by Z. X is the smallest design change you can point at, the literal move you propose to ship. Y is the reason rooted in the person you are serving, not the quarter. Z is the behavior or metric that will move if you were right.
The power is in the boundaries the sentence draws. X forces scope: what exactly gets changed and what remains untouched this sprint. Y forces a defendable theory of cause, which is what separates you from taste. Z forces falsifiability, a moment in the future when you will decide whether to keep, roll back, or iterate.
This is why the sentence beats the slide. It cannot hide a missing reason behind ornate flows, it cannot pad over a shaky bet with eight icebox ideas, and it cannot be “future-proofed” to say nothing. It is brutally specific, which is the only thing your partners cannot outsource. The rationale is not prettier research. It is a decision you are willing to be wrong about.
What a rationale is not
A rationale is not a memoir of your week. The order your files were named is irrelevant, and so is the cute path that got you to the answer. It is not a collage of homework, not a moodboard of stakeholders quoted for color, not the six other options modeled to prove you explored. That is legibility theater, and it eats the oxygen your reason needs. The unsolicited redesign is its purest form: no business model behind the screen, so nothing to decide against.
It is not a restatement of goals or a duplicate of the brief. A goal is where you are going; a rationale explains why this exact turn gets you closer. It is not a negotiated middle between opinions, not an average of preferences, and not the emergent property of a voting session. Consensus is fine, but it does not constitute a reason.
It is not a universal law you can reuse intact. The same Y can support a different X next quarter, and the same Z can mislead if the environment changes. A rationale is local, time-bound, and specific to a state of knowledge. Treating it as a template is how teams slide into superstition and start shipping patterns that no longer serve anyone.
Finding your Y: defendable insight
Y is not a hunch dressed as a post-it. It is an insight about the person at the time they act, phrased so clearly that someone else can bet against it. If the reason would fit on a poster, it is probably a slogan. If it makes a falsifiable prediction about what the person will do next and why, you are in range.
There are only a few reliable places Y comes from. You can extract it from direct observation of the behavior you want, from credible analogues, or from a public principle in psychology that matches the specific state you can induce. Everything else is conjecture, which is not sinful, but it should be labeled before it makes its way into a roadmap.
If you do not trust your supply of reasons, train it on purpose. Start with the skill of generating actionable insights and hold yourself to a higher bar than quotes that fit your slide. The tell is that a good Y survives the wording changing. The person, the moment, and the trade they face remain solid when you rewrite the caption.
Choosing your Z: make the decision falsifiable
Z is not a dashboard. It is the single check that will force a decision in the smallest number of days. It should be the first place the effect would appear if your reason is correct, not the prettiest chart. If nobody can say what happens if Z does not move, you have a summary, not a rationale.
When the thing you are changing is supposed to trigger an action, write Z as a behavior, not a percentage. Name the action, the segment, the time window, and the prompt that will call it into being. If it requires a specific cue to happen, make sure it exists in your design and in your analytics plan.
If no prompt exists, add one, and make it specific enough to test. If you need a refresher, revisit designing explicit prompts and tie the cue to the moment the person can act. A testable Z needs a switch to flip and a clock to read.
Precision here is not pedantry; it is mercy. A Z that is too far downstream will bury your effect in noise and keep bad bets alive for months. A Z that is too close to the UI will measure clicks that do not add up to a win for the person. You are looking for the narrow ridge where behavior meets outcome.
Writing it so it survives review
Put the sentence first, alone, and without apology. Then give your partners the minimum they need to test the claim: the before and after of X, the evidence or reasoning behind Y, and the plan to read Z. Do not ask for trust. Ask for a shared bet, and write down how you intend to lose it if you are wrong. When the review ends with a stakeholder choosing the other path, the rationale is what lets you turn the overrule into a bet with a deciding check.
Avoid the two default failures of review: drowning the reason in artifacts or performing certainty you do not have. If you needed to sketch twelve options to find X, you can mention that without showing eleven you will never ship. If Y is a conjecture, say so, and anchor it with the smallest Z that can retire it quickly.
Write for the decider who is not in the room. They will not meet your personality or hear your caveats; they will receive a screenshot and a sentence forwarded in haste. Make the sentence do the work without you. Strip adjectives, kill metaphors, and remove any phrasing that lets someone agree with you and still ship the opposite. And when that decider is the executive room, reorder the case so the decision leads instead of arriving on the last slide.
Strong: Replace the onboarding checklist with a single completion target because splitting attention across five tasks suppresses first-week momentum, and we will know by the share of new teams that complete one meaningful action within 48 hours of signup when prompted in-product. Weak: Improve onboarding to increase activation, measured by retention later. One is a bet you can argue. The other is a wish.
Strong: Move the upgrade offer from email to the billing screen because upgrade intent spikes at the moment of friction, and we will know by the uplift in same-session plan changes on failed payment attempts. Weak: Redesign billing because people do not like it, measured by NPS. Again, one names a behavior at a moment. The other hides the moment and measures a vibe.
Document the decision, not the journey
Documentation that helps the next person is two things, no more: the sentence that drove the change and the outcome against Z. The rest is noise six weeks from now. A future teammate needs to know why you turned left and whether left paid off. They do not need your entire notebook to be useful to them.
Write the rationale at the moment you propose the change, not after the fact when the story has been tidied. Then come back to the doc to staple the result next to it, including the part that hurt. If Z moved and you shipped, capture the counterfactual you killed. If Z did not move, say so in the same plain words you used to make the bet, because a retired reason is the only note that makes the next one cheaper.
Write one this week
Take the next change you are about to propose and write the line before you open the file. Name an X small enough to point at, tie Y to something a person does at a moment you can find, and pick a Z you can read within a fortnight. Whichever of the three resists being written is the part you have not decided yet.
Practise it where constraints push back, not on an invented product where every answer is defensible. Read a brief with a real constraint in it and write the sentence you would defend, or work through briefs written the way clients actually write them. The sentence is the part of the deliverable nobody can hand you finished.
