mcpField
D
decision-ui

decision-ui

github.com/chirpyworksデザイン・UI0127 回インストール4 週間前に更新
リポジトリ

decision-ui について

decision-ui は、利用者が下す判断を起点にインターフェースを設計するスキルです。チャートやダッシュボードのテンプレートから始めず、情報の階層、根拠、行動、状態、アクセシビリティ、レスポンシブ設計を検討します。

主な機能

  1. 01判断とその背景を定義
  2. 02根拠を階層的に整理
  3. 03分析上の問いに応じてチャートを選択
  4. 04発見事項を次の行動につなぐ
  5. 05画面状態とアクセシビリティに配慮
  6. 06小さな画面向けに構成を再編

活用シーン

  1. 01判断を軸にした運用画面の設計
  2. 02ダッシュボードの階層や行動経路の監査
  3. 03特定の比較に適した可視化の選定
  4. 04レスポンシブ対応と例外状態の確認

インストール

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

$npx skills add https://github.com/chirpyworks/decision-ui --skill decision-ui

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

house-style.md
references/
accessibility.md
anti-patterns.md
chart-selection.md
decision-flow.md

詳細

意思決定 UI

意思決定に必要な労力を減らすインターフェースを構築します。

コンポーネントから始めないでください。チャートから始めないでください。ダッシュボードのテンプレートから始めないでください。

意思決定から始めてください。

1. 意思決定の要件を定める

UI を提案する前に、次の項目を特定します。

  • 利用者 — このビューを使うのは誰ですか?
  • 意思決定 — どの選択、優先順位付け、診断、介入が必要ですか?
  • 時間軸 — 分、時間、日、週、四半期のどれですか?
  • 結果 — 対応が遅れたり、誤ったりした場合、何が危険にさらされますか?
  • 根拠 — どの観察結果が意思決定を変える可能性がありますか?
  • アクション — このビューから、またはこのビューを見た後に、利用者は実際に何ができますか?

次の一文を書きます。

ユーザーがこのビューを開くのは、[意思決定] を [期限/結果] より前に決める必要があるためです。

これを明確に述べられない場合は、不足しているビジネス上の背景を尋ねるか、前提を明示してください。

2. 情報の階層を構築する

次の順序を優先します。

  1. 注目事項 — 今すぐ対応が必要なのは何ですか?
  2. 比較 — 何と比較していますか?
  3. 原因 — なぜ起きているのですか?
  4. 影響 — 何が影響を受ける、または危険にさらされていますか?
  5. アクション — 何ができますか?
  6. 検証 — アクションの後に何が起きましたか?

6 つすべてを 1 ページに無理に詰め込まないでください。これらは推論の順序として扱ってください。

複数ステップからなる業務運用向けまたは診断向けのプロダクトでは、情報設計を確定する前に references/decision-flow.md を読み込んでください。

「原因」は診断上の問いであり、因果関係を断定してよいという意味ではありません。観察された関連性、診断上の根拠、暫定的な仮説、検証済みの原因を区別してください。

最も視覚的に大きく見せるのは、最大の数値ではなく、意思決定価値が最も高い問いです。

3. 指標を根拠として扱う

KPI だからといって重要とは限りません。

指標ごとに、次の点を確認してください。

  • この指標によって、どの意思決定が変わりますか?
  • 比較の基準は何ですか?
  • 解釈を変えるしきい値や範囲はありますか?
  • データの鮮度は把握できていますか?
  • 不確実性は重要ですか?
  • この数値には説明、アクション、あるいはどちらも不要ですか?

現在の意思決定に影響しない指標は削除してください。

4. 問いに応じて可視化を選ぶ

references/chart-selection.md を読み込んでください。

ダッシュボードに「変化を持たせる必要がある」という理由で、チャートを選んではいけません。

チャートは、意図した比較を直感的に理解しやすくする必要があります。角度や面積よりも、位置や長さを優先してください。正確な値を調べるにはテーブルを使ってください。色は装飾ではなく、意味を伝えるために使ってください。

分析上の問いが明確でない場合は、チャートの種類に変化を持たせようとしないでください。

5. 装飾より先に構成を決める

