develop-design-rationale

デザイン判断の根拠

デザイン判断の根拠を記録する文書は、デザイン上の決定に至った背景、制約、検討した代替案、そして特定の解決策に至った理由など、「なぜ」を捉えるものです。デザインそのものが何を作ったかを示す一方で、判断の根拠を記録する文書は、なぜその形で作ったのかという組織の知識を残します。

使用する場面

• ユーザー体験に影響する重要なUX上の判断を行うとき
• デザインレビューの前に、ステークホルダーとの議論に備えるとき
• 有効なアプローチが複数あり、選択の根拠が必要なとき
• 新しいチームメンバーに既存のデザイン判断を伝えるとき
• 過去の判断を見直し、当初の理由を把握するとき
• デザインシステムを進化させる際に、パターンを選んだ理由を記録するとき

使用しない場面

• アーキテクチャやテクノロジーの選定に関する判断の場合 → develop-adr（Nygard 形式）を使用します
• ソリューション全体の方向性についてステークホルダーとの合意が必要な場合 → develop-solution-brief を使用します
• 判断ではなく、調査で得た知見を記録する場合 → develop-spike-summary を使用します
• 判断が簡単に覆せ、リスクも低い場合：判断の根拠を文書化すると形式ばった手続きが増えるため、代わりにPRやチケットに理由を記録します

手順

デザイン判断の根拠を文書化するよう依頼された場合は、次の手順に従ってください。

1. 判断を明示する どのようなデザイン判断を行ったのか、明確な1文で要約することから始めます。これが文書のタイトルとなり、参照の起点になります。

2. 背景を説明する この判断を促した状況を説明します。どのような問題を解決しようとしていたのでしょうか。どのような制約があったのでしょうか。どのようなユーザーニーズが方向性に影響したのでしょうか。関連する調査結果も含めます。

3. 検討した選択肢を列挙する 評価した代替案を少なくとも2～3件記録します。それぞれについて、どのようなものか、主な特徴は何かを説明します。すべての選択肢を公平に扱い、藁人形論法は避けてください。

4. 評価基準を定義する ユーザビリティのヒューリスティクス、技術的な実現可能性、ブランドとの整合性、ユーザー調査の結果、ビジネス要件、デザイン原則など、選択肢をどのように評価したかを明記します。

5. 判断の理由を説明する 選んだ選択肢が、なぜ基準を最も満たすのかを説明します。何を得て、何を犠牲にしたのかなど、トレードオフを明確にします。また、判断のうち、覆せるものと覆せないものを示します。

6. 受け入れたトレードオフを記録する すべてのデザイン判断にはトレードオフが伴います。何を諦め、それが許容できる理由を明記します。この誠実な記録は、将来のチームが制約を理解するうえで役立ちます。

7. 今後の検討事項を記録する 後で注意が必要な事項、監視すべき指標、判断を見直すべき条件、関連する判断などを記録します。

出力形式

出力の構成には、references/TEMPLATE.md のテンプレートを使用します。根拠を完全に記録するには、テンプレートのすべてのセクション（Decision Summary、Context、Options Considered、Evaluation、Decision Rationale、Trade-offs Accepted、Reversibility、Follow-up Considerations、Supporting Materials、Decision History）を埋めます。

品質チェックリスト

最終化する前に、次の点を確認してください。

• 判断が1文で明確に述べられている
• 背景から「なぜ今なのか」と制約がわかる
• 複数の代替案が公平に記録されている
• 評価基準が明確である
• 選んだ選択肢が代替案より優れている理由に触れている
• トレードオフが誠実に記録されている
• このデザインを引き継ぐ人が、誰かに尋ねなくても、選んだ選択肢が採用された理由を再構成できる

例

完成例は references/EXAMPLE.md を参照してください。