Dashboard 規劃設計指南

Dashboard 不是把所有圖表放在同一頁，也不是把報表做得更漂亮。好的 dashboard 應該幫助特定角色在特定情境下快速判斷狀態、定位問題，並採取下一步行動。

先定義 Dashboard 的任務

規劃 dashboard 前，先回答三個問題：

1. 使用者打開這個畫面時，最想知道什麼？

2. 使用者看到異常時，能不能知道原因在哪裡？

3. 使用者看完後，下一個動作是什麼？

如果這三題答不出來，通常代表目前想做的是「資料瀏覽器」或「彙整報表」，還不是 dashboard。

常見 dashboard 類型：

從決策反推內容

不要從「有哪些資料」開始，而要從「哪些決策需要被改善」開始。

建議使用這個句型定義 dashboard：

為了讓「角色」在「情境」中判斷「問題」，並採取「行動」，我們需要呈現「指標與線索」。

範例：

為了讓客服主管在每日早會前判斷客服量能是否不足，並調整排班或支援優先順序，我們需要呈現待處理工單、逾時案件、各類問題占比、處理時長與人員負載。

這個句型能避免兩個常見錯誤：一是把所有部門的需求塞進同一頁，二是只呈現數字卻無法支持行動。

設計指標模型

每個 KPI（關鍵績效指標）都應該有清楚定義，否則 dashboard 上的數字很容易引發爭論。

指標可以分成四層：

每個指標至少要定義：

• 指標名稱：避免口語化，例如「有效訂單數」比「訂單」清楚。

• 計算公式：分子、分母、排除條件、時間區間。

• 資料來源：資料表、API、事件、人工匯入來源。

• 更新頻率：即時、每小時、每日、每月。

• 目標值：絕對目標、同期比較、移動平均或門檻。

• 責任人：誰需要對異常做出回應。

建立資訊層級

Dashboard 的閱讀路徑應該像一個由淺入深的診斷流程。

1. 第一層：現在好不好
   用總覽卡、狀態燈、趨勢箭頭、目標達成率回答「是否正常」。

2. 第二層：哪裡有問題
   用分類、區域、渠道、產品、團隊等維度回答「問題集中在哪」。

3. 第三層：為什麼發生
   用趨勢、漏斗、分布、對比、異常事件回答「可能原因是什麼」。

4. 第四層：接下來做什麼
   用待辦清單、告警、建議動作、明細連結回答「要交給誰處理」。

一個實用原則是：3 秒看出狀態，30 秒定位問題，3 分鐘找到下一步行動。

選擇正確的圖表

圖表的選擇應該服務於問題，而不是服務於視覺豐富度。

設計圖表時，標題應該說明觀察重點，而不是只寫欄位名稱。例如「本週逾時工單集中在物流問題」比「工單類型」更有用。

圖表範例一：KPI 摘要卡

KPI 摘要卡適合放在 dashboard 的第一屏，目的是讓使用者不用解讀複雜圖表，就能立刻知道目前狀態是否正常。摘要卡不是越多越好，通常 3 到 6 張已經足夠；如果超過 8 張，使用者會失去焦點。

KPI 卡應該包含：

• 指標名稱：用業務語言命名，不要只放資料欄位名稱。

• 目前值：使用清楚的單位，例如金額、百分比、件數、分鐘。

• 比較基準：和昨日、上週、上月、目標值或同期相比。

• 狀態語意：用顏色、箭頭、標籤表達是否異常。

• 短期趨勢：迷你走勢圖（sparkline）或進度條，幫助判斷是單點波動還是持續趨勢。

• 補充文字：一句話說明需要注意的原因或下一步。

使用 KPI 卡時要避免幾件事。第一，不要只放一個大數字，卻沒有比較基準；沒有基準的數字很難判斷好壞。第二，不要把所有卡片都做成同樣的視覺強度；真正需要注意的卡片應該比正常卡片更容易被看見。第三，不要用紅色表示所有下降，因為有些指標下降反而是好事，例如錯誤率、取消率、成本。

適合 KPI 卡的場景：

圖表範例二：趨勢圖

趨勢圖用來回答「狀況是變好、變壞，還是只是正常波動」。它特別適合觀察時間序列，例如營收、轉換率、錯誤率、準時率、活躍使用者與庫存水位。

