Rationale vs Justification: The Difference That Makes Design Decisions Defensible

The short answer

Most design documentation looks like a record of reasoning but is actually a defence of a conclusion. Rationale explains why a decision was made; what was known, what was weighed, what alternatives were considered, and why the chosen option won. Justification explains why a decision was right; it argues backward from the conclusion, assembling support for a decision already made. Justification is advocacy disguised as documentation. Only rationale survives contact with a future reader, because only rationale gives the next person what they need to evaluate whether the original reasoning still holds.

The distinction most documentation gets wrong

Design documentation is supposed to record reasoning. Much of it does something subtly different: it defends a conclusion. The two look similar on the page, which is why the distinction is so easy to miss and so consequential when it is missed.

Rationale is a record of how a decision was reached. It captures what was known at the time, what options were on the table, what considerations were weighed, and why the chosen option was selected over the alternatives. It is written forward, from the situation to the decision.

Justification is a defence of a decision already made. It starts from the conclusion and works backward, assembling the supporting points that make the decision look sound. It is advocacy, and like all advocacy, it is constructed to convince rather than to inform. The difference is not always visible in the tone. It is visible in what the document allows a future reader to do.

The same decision, documented two ways

The difference is easiest to see in practice. Two designers document the same decision: removing a progress indicator from a checkout flow.

The first writes that progress indicators add cognitive load and distract users from the task, and that the cleaner design improves completion. This reads like reasoning when it is actually justification — a set of supporting claims assembled to make the decision look correct. It tells a future reader what the designer believed. It gives them no way to test whether the belief still applies.

The second writes that usability testing with eight participants showed six ignored the indicator entirely and three said it made the form feel longer than it was; that removing it reduced task completion time by twelve percent on retest; and that they would reintroduce it if testing on longer forms showed different behaviour. This is rationale, and it tells a future reader what the designer knew, under what conditions, and what would change the decision.

If the decision is revisited in eighteen months, only the second version is useful. The first tells the next person what the original designer thought, but the second tells them what the original designer knew and, crucially, under what conditions the decision should change. One is a closed argument, the other, a usable record.

Why justification is seductive

Justification is the more natural thing to write, for two reasons:

1. It is easier; arguing for a conclusion you have already reached requires less effort than reconstructing the reasoning that got you there.
2. It makes the decision look stronger; a well-constructed justification reads as confident and authoritative.

But that strength is an illusion when it comes to durability. Justification is useless to anyone who was not already convinced, because it offers no way to test whether the decision still applies. It cannot be reasoned with. It can only be agreed or disagreed with. A future reader who encounters a justification has two options: accept it or reject it. They cannot evaluate it, because the information they would need to evaluate it — what was known, what was weighed, what would change the decision — was never recorded.

Rationale is more useful precisely because it is less rhetorically strong. It exposes the conditions and the uncertainty. It admits what was not known. And in doing so, it gives the next person the materials to make their own judgment about whether the decision still holds — which is exactly what a durable decision record needs to do.

How to write rationale instead of justification

The practical test is simple. After writing a decision record, ask: does this tell the reader what I knew, or what I believed? Does it expose the conditions under which the decision was made, or does it argue that the decision was correct? Could a future reader use this to make the same decision again from scratch — or only to agree with the decision I already made?

Writing rationale means recording the evidence as evidence, not as support. It means naming the alternatives that were considered and rejected, rather than presenting the chosen option as the only sensible one. It means stating the conditions under which the decision should change, rather than implying it is permanent. And it means being honest about what was not known — the gaps and assumptions that a justification would paper over. 

This is harder to write and less satisfying to read. It is also the only form of documentation that does the job documentation is supposed to do: transfer reasoning to someone who was not there, in a form they can actually use.

Instead of asking how to explain why a design is right, ask what someone would need to know to make the same decision again from scratch.

Frequently asked questions