Skip to content

The PUXD Design Rationale Structure: A Complete Guide

The short answer

Most attempts to document design decisions fail in one of two ways: they are too heavy, so they don’t get done, or too vague, so they don’t help. The PUXD Design Rationale Structure is light enough to use under delivery pressure and complete enough that the reasoning survives without the person who recorded it. It records five things about a decision, and no more: the decision itself, the evidence or reasoning that led to it, the alternatives considered and why they were rejected, the constraints that shaped it, and the conditions under which it should be revisited.

Why most design documentation fails

Documenting design decisions is one of those practices that almost everyone agrees is valuable and almost no one does consistently. The reason is that most documentation approaches fail in one of two predictable ways.

The first failure is weight.

A documentation process that requires a lengthy write-up, a dedicated tool, or a meeting to complete is a process that does not survive contact with delivery pressure. When a sprint is running and a decision needs to be made and recorded in the same afternoon, a heavyweight process gets skipped. The documentation that does not get done helps no one.

The second failure is vagueness.

A documentation process that captures only a vague summary — ‘we decided to simplify the checkout’ — is technically complete but practically useless. It records that a decision was made without recording what would let a future person evaluate it. The documentation that gets done but says nothing useful also helps no one.

What is needed is a structure that sits between these failures: light enough to use under pressure, complete enough that the reasoning transfers. The PUXD Design Rationale Structure is designed to be exactly that. It records five elements, and deliberately no more.

The five elements

1. The decision

Plainly state what was decided. Not the discussion around it, not the options on the table, just the decision as it was actually made. For example, ‘We removed the summary page from the quotation journey.’ This sounds trivial, and it is the element most frequently skipped — which is precisely why so many decisions become ambiguous within weeks. A clear statement of the decision is the anchor everything else attaches to. Without it, the record describes a conversation rather than a decision.

2. The evidence or reasoning

Record what was known at the time the decision was made. This is research findings, analytics, testing results, or the specific reasoning applied where direct evidence was not available. For example, ‘Usability testing with eight participants showed six found the summary page confusing rather than reassuring.’

The point of this element is to capture what informed the decision, not to argue that the decision was correct. This is the distinction between rationale and justification: you are recording what you knew, not building a case for what you chose. Where you did not have direct evidence and reasoned from principle or experience, say so — an honest record of reasoning under uncertainty is more useful than a false impression of evidence.

3. The alternatives considered and why they were rejected

Record what was deliberately not chosen and why. This is the element most often missing, and the most valuable when a decision is revisited. A future reader needs to know not only what was chosen but what was rejected — because the obvious alternative is usually the first thing a challenger proposes.

‘We considered keeping the summary page but making it collapsible; we rejected this because testing showed the confusion came from the content of the summary, not its prominence.’ Recording why an alternative was rejected the first time saves the team from relitigating it. When someone later proposes that exact alternative, the record already contains the answer.

4. The constraints that shaped the decision

Record the conditions the decision was made within: technical limits, policy requirements, timeline pressures, organisational realities. ‘The decision had to work within the existing quotation engine, which could not support a partial save at the summary step.’

Constraints change. A decision that made complete sense under one set of constraints may need revisiting when they shift. Recording the constraints makes that judgment possible. A future reader can see whether the conditions that shaped the decision still apply, or whether a constraint that forced a particular choice has since been lifted.

5. The conditions under which the decision should be revisited

Record what would justify reconsidering the decision. This is the element that turns a record into a living decision. ‘This should be revisited if we introduce longer quotation journeys, where a summary may behave differently, or if analytics show drop-off concentrated at the point the summary used to occupy.’

By naming in advance what would justify a change, you give your future self and your colleagues a clear test. The decision is not permanent and does not pretend to be — it is valid until specified conditions change. This element is also what makes a decision review-resistant in the productive sense: it welcomes legitimate challenge (has this condition been met?) while deflecting mere preference (do you have grounds, or just an alternative?).

It is a thinking discipline, not a document format

The structure is not a specific template or tool. It is a thinking discipline that can be recorded in whatever place works best for your team. The five elements can live in a research repository, a decision log, a design file, or a delivery ticket. What matters is not the format but that the five elements are captured. Together they produce reasoning that transfers.

This flexibility is deliberate. A structure that mandated a specific tool would reintroduce the weight problem, and it would fail wherever that tool was not used. By defining the structure as five things to capture rather than a format to fill in, it can adapt to however your team already works. The discipline is in capturing all five, consistently, not in where they are written down.

What this structure produces

A decision recorded with all five elements can be understood, evaluated, and challenged on the right terms by someone who was never in the room. They can see what was decided, what informed it, what was rejected and why, what constraints applied, and what would justify a change. That is everything a future reader needs to either uphold the decision against an illegitimate challenge or revise it in response to a legitimate one.

This is the difference between a decision that survives handover and one that evaporates the moment its author leaves. It is the structural solution to the problems the rest of this series describes: the reversals, the relitigating, the institutional forgetting. None of those problems are solved by trying harder to remember or communicate. They are solved by capturing five specific things at the moment a decision is made.

Frequently asked questions

What is the PUXD Design Rationale Structure?

The PUXD Design Rationale Structure is a five-element framework for documenting design decisions in a form that survives handover. It records the decision itself, the evidence or reasoning that led to it, the alternatives considered and why they were rejected, the constraints that shaped it, and the conditions under which it should be revisited. It is designed to be light enough to use under delivery pressure and complete enough that the reasoning transfers to someone who was not part of the original decision.

How do you document a design decision effectively?

Document a design decision by capturing five things: what was decided (stated plainly), what evidence or reasoning informed it, what alternatives were considered and why they were rejected, what constraints shaped it, and under what conditions it should be revisited. Together these produce a record that a future reader can understand, evaluate, and challenge on the right terms. The format doesn’t matter — a decision log, research repository, or delivery ticket all work — but all five elements need to be captured.

What should a design decision record include?

A complete design decision record includes five elements: the decision as it was actually made, the evidence or reasoning that informed it, the alternatives that were considered and rejected (with the reasons for rejection), the constraints the decision was made within, and the conditions that would justify revisiting it. The alternatives element is the most often skipped and the most valuable on review, because the obvious alternative is usually the first thing a future challenger proposes.

Why do most design decision documentation efforts fail?

Most design documentation fails by being either too heavy or too vague. Heavyweight processes that require lengthy write-ups or dedicated tools get skipped under delivery pressure. Vague summaries that record a decision was made without capturing the reasoning are technically complete but practically useless. An effective structure sits between these failures — light enough to use under pressure, complete enough that the reasoning survives. Capturing five specific elements achieves that balance without mandating a particular format.