{"enrichment":{"faq":[{"a":"develop-design-rationale helps you systematically capture the \"why\" behind UX choices. Start by identifying the decision context\u2014what problem prompted the choice, who was involved, and what constraints applied. Document the alternatives you evaluated, the trade-offs you accepted, and the reasoning that led to your final solution. Include relevant data, user research, or business factors that influenced the outcome. This structured approach ensures your design rationale is clear, traceable, and useful for future reference.","q":"How to document design decisions and reasoning?"},{"a":"develop-design-rationale emphasizes capturing decision context, alternatives considered, and the reasoning behind your choice. A strong template covers: the design decision itself, the problem it addresses, alternatives you evaluated and why you rejected them, key trade-offs you accepted, supporting evidence or research, stakeholders involved, and the date documented. This structure makes your rationale easy to review with stakeholders, onboard new team members, and revisit when circumstances change or questions arise later.","q":"What should a design rationale template include?"},{"a":"develop-design-rationale recognizes that design decisions carry institutional knowledge that fades quickly without documentation. Preserving context helps new team members understand not just what was chosen, but why\u2014reducing re-litigation of settled choices and accelerating onboarding. It also protects against knowledge loss when team members leave and enables teams to revisit past reasoning when requirements shift, making it easier to decide whether to adapt an existing solution or reconsider the original trade-offs.","q":"Why preserve design context and decision history?"},{"a":"develop-design-rationale prepares your design reasoning for stakeholder review by making your decision process transparent and defensible. When you document alternatives considered, trade-offs accepted, and the reasoning behind your choice, stakeholders can see the full picture rather than just the final outcome. This clarity reduces pushback based on misunderstanding, enables informed discussion about whether trade-offs remain acceptable, and builds confidence that the design was thoughtfully considered rather than arbitrary.","q":"How can design rationale help with stakeholder alignment?"},{"a":"develop-design-rationale emphasizes documenting the compromises inherent in any design choice. Capture what you gained with your solution and what you gave up\u2014whether that's simplicity versus power, performance versus flexibility, or cost versus quality. Explain why you weighted those trade-offs the way you did given your context, constraints, and user needs. This honesty about trade-offs helps teams understand the decision's limits and makes it easier to revisit the choice if priorities shift or new information emerges.","q":"What trade-offs should design rationale capture?"},{"a":"develop-design-rationale focuses on capturing UX and interaction design reasoning\u2014the \"why\" behind choices about user experience, interface patterns, and interaction flows. While both preserve decision history, design rationale emphasizes user impact, alternatives evaluated, and design thinking, whereas architecture decision records typically address technical system structure. Both serve similar preservation and alignment goals but operate at different levels; you may use both to document different aspects of a complex product decision.","q":"How does design rationale differ from an architecture decision record?"}],"shadow_tags":["decision-documentation","design-justification","stakeholder-alignment","trade-off-analysis","institutional-knowledge","design-context","alternatives-evaluation","design-governance"],"summary_rewrite":"Capture the \"why\" behind design choices by documenting decision context, alternatives evaluated, and reasoning that led to your solution. This skill preserves institutional knowledge about design decisions, helping teams onboard to existing choices and revisit past reasoning when needed."},"files":[{"bytes":4108,"path":"skills/develop-design-rationale/SKILL.md","sha256":"853395279e4da6fc4fbbb305544be7b28f65cfb7c24f1b6d558ec07610e99f88","url":"https://skillfed.io/files/product-on-purpose/pm-skills/develop-design-rationale/3ebb7ef0/SKILL.md"}],"id":"product-on-purpose/pm-skills/develop-design-rationale","links":{"html":"https://skillfed.io/product-on-purpose/pm-skills/develop-design-rationale","md":"https://skillfed.io/product-on-purpose/pm-skills/develop-design-rationale.md","repo":"https://github.com/product-on-purpose/pm-skills"},"meta":{"agents_supported":[],"first_seen":"2026-07-28","forks":66,"language":"JavaScript","last_updated":"2026-07-24","license":"Apache-2.0","name":"develop-design-rationale","publisher":"product-on-purpose","stars":505},"relations":{"categories":["product-management","design-documentation","ux-strategy"],"similar":[{"id":"product-on-purpose/pm-skills/develop-adr"},{"id":"product-on-purpose/pm-skills/develop-solution-brief"},{"id":"product-on-purpose/pm-skills/develop-spike-summary"},{"id":"product-on-purpose/pm-skills/iterate-pivot-decision"},{"id":"product-on-purpose/pm-skills/deliver-prd"},{"id":"product-on-purpose/pm-skills/tool-note-and-vote"},{"id":"product-on-purpose/pm-skills/tool-foundation-sprint-magic-lenses"},{"id":"product-on-purpose/pm-skills/deliver-acceptance-criteria"},{"id":"product-on-purpose/pm-skills/define-hypothesis"},{"id":"product-on-purpose/pm-skills/foundation-persona"}]},"slug":{"owner":"product-on-purpose","repo":"pm-skills","skill":"develop-design-rationale"},"version":"3ebb7ef0"}