ダッシュボードを設計してほしいという依頼が来たとき、私は「グラフとKPIカードを並べればいい」と思っていた。
Google Stitch でダッシュボードのUIを作り始めてすぐ、その思い込みが崩れた。グラフを置けば「数字が見える」。でも「数字を読める」かどうかは全く別の問題だった。何を強調して、何を背景に置くか。グラフの種類は何が適切か。KPIはどの順番で並べるか——ダッシュボード設計は「情報の優先順位設計」だと気づいた瞬間から、全ての判断が複雑になった。
結論から言うと、ダッシュボードUIで最も重要なのは「このダッシュボードを見た人が、次に何をすべきかわかること」だ。見た目がきれいなグラフを並べることではなく、「今の状態と、取るべきアクション」がひと目でわかる設計——これがダッシュボードの本質であり、Stitchを使いながらその設計判断を繰り返し試したことで、ようやく見えてきた視点だ。
ダッシュボードUIとは何か——「見る」から「読む」への設計
ダッシュボードUIとは、複数のデータ・指標・グラフを一画面にまとめ、ユーザーが状況を素早く把握できるよう設計されたUIです。SaaSのAdmin画面・ECの売上分析画面・マーケティングのKPI管理画面・IoTのセンサー監視画面など、「データを見る人」が使うあらゆるサービスに存在する。
ダッシュボードの設計で最初に理解すべきは、「見る体験」と「読む体験」は違うということだ。グラフを置けば「数字が見える」。しかし「数字が読める」ためには、情報の優先順位・比較の軸・変化のシグナル——これらが設計されている必要がある。Stitchで複数のダッシュボードUIを生成・比較する中で、この違いが最も鮮明に見えてきた。
Stitch でダッシュボードを設計した手順
最初のプロンプトはシンプルだった。「ECサイトの管理ダッシュボード。売上・訪問者数・コンバージョン率・直近の注文一覧を表示」。
生成されたUIは機能的だった。KPIカードが横に並び、折れ線グラフが中央に大きく表示され、テーブルが下部に配置されていた。しかし何かが足りない。見た瞬間に「今日の状況が良いか悪いか」がわからなかった。数字はある。グラフもある。でも「読めない」。
問題の正体は「比較軸の欠如」だった。数字は単体では意味を持たない。「昨日より上がっているのか下がっているのか」「先週比でどうか」「目標に対してどの位置にいるか」——こういった比較があって初めて、数字が「情報」になる。
修正プロンプトで「各KPIカードに前日比の変化率と、上昇なら緑・下降なら赤のインジケーターを追加。目標達成率もバーで表示」を加えた。2回目の生成で、ダッシュボードが急に「読める」ものになった。
グラフの種類選択——Stitchで気づいたこと
ダッシュボード設計で迷ったのは「どのグラフ種類を使うか」だった。Stitchで複数のグラフ種類を試して気づいたことを整理する。
折れ線グラフ（Line Chart）は「時系列の変化」に最も向いている。「売上が過去30日間でどう推移したか」を見せるには折れ線が最適で、Stitchで生成した際も視覚的に最も「変化のトレンド」が伝わりやすかった。
棒グラフ（Bar Chart）は「複数項目の比較」に向いている。「カテゴリ別の売上比較」「チャネル別のコンバージョン」など、項目間の大小関係を比較するには棒グラフが明確だった。Stitchで生成した棒グラフは横棒・縦棒どちらも試せたが、項目名が長い場合は横棒の方が読みやすいことを視覚で確認できた。
円グラフ・ドーナツグラフは「全体に対する割合」には使えるが、4項目以上になると読みづらくなることをStitchでの比較で確認した。「5カテゴリ以上ある場合は円グラフを避けて棒グラフにする」という判断を、ビジュアル比較で直感的に確認できたのはStitchの強みだった。
情報の優先順位設計——「何を上に置くか」問題
KPIカードの配置が最も重要だった
ダッシュボードの上部に置くKPIカード（数値サマリー）の配置は、「このダッシュボードで最も重要な指標は何か」という問いへの答えだ。
Stitchで複数のKPI配置パターンを生成して気づいたのは、「重要な指標を左上に置く」という単純なルールが驚くほど効く、ということだ。人の視線は左上から右下へ流れる。最も重視してほしい指標（売上総額・アクティブユーザー数など）を左上のカードに配置するだけで、ダッシュボードの「読む優先順位」が自然に形成される。
また、KPIカードの数は5〜7枚程度が視認性のバランスが良いことをStitchでの生成比較で確認した。8枚以上になると、どれを見ればいいか迷いが生まれる。「最重要KPIだけを上部に置き、詳細指標はスクロールで見る」という設計が、認知コストを下げる最善策だった。
アラート・警告の表示設計
ダッシュボードで見落としがちなのが「異常値・警告」の表示設計だ。
通常状態のデータを「見える」ようにするのは比較的簡単だ。しかし「異常が起きているときに即座に気づける」設計は意識しないと作れない。Stitchで「売上が前日比30%以上下落した場合の警告表示」を含むダッシュボードを生成すると、警告バナーの配置・色・テキストの書き方が、ダッシュボード全体の「信頼感」に大きく影響することがわかった。
警告は「赤で目立たせるべき」という思い込みがあったが、Stitchで実際に生成してみると「真っ赤なバナーが常に表示されているダッシュボード」は精神的な圧迫感が強く、ユーザーが警告を「無視する習慣」を作ってしまうリスクがある。「重要度に応じた色の使い分け（赤：緊急・黄：注意・青：情報）」という段階設計の方が、ユーザーが適切に反応できることをビジュアル比較から学んだ。
「誰のためのダッシュボードか」で設計が変わる
ダッシュボード設計で最も重要な問いは「このダッシュボードを誰が見るか」だ。
経営者向けのダッシュボードに必要なのは「サマリーと異常の検知」だ。詳細な数字よりも「今良いのか悪いのか、何か問題があるか」を瞬時に判断できる設計が求められる。Stitchで「経営者向け・情報密度を落としたシンプルなKPIダッシュボード」を生成すると、数字が少なくシンプルなのに「状況が読める」UIになる。
現場担当者向けのダッシュボードには「詳細なデータと操作性」が必要だ。フィルター・期間変更・ドリルダウン（大きな集計から詳細への掘り下げ）といった操作機能が重要になる。Stitchで「現場担当者向け・詳細フィルター付き分析ダッシュボード」を生成すると、操作要素が増えてUIが複雑になるが、それが「使い勝手」として正しい設計だとわかる。
同じデータを見るダッシュボードでも、「誰が見るか」によって情報密度・操作性・強調ポイントが全て変わる。この判断をStitchで素早くビジュアル化して確認できることが、設計の質を上げた。
失敗したこと・気をつけるべきこと
1. データが揃う前に設計を始めてしまった
ダッシュボードを設計する前に「どのデータが表示できるか（実装可能か）」を確認しないまま、Stitchで「理想のダッシュボード」を作ってしまった。後でエンジニアと話すと「このデータはリアルタイムでは取れない」「このグラフの集計には負荷がかかる」という問題が出た。ダッシュボードの設計は「見せたいデータの実現可能性」を最初に確認してから行うべきだった。
2. グラフの種類を「見た目の好み」で選んでいた時期がある
「ドーナツグラフがかっこいい」という理由で、7カテゴリのデータをドーナツグラフで表現していた。Stitchで生成した見た目はきれいだったが、実際に数値を入れると何がどれかわからない状態になった。グラフ種類は「データの性質と比較の目的」から選ぶ必要がある。
3. モバイルでのダッシュボード表示を想定していなかった
ダッシュボードは「デスクトップで大きなモニターで見る」という前提で設計していたが、後から「スマートフォンで確認したい」という要求が出た。グラフの横並び表示がモバイルでは全て縦並びになり、レイアウトが崩れた。ダッシュボードをモバイルで見せる可能性がある場合は、最初からモバイル版も別プロンプトで設計すべきだった。
4. 「更新頻度」の表示を忘れていた
ダッシュボードに表示されているデータが「リアルタイムか」「1時間前か」「昨日のデータか」という情報を表示していなかった。ユーザーから「このデータはいつ時点のものですか」という質問が来た。「最終更新：〇〇 分前」という表示は、データの信頼性をユーザーに伝えるために必須の要素だった。
5. インタラクティブ要素（フィルター・期間変更）を静止画で伝えようとした
Stitchで設計したダッシュボードには「期間変更ドロップダウン」と「カテゴリフィルター」が含まれていたが、これらは静止画では「操作したらどうなるか」が伝わらなかった。フィルターを適用した後の状態を別画面として用意するか、プロトタイプツールでインタラクションを示す必要があった。
よくある質問（FAQ）
Q1. Stitch でダッシュボードを設計するとき、最初のプロンプトは何を書けばいいですか？
「誰のためのダッシュボードか」「何のデータを見るか」「最重要KPIは何か」の3点を含めると精度が上がります。例：「ECサイトの運営担当者向け売上管理ダッシュボード。最重要KPIは今日の売上・注文数・直帰率。前日比の変化率も表示」のように書くと、意図に近いUIが生成されやすいです。
Q2. KPIカードは何枚まで上部に置くのが適切ですか？
5〜7枚が視認性と情報量のバランスが良い範囲です。3枚以下だと情報が少なく感じられ、8枚以上だとどれを見ればいいかわからなくなります。「最重要KPIを上部5〜7枚に絞り、詳細指標はスクロール下部に配置する」という設計が、認知コストを下げながら情報量を保つバランスの良い方法です。
Q3. ダッシュボードのグラフ種類はどう選べばいいですか？
データの「性質」と「比較の目的」で選びます。時系列変化→折れ線グラフ、複数項目の比較→棒グラフ、全体に対する割合（4項目以下）→円/ドーナツグラフ、分布の確認→ヒストグラム、2変数の相関→散布図が基本の選択基準です。「かっこいいから」でグラフを選ぶと、後でデータを入れたときに読めなくなる問題が起きやすいです。
Q4. 経営者向けと現場担当者向けで、ダッシュボードはどう変えるべきですか？
経営者向けは「サマリーと異常の即時把握」を優先。情報密度を下げ、KPIの大きさと変化だけが目に入るシンプルな設計にします。現場担当者向けは「詳細なデータと操作性」を優先。フィルター・期間変更・ドリルダウン機能を持たせ、データを深く掘り下げられる設計にします。同じデータでも見る人によって最適な設計は全く異なります。
Q5. 警告・アラートはどう表示するのが効果的ですか？
重要度に応じた色の段階設計（赤：緊急対応が必要、黄：注意が必要、青：参考情報）を使うことで、ユーザーが適切に反応できます。全ての警告を赤にすると「赤慣れ」が起きて重要な警告が無視されるようになります。また、警告には「何が起きているか」だけでなく「次に何をすればいいか」のアクションも添えると、ダッシュボードが「見るだけ」から「行動に繋がるUI」になります。
Q6. ダッシュボードのデータ更新タイミングはどう表示すればいいですか？
「最終更新：〇分前」または「データ更新時刻：HH:MM」の表示を必ず加えることを推奨します。表示する場所は右上または各グラフのラベル近くが一般的です。リアルタイムデータの場合は「ライブ」バッジを加えると信頼感が増します。データの鮮度をユーザーが判断できない状態は、ダッシュボードへの信頼を損ないます。
Q7. Stitch でダッシュボードを設計する際のよくある失敗は？
最もよくある失敗は「見た目を整えることに集中しすぎて、比較軸が欠如したダッシュボードを作ること」です。数字が大きく見えても「前日比・目標比・平均比」などの比較軸がないと、数字の意味が伝わりません。また「誰が見るかを決めずに設計を始めること」も多い失敗で、対象ユーザーの明確化なしにデザインすると、情報密度・操作性・強調ポイントの全てが中途半端になります。
Q8. モバイルでのダッシュボード表示は、どう対応すべきですか？
最も実用的なのは「モバイルでは最重要KPI3〜4項目のみのサマリービュー」を提供し、詳細はデスクトップで見るという設計です。全てのグラフをモバイルに最適化しようとすると、情報の密度が下がりすぎてダッシュボードとして機能しなくなります。Stitchでモバイル版を別プロンプトで設計し、「モバイルでは何を見せるか」を意識的に絞り込む設計が実用的です。
まとめ
「グラフとKPIカードを並べればいい」と思っていた自分が、Google Stitch でダッシュボードを設計して気づいたのは、このUIが「数字を見る体験」ではなく「数字を読む体験」を作るものだということだった。
比較軸がなければ数字は意味を持たない。優先順位がなければどこを見ればいいかわからない。見る人が違えば、最適な設計も変わる——ダッシュボードは、UIの中で最もデータへの理解と設計の意図が問われるジャンルだ。
- 比較軸（前日比・目標比）を加えることで、数字が「情報」になる
- KPIカードは5〜7枚・左上に最重要指標を置く配置が視認性のベース
- グラフ種類は「データの性質」から選ぶ——見た目の好みで選ばない
- 警告は重要度に応じた色段階設計で「赤慣れ」を防ぐ
- 「誰のためのダッシュボードか」が情報密度・操作性・強調ポイントを全て決める
Stitchでダッシュボードを設計するたびに、「数字を読める状態を作ることの難しさ」を実感する。そしてその難しさを乗り越えた先に、「見た人が次のアクションを取れるダッシュボード」が生まれる。
