Communitygithub.com

voytas75/operational-dashboard-design

運用ダッシュボードを設計する際に使用します。

operational-dashboard-design とは?

このスキルは、運用ダッシュボードやKPIビュー、コンパクトな分析グラフィックをデータファーストで設計し、既存のダッシュボードを整理・改善するための手順を提供します。主要な流れは「概要 → 注意 → 詳細 → 行動」であり、プライマリビューから説明文を排除しつつ、データ解釈や操作に必要な情報は隠さないことを重視します。手順はデータ契約の確立、階層とアクションの定義、視覚エンコーディングの選択、簡潔な表現とアクセシビリティの適用、成果物の構築と検証の5段階で構成されます。具体的なライブラリやサービスに依存せず、利用可能なツールでデータを検査し、成果物を構築・テストします。最終的には、実装されたアーティファクト、主要な判断とアクション経路の説明、合格・不合格・未検証のチェックを分けたQAレポート、残された前提条件や次のステップを出力します。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/voytas75/skills/tree/HEAD/skills/operational-dashboard-design

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

運用ダッシュボード設計

概要 → 注意 → 詳細 → 行動 の流れでデータファーストのダッシュボードを構築します。プライマリビューには説明文を表示せず、データの解釈やコントロールの操作に必要な情報を隠さないようにします。

使用するタイミング

  • 運用ダッシュボード、KPIビュー、コンパクトな分析グラフィックを設計またはレビューする場合。
  • ユーザーが例外を特定し、影響を受けたデータから定義されたアクションを実行できるようにする場合。
  • 散らかったダッシュボードを、一貫性がありスキャンしやすいビジュアルシステムにリファクタリングする場合。

ナラティブレポート、教育用グラフィック、オンボーディング、または明示的な説明が必要なインターフェースのための普遍的なルールとしては使用しないでください。静的なグラフィックはツールチップに依存したり、インタラクティブなアクションを提供するふりをすることはできません。

入力と前提条件

データセットまたは正確なスキーマ、対象ユーザー、運用上の判断、納品形式(モックアップ、画像、HTML、動作するダッシュボード)、対象デバイスを入手します。メトリクスの単位、時間枠、ベースライン、しきい値、望ましい方向性、許可されたアクションを特定します。

特定のライブラリ、サービス、エージェントクライアントは必要ありません。利用可能なツールを使用してデータを検査し、要求されたアーティファクトを構築し、テストします。不足している意思決定に重要な情報のみを質問し、暫定的な前提にはラベルを付けます。測定値、しきい値、アクション、または成功したQA結果を決して発明してはいけません。

手順

1. データ契約を確立する

  • 合計、集計、分母、単位、時間枠、ベースラインの比較可能性を実際の計算で確認します。
  • ゼロ、欠損、古い、利用不可、該当なしの値を区別します。欠損データを黙ってゼロに変換しないでください。
  • 各メトリクスについて、値が高いか低いかが問題となるかを定義します。支出などのニュートラルなメトリクスについては、承認された予算または範囲を使用します。ない場合は、ニュートラルなスタイルを使用し、問題があることを暗示しないでください。
  • 統計的不確実性とデータの鮮度は、それらが決定に影響を与える場合に表示したままにします。

完了条件: 表示されるすべてのメトリクスに定義された解釈と既知のデータ制限があること。

2. 階層とアクションを定義する

  • 全体の状態から始め、次にデータに直接フラグ付けされた例外、次に詳細へと進みます。
  • 注意の優先順位は、重要度と意思決定の関連性から設定し、恣意的な視覚装飾から設定しないでください。
  • アクションは影響を受けるデータの上または横に配置します。たとえば、アクション可能なヒートマップセルは、関連する詳細またはワークフローを開きます。
  • 意味のあるアクセス可能な名前、可視フォーカス、明確なインタラクティブアフォーダンスを使用します。是正措置を発明したり、ビューの設計の一部として実行したりしないでください。

完了条件: 各フラグに定義された理由と、実際のアクション、または明示的に非インタラクティブな詳細の宛先があること。

3. 視覚エンコーディングを選択する

共通のスケール上の位置、次に長さ、次に角度/面積、次に色を、タスクに適している場合に優先します。これは設計上のヒューリスティックであり、1つのエンコーディングがすべてのデータセットに適合するという保証ではありません。

デフォルトの視覚語彙:

  • クラス化ヒートマップ: 離散的でラベル付けされたしきい値を使用した例外スキャン用。
  • 弾丸グラフ: 値、比較可能な目標、および意味のある範囲をゲージの代わりに使用します。比較に必要な場合はスケールを揃えます。
  • セグメント化シェアバー: 円グラフの代わりに、定義された全体の一部(2つのカテゴリのシェアを含む)を表示します。分母を表示し、重複するカテゴリに全体があることを暗示しないでください。
  • スパークライン: エンドポイント、スケール、または範囲情報を十分に含んだコンパクトな時系列コンテキストを提供し、誤解を招く比較を避けます。
  • 一貫した詳細サーフェス: 同等のフォーカス/タップアクセス可能なポップオーバーまたは詳細パネルを備えたツールチップ。

