Structural Design

Design Rationale

Design rationale is the documented reasoning behind a design decision, including the problem, evidence, alternatives, trade-offs, constraints, and expected consequences.

Concept facts

Design rationale is the documented reasoning behind a design decision, including the problem, evidence, alternatives, trade-offs, constraints, and expected consequences.

Also known as
Design reasoning, rationale documentation, decision rationale, design justification.
Used in
Product design, service design, design systems, UX governance, accessibility decisions, design QA, research reporting, and implementation planning.
Interpret with
Design system, component, design quality assurance, research finding, UX insight, decision log, assumption mapping, and UX governance.

Plain-language explanation

Design rationale explains why a design decision was made. It captures the reasoning behind the choice, not just the final design. The rationale helps future teams understand the decision and avoid reversing it without context.

Why it matters

Design decisions are often made under constraints. If the rationale is not documented, future teams may misunderstand the design, repeat old debates, or remove important features during redesign.

Use contexts

  • documenting important interface, service, content, or component decisions
  • explaining why one design option was chosen over another
  • preserving research evidence behind design choices
  • reviewing design system patterns
  • handing work between teams or vendors
  • supporting governance in regulated or institutional systems

Application guidance

Document the problem, options, evidence, constraints, selected decision, and trade-offs. Keep rationale concise, connect it to findings where available, and include rejected alternatives when they matter.

Practical example

A public health dashboard uses a prominent “urgent referral” label instead of only a color-coded status. The rationale records that color alone was rejected because it would not support users with color-vision differences and could be missed by busy clinic staff. The UX consequence is patient-safety risk, staff workflow burden, and decision risk in high-pressure clinical referral review.

Interpretive boundaries

Design rationale should not be used to defend poor decisions. It should document reasoning and evidence, including uncertainty and trade-offs. Not every small design choice needs formal rationale.

Applied at Userhub

Userhub uses design rationale to support transparent design decisions across UX Lab recommendations, TDS implementation, content patterns, accessibility choices, and service design work.

See Userhub UX Lab for applied UX research and evaluation context.

Sources and references

MacLean, A., Young, R. M., Bellotti, V. M. E., & Moran, T. P. (1991). Questions, options, and criteria: Elements of design space analysis. Human-Computer Interaction, 6(3–4), 201–250. https://doi.org/10.1080/07370024.1991.9667168

Moran, T. P., & Carroll, J. M. (Eds.). (1996). Design rationale: Concepts, techniques, and use. Lawrence Erlbaum Associates.

Tyree, J., & Akerman, A. (2005). Architecture decisions: Demystifying architecture. IEEE Software, 22(2), 19–27. https://doi.org/10.1109/MS.2005.27

Cite this entry

APA

Userhub. (2026). Design Rationale. UX Reference. https://userhub.com.bd/reference/design-rationale/