7 min read

為何你不應該做Dashboard,只需要做投影片就好

用一次即丟的儀表板,稱為Trashboard,是維運災難的開始
Trashboard一詞的來源,可見規劃不當的Dashboard,造成的危害,古今中外皆然

在數位轉型的浪潮下,Dashboard儀表板一直不斷被吹捧,間接導致無論專案大小,數據團隊很容易動不動就會被業務單位要求要配合做儀表板

但實際上,並不是所有的資訊呈現都需要用到儀表板,殺雞焉用牛刀。相反地,一昧地做儀表板,反而會埋下日後的維運隱患,不可不慎。

與其說Dashboard是會自動更新的投影片,他更像是一個軟體產品,會需要用軟體產品的思維來做規劃

這是因為 :

1.Dashboard的背後,存在著Tables與Pipelines在支撐

若儀表板被重複運用的機會不高,像是為了一次性的行銷campaign就製作追蹤用的專屬儀表板,但不同活動間卻無法共用,就很難合理化當初開發、日後維運與持續運算更新的成本

一次性的需求,案子跟案子之間缺乏明確的關聯,導致可重複運用的部分不多,諸如活動Campaign、實驗結果、提案說服的專案,大多屬於這一類,做投影片比起做Dashboard更為合適

2.Dashboard比起投影片,更仰賴用戶知道如何操作,與能夠說出數字背後故事的能力

這是因為在投影片裡,圖表與文字都可以被預先設計、策劃,並且固定好,用戶的注意力可以被聚焦控制在我們希望他們關注(而不是其他不重要)的事物上,但Dashboard則不然。

一條曲線,可以解讀至少一種以上的訊息。若你不在現場導讀協助,你確定觀眾知道你想傳達的意思? (參考來源: Gene Zelazny - Say It with Charts)

以上述的圖表為例,至少可以解讀出以下幾種訊息 :

  1. 3月是2022上半年客戶數的低谷
  2. 客戶數一直處於浮動(Fluctuated)的狀態,而非穩定
  3. 客戶數在8月達到高峰
  4. 客戶數在1月到8月期間,歷經兩波的衰退
  5. 客戶數呈現正成長

若這是一份要對CEO報告的圖表,他們是一群時常穿梭在各處救火的人,如何確定他們能在有限的時間裡,自行透過Dashboard的操作,完整得到上述的觀察?

假設在某個情境裡,其實最需要留意的是「客戶數在1月到8月期間,歷經兩波的衰退」這一項,假如沒有任何視覺上的提示,而又沒有人在旁邊做導讀,要如何確定不會重點放錯地方? (像是誤把「客戶數呈現正成長」當作整張圖最重要的結論)

因此,對於需對故事與詮釋有更大控制的情境,投影片比起Dashboard更為合適。

3. 若在Dashboard加註了僅適用特定情境的文字標示,反而有違應能重複運用的初衷,還不如做投影片更為合適

隨著資料更新後,當初用來標示兩次衰退低谷的圓點,顯得格外突兀與不明所以

通常越是非數據背景的需求方,像是業務、企劃,或是影響層面廣的策略、決策與管理層,像是長字輩、總監等,就越需要將點狀的數據發現,轉變成脈絡清楚,能見樹又能見林的故事性論述

若把Dashboard當作投影片,放上一堆只適用於特定時空情境的文字描述,結果就會像是圖片所示,反而違背了當初做Dashboard能自動化與重複運用的初衷,而且還要花費人力再去調整,還不如做投影片。

4. 對於重複性的需求,區分三種不同的使用情境,對應不同類型的Dashboard

我想這是為何投影片是文件,而Dashboard應被視為是「軟體產品」的最大原因。

最可怕的狀況莫過於 : 同一個數字,可以透過多個以上的儀表板獲得,但不同儀表板的數字卻因為背後的算法、觀點的差異,而長得不一樣。

經驗上,這往往是因為未預先對Dashboard做定位上的區分,迭代時就會很容易因需求方的要求,不斷地增加額外新功能,導致儀表板目的不明確,變得非常臃腫,難以使用跟維護。

三種不同的Dashboard運用情境:分析探索 / 運營監控 / 報告總結 (來源)

而這三種情境分別為:

Analytical 分析探索

  • 特色是允許使用者從各種角度去切資料,以利發現潛在的趨勢與成長機會
  • 因此使用者通常是全職在做數據,熟悉資料特性的人員,像是分析師、幕僚
  • 會有較為複雜的圖表,像是 Dot chart、Bubble chart、Heatmaps
  • 比起其他儀表板,並不需要預先設定好命題
  • 因為不是嚴肅的監測用途,故對於背後資料的品質,要求比較寬鬆

Operational 運營監測

  • 最大的特徵是:必須要預先定義好命題,即要監測什麼? 通常會是KPI
  • 這類儀表板不外乎回答 : (1) 現在離目標多遠? (2) 若有落差,那原因是什麼?
  • 因為使用者重點在運營,而不是全職在用數據,因此只會用簡單的圖表,像是 Line chart、Bar chart、Pie chart
  • 因為攸關KPI達成與否,對資料品質的要求嚴格

Presentational 報告總結

  • 跟Operational類似,也是回答目前的狀態離目標多遠,但差別是溝通層級更高
  • 這是因為CXO level的人take care的是策略/資源配置等宏觀的議題,日常運營的流程細節就太微觀了,因此只要總結現狀,然後知道要盯哪個部門就好
  • 一樣必需要先定義好命題,並且用簡單的圖表做呈現(畢竟CEO的時間是破碎的)
  • 一樣對資料品質的要求嚴格,畢竟績效誤差一點是會死人的
  • 但更多的會是類似Kanban的大字報,顯示目前的數字、達成率是多少

結語

本文總結一些過往自己執業的心得,還有踩過的誤區,避免「手上有錘子,什麼都是釘子」,有時做投影片就好,沒有必要做儀表板。

就算是要做儀表板,也要視為軟體專案做規劃,定義好Target Audience跟Use case scenario,有意識的納入功能,避免資源的浪費跟重工。