mcpField
T
tradeoff-analysis

tradeoff-analysis

github.com/owl-listenerデザイン・UI10872 回インストール20 週間前に更新
リポジトリ

tradeoff-analysis について

tradeoff-analysisは、アクセシビリティ上のトレードオフを評価するデザインスキルです。ユーザーニーズと製品制約について、利点、害、深刻度、可逆性、前例を比較し、影響を受ける人や改善策、見直し日を記録します。

主な機能

  1. 01ユーザー群ごとの利点と害の比較
  2. 02タスク阻害と使いにくさの評価
  3. 03判断の可逆性と前例の検討
  4. 04除外される人と改善計画の記録
  5. 05トレードオフの見直し日の設定

活用シーン

  1. 01相反するアクセシビリティニーズの選択
  2. 02期限や性能とアクセシビリティの両立評価
  3. 03設計判断で除外されるユーザーの記録
  4. 04延期したアクセシビリティ対応の改善計画

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/owl-listener/inclusive-design-skills --skill tradeoff-analysis

インストール後、Claude Code で/tradeoff-analysisを入力して読み込まれたか確認します。

詳細

アクセシビリティのトレードオフ分析

アクセシビリティのトレードオフを厳密に分析しましょう。「すべてに対応することはできない」というのは多くの場合事実であり、トレードオフの判断の質によって、誰が受け入れられ、誰が排除されるかが決まるからです。

トレードオフが発生する場面

ユーザーのニーズの衝突
  • 自動再生の字幕は聴覚障害のあるユーザーに役立ちますが、動くテキストは ADHD のあるユーザーの注意をそらします
  • わかりやすい言葉は認知アクセシビリティに役立ちますが、一部のユーザーには見下されているように感じられることがあります
  • 高コントラストはロービジョンのユーザーに役立ちますが、片頭痛の症状によっては目の疲れを引き起こすことがあります
アクセシビリティとその他の要件
  • パフォーマンス:充実したアクセシビリティ機能とページ読み込み速度
  • 納期:完全なアクセシビリティと期限内のリリース
  • 複雑さ:アクセシブルなカスタムコンポーネントと、よりシンプルだがアクセシビリティの低いネイティブ要素
  • コスト:包括的なテストと予算の制約
部分的な実装
  • 機能の 80% は今すぐアクセシブルにし、残りの 20% は後から対応できます
  • どの 80% を選び、誰を残りの 20% から排除しますか?

分析フレームワーク

トレードオフごとに、次の項目を検討します。

1. オプション A の恩恵を受けるのは誰か?
  • アクセシビリティが向上するユーザーグループ
  • 影響を受けるユーザー数(推定)
  • オプション A を選ばない場合、障壁の深刻度はどの程度か
2. オプション B の恩恵を受けるのは誰か?
  • 代替案について同じ分析を行います
3. 各オプションによって不利益を受けるのは誰か?
  • アクセシビリティが損なわれたり、体験が低下したりするユーザーグループ
  • 不利益の深刻度
  • 不利益は恒久的か、一時的か(後から修正されるか)
4. 深刻度の非対称性はどの程度か?
  • タスクを完了できないユーザー(阻害)は、タスクが難しくなるユーザー(摩擦)よりも深刻な影響を受けます
  • 摩擦の軽減よりも、阻害要因の解消を優先します
  • 状況による一時的な制約よりも永続的な障害を優先します(一時的な制約のあるユーザーには別の選択肢がありますが、永続的な障害のあるユーザーにはない場合があります)
5. 決定の可逆性はどうか?
  • 大きなコストをかけずに、後からこの決定を変更できますか?
  • 変更できる場合:より迅速な選択肢を選び、改善を計画します
  • 変更できない場合:よりインクルーシブな選択肢を選び、遅延を受け入れます
6. 前例として何が残るか?
  • この決定は、今後の機能にパターンを作りますか?
  • 一度取られた近道は、文書化されなければ標準になります
  • 悪い前例となる場合、長期的なコストは短期的な節約を上回ります

トレードオフの文書化

すべてのトレードオフは、意思決定の文書化形式に次の追加項目を含めて記録する必要があります。

この決定によって排除されるユーザー: 影響を受ける具体的なユーザーグループを記載します。

排除の深刻度: 阻害(タスクを完了できない)か摩擦(難しくなるが可能)かを記載します。

改善計画: 排除されたユーザーに、いつ、どのように対応するかを記載します。 「チャートコンポーネントのスクリーンリーダー対応はスプリント 14 まで延期します。回避策:チャートの下にあるデータテーブルで同じ情報を提供します。JIRA-4521 で追跡しています。」

レビュー日: このトレードオフを再評価する日を記載します。

譲れない原則

次のようなトレードオフは決して行ってはいけません。

  • キーボードではまったく操作できない機能をリリースしない
  • 納期に間に合わせるために既存のアクセシビリティを損なわない
  • タスクの完了を阻害するアクセシビリティの修正を後回しにしない
  • 追跡可能なチケットと期限を設定せずに、「後で修正する」を許容しない

評価のための質問

  1. トレードオフの双方について、誰が恩恵を受け、誰が不利益を受けるかを分析しましたか?
  2. 深刻度の非対称性(阻害と摩擦)を考慮しましたか?
  3. 排除されるユーザーのための改善計画を文書化しましたか?
  4. レビュー日を設定しましたか?
  5. 管理が必要な前例となる決定ですか?

コメント