develop-design-rationale

Name: develop-design-rationale
Author: product-on-purpose

486stars64forks

How to install develop-design-rationale?

product-on-purpose/pm-skills/develop-design-rationale

$npx -y skills add product-on-purpose/pm-skills --skill develop-design-rationale

Installs into the current project.

Summary

Documents the reasoning behind design decisions including alternatives considered, trade-offs evaluated, and principles applied. Use when making significant UX decisions, aligning with stakeholders on design direction, or preserving design context for future reference.

Files · 1

View on GitHub

SKILL.md

1	<!-- PM-Skills \| https://github.com/product-on-purpose/pm-skills \| Apache 2.0 -->
2	# Design Rationale
3
4	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.
5
6	## When to Use
7
8	- When making significant UX decisions that affect user experience
9	- Before design reviews to prepare stakeholder discussions
10	- When multiple valid approaches exist and the choice needs justification
11	- To onboard new team members to existing design decisions
12	- When revisiting past decisions to understand original reasoning
13	- During design system evolution to document pattern choices
14
15	## When NOT to Use
16
17	- The decision is architectural or a technology selection -> use `develop-adr` (Nygard format)
18	- You need stakeholder alignment on the overall solution direction -> use `develop-solution-brief`
19	- You are documenting exploration findings rather than a decision -> use `develop-spike-summary`
20	- The decision is trivially reversible and low-stakes: a rationale document adds ceremony; record the reasoning in the PR or ticket instead
21
22	## Instructions
23
24	When asked to document design rationale, follow these steps:
25
26	1. State the Decision
27	Begin with a clear, one-sentence summary of what design decision was made. This becomes the title and reference point for the document.
28
29	2. Describe the Context
30	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.
31
32	3. List Options Considered
33	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.
34
35	4. Define Evaluation Criteria
36	Specify how options were assessed: usability heuristics, technical feasibility, brand alignment, user research findings, business requirements, or design principles.
37
38	5. Explain the Reasoning
39	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.
40
41	6. Document Trade-offs Accepted
42	Every design decision involves trade-offs. Name what you gave up and why it was acceptable. This honesty helps future teams understand constraints.
43
44	7. Note Follow-up Considerations
45	Capture anything that needs attention later: metrics to watch, conditions that might warrant revisiting the decision, or related decisions to make.
46
47	## Output Format
48
49	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.
50
51	## Quality Checklist
52
53	Before finalizing, verify:
54
55	- [ ] Decision is clearly stated in one sentence
56	- [ ] Context explains the "why now" and constraints
57	- [ ] Multiple alternatives are documented fairly
58	- [ ] Evaluation criteria are explicit
59	- [ ] Reasoning addresses why chosen option beats alternatives
60	- [ ] Trade-offs are honestly acknowledged
61	- [ ] A reader who inherits this design can reconstruct why the chosen option won without asking anyone
62
63	## Examples
64
65	See `references/EXAMPLE.md` for a completed example.

People who liked this also viewed

6 picks

Type

develop-design-rationale

486stars64forks

View on GitHub

How to install develop-design-rationale?

product-on-purpose/pm-skills/develop-design-rationale

$npx -y skills add product-on-purpose/pm-skills --skill develop-design-rationale

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	<!-- PM-Skills \| https://github.com/product-on-purpose/pm-skills \| Apache 2.0 -->
2	# Design Rationale
3
4	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.
5
6	## When to Use
7
8	- When making significant UX decisions that affect user experience
9	- Before design reviews to prepare stakeholder discussions
10	- When multiple valid approaches exist and the choice needs justification
11	- To onboard new team members to existing design decisions
12	- When revisiting past decisions to understand original reasoning
13	- During design system evolution to document pattern choices
14
15	## When NOT to Use
16
17	- The decision is architectural or a technology selection -> use `develop-adr` (Nygard format)
18	- You need stakeholder alignment on the overall solution direction -> use `develop-solution-brief`
19	- You are documenting exploration findings rather than a decision -> use `develop-spike-summary`
20	- The decision is trivially reversible and low-stakes: a rationale document adds ceremony; record the reasoning in the PR or ticket instead
21
22	## Instructions
23
24	When asked to document design rationale, follow these steps:
25
26	1. State the Decision
27	Begin with a clear, one-sentence summary of what design decision was made. This becomes the title and reference point for the document.
28
29	2. Describe the Context
30	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.
31
32	3. List Options Considered
33	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.
34
35	4. Define Evaluation Criteria
36	Specify how options were assessed: usability heuristics, technical feasibility, brand alignment, user research findings, business requirements, or design principles.
37
38	5. Explain the Reasoning
39	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.
40
41	6. Document Trade-offs Accepted
42	Every design decision involves trade-offs. Name what you gave up and why it was acceptable. This honesty helps future teams understand constraints.
43
44	7. Note Follow-up Considerations
45	Capture anything that needs attention later: metrics to watch, conditions that might warrant revisiting the decision, or related decisions to make.
46
47	## Output Format
48
49	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.
50
51	## Quality Checklist
52
53	Before finalizing, verify:
54
55	- [ ] Decision is clearly stated in one sentence
56	- [ ] Context explains the "why now" and constraints
57	- [ ] Multiple alternatives are documented fairly
58	- [ ] Evaluation criteria are explicit
59	- [ ] Reasoning addresses why chosen option beats alternatives
60	- [ ] Trade-offs are honestly acknowledged
61	- [ ] A reader who inherits this design can reconstruct why the chosen option won without asking anyone
62
63	## Examples
64
65	See `references/EXAMPLE.md` for a completed example.

People who liked this also viewed

6 picks

Type