develop-design-rationale
The develop-design-rationale skill documents the reasoning and context behind significant UX design decisions, capturing alternatives considered, evaluation criteria applied, and trade-offs accepted. Use it when making consequential design choices that affect user experience, preparing for design reviews, onboarding teams to existing decisions, or evolving design systems, but not for technology selections or exploration findings.
git clone --depth 1 https://github.com/product-on-purpose/pm-skills /tmp/develop-design-rationale && cp -r /tmp/develop-design-rationale/skills/develop-design-rationale ~/.claude/skills/develop-design-rationaleSKILL.md
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 --> # 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: 1. **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. 2. **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. 3. **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. 4. **Define Evaluation Criteria** Specify how options were assessed: usability heuristics, technical feasibility, brand alignment, user research findings, business requirements, or design principles. 5. **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. 6. **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. 7. **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. ## Output Format Use the template in `references/TEMPLATE.md` to structure the output. A complete rationale fills every template section: Decision Summary; Context; Options Considered; Evaluation; Decision Rationale; Trade-offs Accepted; Reversibility; Follow-up Considerations; Supporting Materials; and Decision History. ## Quality Checklist Before finalizing, verify: - [ ] Decision is clearly stated in one sentence - [ ] Context explains the "why now" and constraints - [ ] Multiple alternatives are documented fairly - [ ] Evaluation criteria are explicit - [ ] Reasoning addresses why chosen option beats alternatives - [ ] Trade-offs are honestly acknowledged - [ ] A reader who inherits this design can reconstruct why the chosen option won without asking anyone ## Examples See `references/EXAMPLE.md` for a completed example.
Run an ad-hoc ordered chain of pm-skills with shared context (ephemeral; routes to the pm-workflow-orchestrator)
Defines a testable hypothesis with clear success metrics and a validation approach. Use when forming assumptions to test or aligning a team on what success looks like, before any experiment is designed. To design the A/B test or experiment that will validate the hypothesis, use measure-experiment-design.
Creates a Jobs to be Done canvas capturing the functional, emotional, and social dimensions of a customer job. Use when deeply understanding customer motivations, designing for jobs, or reframing product positioning.
Creates an opportunity solution tree connecting a desired outcome to customer opportunities and candidate solutions, preventing solution-first jumps in continuous discovery. Use when structuring scattered feature ideas or communicating how the roadmap traces to outcomes. For ranking an existing flat list of candidates, use define-prioritization-framework instead; this skill discovers the list, it does not score one.
Run applicable prioritization frameworks (RICE, ICE, MoSCoW, Weighted Scoring, Kano) against a list of features or initiatives. Produces a comparison table showing where rankings agree and diverge across frameworks, and an executive summary with recommendation. Framework applicability is filtered by data availability; Kano requires customer research. Refuses to fabricate scores; produces an estimation scaffold when input data is missing.
Creates a clear problem framing document with user impact, business context, and success criteria. Use when starting a new initiative, realigning a drifted project, or communicating up to leadership.
Generates structured Given/When/Then acceptance criteria for a user story or feature slice, covering the happy path, key failure scenarios, and non-functional expectations in testable form. Use when turning requirements into verifiable scenarios for engineering handoff and QA sign-off. For a dedicated catalog of boundary conditions, error states, and recovery paths across a feature, use deliver-edge-cases; to write the stories themselves, use deliver-user-stories.
Documents edge cases, error states, boundary conditions, race conditions, and recovery paths for a feature - the systematic catalog of what can go wrong and the failure modes to design for. Use during specification to map the failure surface and ensure comprehensive coverage, or during QA planning to identify boundary and limit scenarios to test. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the whole-feature edge-case catalog.