<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
A design rationale document captures the "why" behind design decisions.the context, constraints, alternatives considered, and reasoning that led to a particular solution. While designs themselves show what was built, rationale documents preserve institutional knowledge about why it was built that way.
-
State the Decision
Begin with a clear, one-sentence summary of what design decision was made. This becomes the title and reference point for the document.
-
Describe the Context
Explain the situation that prompted this decision. What problem were you solving? What constraints existed? What user needs informed the direction? Include relevant research findings.
-
List Options Considered
Document at least 2-3 alternatives that were evaluated. For each option, describe what it would look like and its key characteristics. Be fair to all options.avoid strawmen.
-
Define Evaluation Criteria
Specify how options were assessed: usability heuristics, technical feasibility, brand alignment, user research findings, business requirements, or design principles.
-
Explain the Reasoning
Walk through why the chosen option best meets the criteria. Be explicit about trade-offs.what you gained and what you sacrificed. Acknowledge where the decision is reversible vs. irreversible.
-
Document Trade-offs Accepted
Every design decision involves trade-offs. Name what you gave up and why it was acceptable. This honesty helps future teams understand constraints.
-
Note Follow-up Considerations
Capture anything that needs attention later: metrics to watch, conditions that might warrant revisiting the decision, or related decisions to make.