一張好用的趨勢圖通常不只是一條線，還應該補上決策所需的上下文：

• 目標線：讓使用者知道目前值是否符合期待。

• 比較線：例如去年同期、上週同期、移動平均。

• 事件註解：標示促銷、系統異常、天候、政策變更等業務事件。

• 異常區間：標示超出控制範圍的時間段。

• 時間粒度：依決策頻率選擇小時、日、週或月。

趨勢圖最常見的錯誤是時間粒度不對。主管月會看的 dashboard 不應該用分鐘級資料；營運監控如果只看月資料，也會太慢才發現問題。設計時要問：使用者多久做一次決策？如果每天做決策，圖表就應以日為主；如果每 15 分鐘需要處理異常，圖表就應支援更細的粒度與告警。

趨勢圖標題也應該帶出洞察。例如「準時率連續 5 天高於 95%」比「準時率趨勢」更能降低解讀成本。

圖表範例三：排行長條圖

排行長條圖用來回答「問題集中在哪裡」。當 dashboard 的目標是分配資源或決定優先順序，排行圖通常比圓餅圖更有效。

適合排行圖的問題：

• 哪些門市逾時工單最多？

• 哪些產品貢獻最高營收？

• 哪些客戶最容易流失？

• 哪些錯誤碼發生最頻繁？

• 哪些物流商延遲率最高？

排行圖設計原則：

• 使用水平長條，讓分類名稱容易閱讀。

• 預設由大到小排序，除非有固定業務順序。

• 標示門檻線，例如「超過 90 件需處理」。

• 只顯示前 5 到前 10 名，其他項目可放在明細表。

• 如果要比較比例，避免只看件數，需同時考慮基數。

排行圖很適合接到下一步行動。使用者點擊某個門市、客戶或產品後，應該能看到明細、負責人、歷史趨勢與建議處理方式。否則它只能指出問題，不能幫助解決問題。

圖表範例四：漏斗圖

漏斗圖用來分析階段式流程，常見於註冊、購買、審核、招募、客服處理與業務銷售。它的價值不在於形狀像漏斗，而在於讓使用者看出每個階段的轉換率與最大流失點。

設計漏斗圖前，必須先定義每一層的分母與條件：

漏斗圖適合搭配切分維度，例如來源渠道、裝置、方案、地區、活動、業務團隊。單一總漏斗只能告訴你整體流失，切分後才可能知道原因。

漏斗圖不適合拿來呈現沒有固定順序的分類占比。如果使用者可以跳過階段、返回階段，或同時處於多個狀態，就應該改用流程圖、桑基圖（Sankey diagram，用線條寬度表示流量大小）或狀態轉移分析。

圖表範例五：熱力圖

熱力圖用來發現「交叉維度中的集中區域」。它通常用顏色深淺表示數值大小，適合呈現時間與分類、地區與產品、錯誤類型與服務、門市與時段等組合。

熱力圖適合回答：

• 哪些時段客服量最高？

• 哪些地區的配送延遲最嚴重？

• 哪些功能在特定版本錯誤最多？

• 哪些門市在週末需求特別高？

• 哪些產品組合帶來最高退貨率？

熱力圖設計要注意色彩。顏色應該有明確順序，並避免只靠紅綠判讀。若數值差異很大，可以使用分位數或對數尺度，否則少數極端值會讓其他格子都看起來差不多。

熱力圖也需要搭配 tooltip 或明細。顏色可以幫助使用者找到異常格子，但點進去後應該能看到精確數值、相關事件與處理建議。

圖表與問題的對照表

規劃 dashboard 時，可以先寫下問題，再選圖表。

圖表不是越多越專業。越成熟的 dashboard，越會把圖表數量控制在必要範圍內，並讓每張圖都有清楚的判讀目的。

版面配置原則

Dashboard 的版面不是平均分配空間，而是依照決策重要性配置視覺重量。

建議配置：

• 頂部：頁面標題、資料時間、全域篩選、主要狀態摘要。

• 第一列：最重要的 3 到 6 個 KPI，顯示目前值、變化、目標差距。

• 中段：支援診斷的趨勢、分群、排行與異常。

• 下段：可操作明細、待處理清單、鑽取入口。

視覺層級原則：

• 重要數字要大，但不要所有數字都大。

• 同一類資訊使用一致的色彩、單位、時間區間。

