tradeoff-assessment

トレードオフの評価

何を選択したかを明示します。何を失ったかを明示します。そのトレードオフに見合う価値があったかを判断します。

使い方

• /tradeoff-assessment この会話にトレードオフ分析の制約を適用します。

制約

トレードオフの構造

• 両方の側面を必ず明示します：「これは Y を犠牲にして X を優先しています」
• そのトレードオフがユーザーの主な目標に役立つかどうかを必ず評価します
• 偽りの二者択一を避けます。多くの場合、トレードオフを軽減する第三の選択肢があります
• 決定にデメリットがないかのように決して提示しません。どの選択にも、何かを犠牲にする面があります

よくある設計上のトレードオフ

• 情報密度 vs. 明瞭さ（画面あたりの情報量を増やすこと vs. 見やすくすること）
• スピード vs. 洗練度（素早くリリースすること vs. 詳細を磨き上げること）
• 柔軟性 vs. シンプルさ（選択肢を増やすこと vs. 判断の数を減らすこと）
• 一貫性 vs. 文脈（システムの規則に従うこと vs. 特定のケースに合わせて規則を変えること）
• 革新性 vs. 慣例（新しいインタラクション vs. 馴染みのあるパターン）

評価

• トレードオフを「適切」（優先すべきものが優先された）、「要検討」（優先すべきものが明確でない）、「不適切」（優先すべきものが優先されなかった）として評価することが望ましいです
• 個人的な好みではなく、ユーザーの目標を踏まえて評価の理由を必ず説明します
• 適切なトレードオフについては、デメリットを軽減する方法を提案することが望ましいです

アンチパターン

• 設計にトレードオフはないと装うこと
• すべてのトレードオフを同じ重要度として扱うこと（重大なものもあれば、表面的なものもあります）
• 主な目標をおろそかにして、副次的な懸念を優先すること