この語彙で要求されたタスクを正直に表現できない場合は、その不一致を説明し、データを強制的に当てはめるのではなく、適切な代替案を提案します。

完了条件: すべてのコンポーネントが比較または決定をサポートし、そのスケールが解釈可能であること。

4. 簡潔な表現とアクセシブルな顕著性を適用する

  • プライマリデータビューでは、簡潔なメトリクス名、値、単位、期間ラベル、ベースラインラベル、必要なコントロール/ステータスラベルを使用します。ナラティブな洞察や説明段落は使用しません。
  • ▼ 15% vs Sep のようなコンパクトな比較では、何が比較されているか、その変化が好ましいかどうかを特定する必要があります。矢印だけで深刻度をエンコードしてはいけません。
  • 補足説明は詳細に配置しますが、重要な意味をホバーオンリーにしないでください。キーボードとタッチアクセス、アクセス可能な名前、必要に応じて同等のテキスト/データ表現を提供します。
  • 順序のある大きさにはシーケンシャルスケール、意味のある中間点の周りには発散スケール、定義されたしきい値にはクラス化スケールを使用します。
  • 確立された問題に向けて視覚的な強度を高めます。低い値が悪い場合は深刻度マッピングを逆にし、両極端が悪い場合は両側しきい値を使用します。
  • 色と、形状、アイコン、パターン、境界線、明示的な短いステータスラベルなどの色以外の手がかりをペアにします。
  • 通常のテキストでは少なくとも4.5:1、大きなテキストと意味のあるグラフィカル/コントロールの境界では3:1のコントラストを目指します。実際の前景/背景の組み合わせとインタラクション状態をテストします。検証されていないアクセントカラー上のアクセントテキストは避けます。
  • 装飾、冗長なグリッド線、不要な背景を削除します。データの解釈に必要な場合は、凡例、ラベル、ガイドを保持します。

完了条件: ビューが、色、ホバー、またはプライマリデータサーフェス上の説明文がなくても理解できること。

5. 要求されたアーティファクトを構築して検証する

設計の説明だけでなく、要求された形式で納品します。動作するダッシュボードの場合は、そのインタラクションとデータ状態を実行します。画像またはモックアップの場合は、機能しないコントロールを明確に特定します。

以下の検証チェックリストを実行します。確認された欠陥は修正し、未実行のチェックは 未検証 とラベル付けします。仕様を実装されたダッシュボードと呼んだり、構造レビューをユーザビリティテストと呼んだりしないでください。

完了条件: エビデンスに基づくQAと明示的な制限事項とともにアーティファクトが納品されること。

検証

  • データ: 計算された合計とシェアが適合する。単位、時間枠、分母、ベースラインが一致する。欠損/古い/ニュートラルな状態がテストされている。
  • 顕著性: レンダリングされたビューを検査し、意図した例外が目立つかどうかを確認する。視覚レビューと測定されたユーザー注意テストを区別する。
  • 色: ツールが許可する場合は実際の色覚シミュレーションを検査する。色以外の手がかりが深刻度を伝えていることを独立して確認する。シミュレーションだけではアクセシビリティを確立できない。
  • コントラスト: レンダリングされた色のペアと関連する状態を測定する。方法と不合格を報告し、パレット名から準拠を主張しない。
  • 言語: プライマリサーフェスに説明文がないか検査する。必要なコントロール、ステータス、安全に関する表現は保持する。
  • インタラクション: キーボードナビゲーション、可視フォーカス、フォーカス/タップ詳細、非表示、意図したアクションルートを、承認されていない外部アクションを実行せずに実行する。
  • レイアウト: 対象ビューポート、クリッピング、オーバーフロー、長いラベル、代表的な空/単一/複数アイテムの状態をチェックする。
  • 整合性: 凡例とスケールが十分である。レイアウトルールが競合しない。出力がデータを発明したり、サポートされていないアクションを暗示したりしない。

出力契約

以下を返却します:

  1. 要求されたアーティファクト、またはその検証済みの場所。
  2. 主要な決定とアクション経路の簡単な説明。
  3. 合格、不合格、未検証のチェックを分け、方法またはエビデンスを添えたコンパクトなQAレポート。
  4. 残りの前提条件またはブロッカー、および未完了の場合の具体的な次のステップ1つ。

「説明文禁止」ルールはダッシュボードのプライマリデータサーフェスに適用され、この納品レポート、アクセシビリティテキスト、または重要なエラー/安全メッセージには適用されません。

落とし穴

  • 必要なコンテキストを削除するミニマリズムは、効率ではなく曖昧さです。
  • 赤い値は必ずしも問題ではありません。深刻度にはメトリクス固有のルールが必要です。
  • ツールチップは、必須の可視情報またはフォーカスアクセス可能な情報へのアクセス可能な代替手段ではありません。
  • スパースなグラフィックでも、互換性のないスケール、切り詰められた範囲、欠落した分母によって誤解を招く可能性があります。
  • コントラストチェックだけからWCAG準拠を主張しないでください。
  • アイトラッキング、色覚シミュレーション、またはテストされたインタラクションを、実際に実行せずに主張しないでください。

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

関連スキル