• 色彩應優先用於狀態與異常，不要只做裝飾。

• 空白是分組工具，不是浪費空間。

• 表格要支援排序、篩選與固定關鍵欄位。

版面線框與資訊密度

Dashboard 的版面可以先用線框規劃，不需要一開始就進入高保真 UI。線框的重點是確認資訊優先順序、區塊關係與閱讀路徑。

常見版型：

資訊密度要根據使用情境調整。主管簡報型 dashboard 可以留較多空白，讓關鍵結論清楚；營運工作台則可以密集一些，因為使用者需要快速掃描大量待處理項目。不要用同一套視覺密度處理所有角色。

互動設計

好的互動不是把所有圖都做成可點擊，而是讓使用者能自然地從總覽走到原因。

常見互動能力：

• 全域篩選：時間、區域、產品、渠道、團隊。

• 局部鑽取：點擊異常項目後查看該分類明細。

• 交叉篩選：點選圖表中的項目後，其他區塊同步更新。

• 告警狀態：標示超標、低於目標、資料延遲、異常波動。

• 註解：讓使用者記錄某天數字變動的業務原因。

• 匯出：只在需要交付、稽核或二次分析時提供。

互動越多，使用成本越高。核心路徑應該不用教學也能理解。

篩選器與時間設計

篩選器是 dashboard 最容易被低估的部分。錯誤的篩選設計會讓使用者看到互相矛盾的數字，也會讓團隊難以對齊同一個事實。

設計篩選器時要先決定哪些是全域條件，哪些是局部條件。時間、區域、產品線通常適合全域篩選；單一圖表的分類、排序、Top N 則適合局部控制。全域篩選改變後，頁面上所有指標都應該清楚同步更新，不能有些圖跟著變，有些圖不變卻沒有說明。

時間篩選尤其重要：

• 預設時間要符合使用情境，例如營運看今日，經營看本月。

• 比較區間要清楚，例如 vs. 昨日、上週同期、去年同期。

• 跨時區系統要明確標示時區。

• 即時資料與批次資料不要混在一起假裝同步。

• 月累計、週累計、移動 7 日平均要清楚標示。

如果 dashboard 會被截圖或匯出，篩選條件必須顯示在畫面上。否則同一張圖在不同條件下可能代表完全不同的意思。

資料可信度與狀態設計

Dashboard 最怕的不是不好看，而是使用者不信任。

必須處理的資料狀態：

• 最新資料時間：明確顯示最後更新時間。

• 載入狀態：避免空白畫面讓人誤判為沒有資料。

• 無資料狀態：說明沒有資料的原因與下一步。

• 錯誤狀態：顯示哪個資料源失敗，避免整頁看起來都正常。

• 延遲狀態：當資料落後時要標示，不要假裝即時。

• 權限狀態：不同角色看到的數字口徑要一致，差異要可解釋。

指標旁邊可以放一個簡短說明或 tooltip，包含公式、更新頻率、資料來源。這比在會議中反覆解釋數字更有效。

資料字典與口徑管理

當 dashboard 被多人使用後，真正的挑戰通常不是畫面，而是指標口徑。不同部門如果對「有效訂單」「活躍客戶」「已完成案件」有不同定義，dashboard 只會把衝突放大。

建議每個 dashboard 都附一份簡短資料字典：

資料字典不需要一開始就寫成龐大的文件，但關鍵 KPI 必須先定義清楚。若指標公式曾經改版，dashboard 上也應該保留註解，避免使用者誤判長期趨勢。

行動設計與營運閉環

Dashboard 光是被看到還不夠，真正的價值在於能不能被拿來處理問題。如果使用者看到異常後還要去其他系統重新查資料、手動整理名單、再找負責人，這個 dashboard 就只完成了一半。

可以把 dashboard 的行動分成四種：

設計時可以問：當這個指標變紅時，誰要在多久內做什麼？如果回答不出來，代表這個指標可能不是管理指標，而只是觀察資料。

規劃工作坊流程

可以用 90 到 120 分鐘完成第一版規劃。

1. 釐清目標
   這個 dashboard 要改善哪個決策？目前決策慢在哪裡？

2. 定義角色
   誰每天看？誰偶爾看？誰只需要收到告警？

3. 列出行動
   使用者看到紅燈、下降、異常後，各自會做什麼？