次の要素を使って階層を確立します。

  • 位置
  • スケール
  • 余白
  • 整列
  • 密度
  • コントラスト
  • グループ化
  • タイポグラフィ

境界線、カード、影、グラデーション、コンテナは、構造や状態を明確にする場合にのみ使ってください。

基盤となる意思決定の重要度が実際に同等でない限り、同じ重みのタイルは避けてください。

12 個のモジュールがすべて同じ強さで目立つページには、階層がありません。

6. インサイトをアクションにつなげる

UI が問題を特定した場合、次のアクションへ進む道筋を示してください。

適切な例:

  • 原因を調査する
  • 影響を受けたコホートを比較する
  • 影響を受けた注文/アカウント/資産を開く
  • しきい値を変更する
  • 担当者を割り当てる
  • 承認/却下する
  • 確認する
  • トレードオフをシミュレーションする
  • 回復を検証する

不適切な例:

  • 異常を表示する
  • 赤色にする
  • ナビゲーションをたどって探す作業をユーザーに任せる

7. 理想的なスクリーンショットだけでなく、状態を設計する

関連する状態を網羅します。

  • 読み込み中
  • 空
  • 古いデータ
  • 部分的
  • 遅延
  • 切断
  • エラー
  • 権限制限
  • アクション不要
  • 確認済み
  • 解決済み
  • 上書き

業務運用データでは、データの鮮度と信頼性もインターフェースの一部です。

8. アクセシビリティを維持する

インターフェースを実装または監査する際は、references/accessibility.md を読み込んでください。

重要度、ステータス、比較、アクションを、色だけ、ホバーだけ、またはポインティングデバイスだけに依存させないでください。表形式の関係が重要な場合は、セマンティックなテーブルを維持してください。意思決定に重要なチャートの意味を、テキストで確認できる要約として用意してください。フォーカス順序、ズームとリフロー、動きを減らす設定への配慮を徹底してください。

アクセシビリティのために、専門家向けインターフェースを不自然に情報の少ないものにする必要はありません。階層とアクションを、認識でき、操作できる状態に保つ必要があります。

9. レスポンシブな再構成

デスクトップのグリッドを縮小しないでください。

小さな画面では、次の点を守ってください。

  1. 主要な意思決定を維持する
  2. 最も重要な比較を維持する
  3. 二次的な根拠を折りたたむ
  4. 情報量の多いテーブルを専用のビューに移す
  5. 重要なアクションにアクセスできるようにする
  6. 単にサイズを変更するのではなく、再構成する

10. アンチパターンの確認を行う

references/anti-patterns.md を読み込んでください。

最低限、次の項目は不採用としてください。

  • KPI カードを壁のように並べる
  • 装飾目的で多様なチャートを使う
  • 冗長なサマリー階層
  • 意味のあるしきい値ロジックを持たないゲージ
  • 説明のない赤/緑の意味づけ
  • 目に見えるアクション経路のないダッシュボード
  • 「ダッシュボードにはフィルターがあるから」という理由だけで設けられたフィルター
  • 重要度の異なるビジネス上の影響を同じ強調度で示すこと

11. 意思決定を優先した引き継ぎ資料を作成する

BUILD または REFRAME の場合は、次の項目を返してください。

  1. 意思決定の要件
  2. 主要な階層
  3. 画面構成
  4. 可視化の選択とその理由
  5. 操作/診断ナビゲーション
  6. 状態と例外
  7. レスポンシブ動作
  8. 意図的に削除したもの

AUDIT の場合は、構造への影響度順に問題を並べてください。

  • P0:誤った意思決定モデル/重要なアクションまたは根拠の欠如
  • P1:階層、比較、または可視化によって解釈が妨げられている
  • P2:操作、状態、またはレスポンシブ対応の弱さ
  • P3:仕上げと視覚的な調整

P0/P1 の問題が残っている間は、角の丸みのレビューに時間を費やさないでください。

ハウスルール

house-style.md が存在する場合は、このファイルの後に読み込んでください。

ハウスルールによって、ビジュアル言語、情報密度、コンポーネントシステム、実装方針を変更できます。ただし、意思決定の明確さ、誠実な可視化、アクセシビリティ、状態の整合性を損なってはなりません。

コメント