Documents the reasoning behind design decisions including alternatives considered, trade-offs evaluated, and principles applied.
SkillScore100Maintained
Automatic
◆Design & UX Review pack
Last verified 8/19/2026
What it changes
Passed 25 of 25 test cases with the skill, and 15 of 25 without it.
Without skill60%
With skill100%
Checks it passed that the model alone missed
Includes a section for decision history.
Includes a section tracking decision history.
Includes a dedicated Decision History section.
and 13 more in the full report
10 fixed15 passed either way0 still failing0 broke
Pass-rate lift
+40 pp
Tokens
+39%
Agent turns
0%
Response time
+8%
Model gemini-3.6-flashMeasured 8/19/2026v125 of 25 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 10
Prompt
We just decided to switch our mobile application from a bottom navigation bar to a slide-out hamburger menu. Can you draft a design rationale document for this choice? Please include a concise summary of the decision, the background problem and constraints, 3 alternative UI layouts we evaluated, how we assessed them, the trade-offs we accepted, and any follow-up metrics we should track.
What was checked, without and with the skill
Checked
Without skill
With skill
Includes a section explicitly analyzing decision reversibility.
Missed
Passed
Includes a section for supporting materials or references.
Missed
Passed
Includes a section tracking decision history.
Missed
Passed
case-01 · gemini-3.6-flash · 8/19/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md65 lines3 files
Design Rationale
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.
When to Use
When making significant UX decisions that affect user experience
Before design reviews to prepare stakeholder discussions
When multiple valid approaches exist and the choice needs justification
To onboard new team members to existing design decisions
When revisiting past decisions to understand original reasoning
During design system evolution to document pattern choices
When NOT to Use
The decision is architectural or a technology selection -> use develop-adr (Nygard format)
You need stakeholder alignment on the overall solution direction -> use develop-solution-brief
You are documenting exploration findings rather than a decision -> use develop-spike-summary
The decision is trivially reversible and low-stakes: a rationale document adds ceremony; record the reasoning in the PR or ticket instead
Instructions
When asked to document design rationale, follow these steps:
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.