4. 盤點指標
   保留能支持決策的指標，移除只是「可能會想看」的數字。

5. 畫資訊架構
   先畫區塊與閱讀順序，不急著決定圖表樣式。

6. 驗證資料
   確認來源、口徑、更新頻率、權限與歷史資料完整性。

7. 製作原型
   用低保真線框先驗證流程，再進入 UI 設計與開發。

原型驗證問題清單

在進入開發前，應該用原型和真實使用者跑一次情境驗證。這不需要完整系統，用 Figma、白板、簡報或靜態 HTML 都可以。

驗證時不要問「你喜不喜歡這個畫面」，而要給使用者任務：

• 你能在 10 秒內判斷今天狀況是否正常嗎？

• 如果指標異常，你會先看哪裡？

• 你能指出最需要處理的門市、客戶或產品嗎？

• 你知道這個數字的時間範圍與資料來源嗎？

• 你看完後下一步會做什麼？

• 哪些資訊你覺得不需要？

• 哪些資訊你仍然需要去其他地方查？

原型驗證的重點不是收集所有意見，而是找出會阻礙決策的問題。若使用者需要解釋才懂畫面，通常代表資訊架構或文字標籤還不夠清楚。

常見失敗模式

• 一頁塞太多指標，結果每個指標都不重要。

• 沒有角色分層，主管與執行者看同一套畫面。

• 只有結果指標，沒有能解釋原因的領先指標。

• 顏色沒有語意，紅綠黃只是裝飾。

• KPI 沒有定義，導致每次會議都在吵數字口徑。

• 沒有資料更新時間，使用者不知道數字是否可信。

• 圖表好看但不能操作，看到問題後還是要另外找資料。

• 只做第一版，沒有根據使用情況與決策結果迭代。

反例：資訊很多，但沒有決策價值

上圖是一個常見的錯誤 dashboard：畫面看起來很完整，卡片、圓餅圖、折線圖、表格都有，但使用者看完仍然不知道目前狀態是否正常，也不知道下一步要做什麼。

反例中的問題可以拆成幾類：

判斷 dashboard 是否落入反例，可以問三個問題：

1. 如果把所有顏色拿掉，使用者還能看懂重點嗎？

2. 如果只給使用者 30 秒，他能指出最需要處理的問題嗎？

3. 如果某個指標異常，畫面上是否能看出原因與責任歸屬？

只要其中一題答案是否定，就代表 dashboard 還停留在「資料陳列」，尚未形成「決策工具」。

交付檢查表

上線前可以用這份 checklist 檢查：

• 每個頁面都有明確使用者與決策情境。

• 每個 KPI 都有公式、資料來源、更新頻率與責任人。

• 頁面能在 3 秒內看出主要狀態。

• 異常項目能被定位到維度或明細。

• 資料時間、載入、錯誤、無資料狀態都有設計。

• 色彩有一致語意，並兼顧色弱辨識。

• 篩選條件不會造成指標口徑混亂。

• 手機、平板或大螢幕情境已確認。

• 權限與敏感資料遮罩已處理。

• 使用者能從 dashboard 進入下一步工作流程。

範例：營運監控 Dashboard 架構

目標：讓營運主管在每日早會前掌握訂單履約風險。

建議區塊：

這樣的 dashboard 不只是展示營運資料，而是把「監控、診斷、派工」串成一條決策流程。

範例：SaaS 經營 Dashboard 架構

目標：讓 SaaS 產品團隊每週判斷成長、留存與營收是否健康。

建議區塊：

這類 dashboard 的重點是避免只看新增客戶。若新增成長很好，但啟用率下降、取消率上升、客服量暴增，代表成長可能是不可持續的。

範例：客服品質 Dashboard 架構

目標：讓客服主管掌握服務水位、案件品質與人力配置。

建議區塊：

客服 dashboard 應該同時看效率與品質。只看平均處理時間，可能導致人員快速結案但問題沒有真正解決；只看滿意度，也可能忽略大量未處理案件。

設計原則總結

Dashboard 的成熟度可以用一句話衡量：

它不是讓人知道更多數字，而是讓人更快做出更好的決策。

先定義決策，再定義角色；先定義指標，再定義圖表；先驗證資料可信度，再追求視覺精緻度。只要這個順序正確，dashboard 才會從漂亮的資訊牆變成真正能推動業務的管理工具。