|前言
本文主要分享筆者以往10年在多省、多運營商做大屏、Dashboard,以及早年在某大型房地産互聯公司做數據分析的經驗總結,核心是交付Dashboard過程中沉澱出的“一屏、一眼、馬上幹”方法。
之所以重點聊數據産品中的可視化Dashboard,主要原因是這塊最接近前端受衆(領導)、最容易見效果;其次,這塊内容通用性更強,大多産品都有需求;最後,筆者的核心領域不是數據産品,更多是在交付項目時附帶做數據呈現,數據可視化相對熟些。但同時,為了保證主題完整性,也會聊下“為什麼做數據可視化”、“什麼是數據可視化Dashboard”、“如何做一款數據可視化産品”以及“過往經驗中踩過的一些坑”。
數據可視化是很多B端産品的基礎組件,無論是偏業務的CRM、ERP等,抑或偏工具的協同、雲管等。為什麼要做數據可視化?想清這個問題很重要。
管理大師彼得·德魯克說過,“沒有度量就沒有管理”。引申來看,數據是為了認清現狀,調整行為,達到改善目的。所以,做數據最核心的目的是指導行動,即“馬上幹”,不能對行動産生影響的數據無意義。
信息傳遞領域有句真理,“字不如表,表不如圖”。人類右腦處理圖像速度比左腦抽象處理文字速度快100萬倍,可視化的傳遞可以讓受衆更快理解、更深記憶信息。這樣,幫受衆(領導)快速抓住問題節省時間,或者讓受衆(領導)對自身業務成績産生深刻印象。所以,做數據可視化最核心的目的是高效傳遞信息,即“一屏一眼”,不能讓受衆快速抓住數據觀點的可視化不合格。
在中學數理解題時,可以通過畫圖呈現信息以更快的理解題意、找出解題思路。所以,做數據可視化有助于發現數據間聯系,産生頓悟式的見解,即“洞察”(P.S.筆者過往無此經曆,但有産品宣稱數據可視化有這個功效)。
簡單來說Dashboard是數據圖表的組合,但這個定義有點單薄。筆者通過“數據在業務中的位置”、“數據可視化在數據中的位置”,以及“Dashboard在數據可視化中的位置”層層剖析,以此來理解Dashboard。
數據在業務中的位置,我們從戴明PDCA循環的角度來理解,業務的成功離不開計劃、執行、檢查和調整。數據是“檢查”中最有效的工具,然而,如果隻做好數據,缺乏行動調整和執行沒用。所以,投入過多的精力在數據上意義不大,它僅僅是現狀的反饋。改善業務,不能隻把眼睛盯在數據上!就像開車,最重要的是目的地和調整方案盤,而不是隻盯儀表盤。
p.s.見過不少領導隻是月度會議看數據,不關心團隊的行動項,團隊“偶爾”會聚焦美化數據,而不是解決問題。
一個完整的數據過程至少包括:數據采集、數據存儲、數據分析、數據呈現和數據運營五大環節,而數據可視化歸屬在數據呈現環節中。整個過程好像要做一桌子菜,數據采集是買菜備料,數據存儲是洗菜歸置,數據分析是準備菜譜,數據呈現是烹饪擺盤,數據運營是推薦反饋。
數據采集是數據的源頭,常見的數據采集方法包括在線埋點(如JS埋點、SDK埋點等)、業務數據庫、應用服務器日志、線下材料收集,甚至設備、物聯網端等;
數據存儲是根據需要處理數據并存放的過程,常見的技術包括ETL、數據倉庫,甚至大數據、數據中台等;
數據分析是确定數據觀察角度、指标體系、數據觀點等,常見的行為包括确定北極星指标(唯一關鍵指标)、拆解北極星(模型 MECE)、明确指标口徑、算法輔助、數據挖掘等;
數據呈現是通過圖形來展示數據,常見的方式如監控大屏、Dashboard、數據報告、工作台圖表、信息圖等;
數據運營是連接數據和消費者、連接數據和業務目标,常見的行為包括數據專題推送、數據改進任務跟進、任務改進效果分析等。
Dashboard僅僅是數據呈現中的一種方式,此處,筆者将Dashboard定義為“在一個頁面上,組織一系列可交互的數據可視化圖表,以傳達某個觀點”。我們通過“Dashboard與大屏的區别”、“Dashboard與信息圖的區别”以及“Dashboard與工作台、門戶的區别”來理解Dashboard。
1)Dashboard與大屏的區别
Dashboard和可視化大屏雖然都是将數據以可視化圖表的形式呈現出來,但由于用戶、場景、目标等不同,在設計的過程中區别很大。以下将列舉一些區别點,讓大家有些體感。
比較項 |
大屏 |
Dashboard |
對象 |
群體,領導層、公衆、全體員工 |
個體,領導個體、個體員工 |
目标 |
沖擊感,讓用戶産生深刻印象 |
條理性,讓用戶理解數據觀點 |
場景 |
監控、專題、領導等 |
業務KPI、用戶分析、營銷增長等 |
方式 |
物理大屏 |
電腦、手機 |
頻率 |
低 |
高 |
地點 |
固定 |
不固定 |
共享 |
所有人共享 |
按角色甚至個人定制 |
布局 |
複雜,考慮尺寸、效果、拼縫等 |
簡單,相對标準化 |
風格 |
炫酷 |
簡潔 |
色彩 |
深色系背景圖,色彩多,漸變多 |
淺色系純色背景,色彩少,無漸變 |
圖表 |
定制化強,象形圖多,需設計師參與 |
标準化強,使用線餅柱等常規圖表 |
3D圖表 |
較多 |
較少 |
操作交互 |
無或較少 |
較多,需要篩選、切換、下鑽等 |
動态效果 |
動态效果多 |
基本靜态圖 |
數據更新 |
定時自動更新、清緩存 |
手動刷新更新 |
設計重點 |
效果優先,指标輔助 |
指标優先,圖表輔助 |
硬件要求 |
高性能、獨立顯卡的高配電腦 |
普通配置的電腦、手機即可 |
變更成本 |
高 |
低 |
2)Dashboard與信息圖的區别
信息圖通常由媒體使用,圍繞某個報告主題,使用象形化、非标準化的藝術化定制圖像組合,以讓報告更生動、有趣,以期一次接觸就讓受衆印象深刻。Dashboard相對更平民化,通常使用常見的圖表傳達數據觀點,使用頻率較高,追求實用。
P.S.對于經常看的Dashboard,美不是核心,好用才是王道。
3)Dashboard與工作台、門戶的區别
門戶、工作台和Dashboard相互之間有功能重疊的部分,在有些組織中可能隻會有一個存在。但筆者認為三者之間的功能定位有所不同,以下主要從信息傳遞方式、目标和功能上加以分析。
比較項 |
門戶 |
工作台 |
Dashboard |
溝通方式 |
拉式 |
推式 |
交互式 |
目标用戶 |
公衆 |
角色 |
角色、個體 |
核心目的 |
信息中心 |
完成工作 |
理解現狀 |
核心功能 |
單點登陸、統一消息、新聞公告、菜單管理、Banner輪播等 |
待辦處理、工作日程、常用應用、工作進度、個人KPI圖表等 |
篩選排序、下鑽、聯動、下載、轉換圖表、自定義布局、自定義圖表等 |
做好數據可視化Dashboard這個話題我們從“設計步驟”和“設計思想”兩個角度來理解。
設計Dashboard需要經曆需求調研、指标設計、指标确認、原型設計和原型确認五個階段,按筆者習慣,各階段耗費的時間比例大緻為4:2:1:2:1。也即是說,設計可視化效果僅占整個工作的20%左右,最多的時間耗費在需求調研和指标設計階段。
需求調研階段,最重要的事是熟悉業務流程、目的、關鍵角色等,之後确定Dashboard的核心消費用戶(最好是高層領導),最後明确核心用戶最關注的業務、數據,以及以往獲取數據的渠道、關鍵指标、展現方式等。
指标設計階段,要确定北極星指标并結構化拆解,這是最難的一個環節,尤其組織中缺乏北極星指标共識時。需要根據業務現狀、目标,協同業務方共同敲定。比如在研發效能管理中,可以是需求端到端時長、研發端到端時長、交付及時率等,不同組織、不同階段可以不同,隻需要通過唯一的一個指标驅動改進即可。在拆解時需要通過結構化的方法,如以“交付及時率”做為北極星,可以通過“過去-現在-将來”拆解,過去3個月交付不及時原因、趨勢,現在什麼人、什麼事不及時交付,未來2個叠代什麼事有交付風險等。有些業務單一指标難以設定,可以通過4個以内(盡量少)的組合關鍵指标以指标體系的方式設計。指标設計不僅需要考慮指标本身,還要考慮指标設定後對組織、對人行為的影響等。這個話題太大、太難,此處不再展開。
原型設計階段,要提前考慮開發團隊或産品能支持的圖表組件。若是沒可視化産品,多是使用Echars、Highchars、AntV等開源可視化圖表組件;若有專門的可視化産品,要看産品支持的圖表組件庫。一個易用的數據可視化産品,原型設計時長會再次大大降低。但産品并不是做Dashboard中最重要的事,它僅僅是幫助提高效率、增加美觀度而已。
指标确認和原型确認階段,要頻繁和業務方确認,這不是一個特定的時間節點,而應該是整個過程中持續反饋的事。
Dashboard設計有很多原則、技巧,筆者以“一屏一眼馬上幹”為主線簡單串講。
1)一屏
“一屏”是指Dashboard的圖表要在一屏内展示,不需要用戶滾動頁面即可看完。但在實際業務中,有很多要展示的數據,不可能在一屏内展示怎麼辦?
首先,我們要有一個共識,“用戶不關心的數據,展示給他隻會礙眼”。另外,如果一屏的數據圖表過多,很容易造成用戶認知超載,無法清晰的把握觀點,久而久之可能就不會再看這些數據圖表了。數據要有用戶消費才有價值,這是做數據很核心的一點!
用戶關心的數據,很大程度取決于他在做的事,即他扮演的角色。所以,簡化數據圖表的第一個原則是“分角色”。但有時候一個角色負責不止一個業務(尤其是領導),或一個業務有多個不同的觀察方向,此時,若多個方向無相關性可以“分主題”,若有相關性則根據相關性設計一個MECE的核心指标體系。如果同一個角色、同一個業務方向關心的數據指标确實很多,此時應該根據指标間關系“分級别”,首屏上隻展示一級指标,更細節的内容讓用戶通過下鑽的方式查看。
但有些用戶就是喜歡在一個頁面上看所有數據,我們也不能強制要求用戶每次都切換主題、點擊下鑽。此時,産品可以允許用戶自定義Dashboard,将所有圖表分角色、分主題等集成在圖表庫中,由用戶根據自己需求添加在自定義Dashboard中。
2)一眼
“一眼”是讓用戶一目了然,隻要看一眼就能快速搞清一屏的數據主題,以及一個圖表的數據觀點。做到“一眼”的前提是在“指标設計階段”已經有明确的數據主題(北極星指标)和數據觀點(數據分析結論),數據可視化隻是高效傳遞信息的手段而已。
讓用戶快速搞清一屏數據主題,要做好内容邏輯和形式邏輯。在内容邏輯上要“明确北極星指标”,以北極星指标為主線,其他圖表圍繞北極星指标設計模型結構化拆解;在形式邏輯上要做好整屏“視覺動線設計”,先明确用戶第一個視覺關注點圖表,然後通過上下、左右、或中心向兩側等順序依次浏覽圖表。
讓用戶快速搞清一個圖表的數據觀點,要選擇合适的圖表類型、設計圖表版式。認知的基礎是分類、對比和聯系,大多圖表都逃不開三者,比如折線圖多是時間上的趨勢對比,餅圖多是分類後的對比,散點圖是時間或分類後的分布對比或聯系。
在圖表類型上,其實已明确的數據觀點就大緻框定了可選的圖表類型,具體選擇圖表類型時更多是看組件庫中是否有,或者自己的開發團隊是否有能力實現自定義圖表(我司具備這個能力,美滋滋~)。但不建議過分自定義或選擇生僻的圖表類型,因為我們的目的是讓用戶快速看懂圖表,利用用戶既有認知很重要。
在圖表版式設計上,可以借鑒平面設計4大原則:親密、對齊、對比、重複(本文不贅述,想了解請自行百度)。具體使用如:做好數據系列邏輯排序,讓有邏輯關系的數據系列更靠近;通過簡化背景、網絡、漸變、顔色等幹擾因素,并強化突出核心數據系列,以此形成對比,凸顯觀點;所有圖表采用相同色系,紅橙黃表示警示或異常,綠藍灰表示正常,通過重複降低用戶認知負載。總體來講,通過圖形、色彩、大小、位置等手段,達成讓用戶一目了然的目的。
3)馬上幹
“馬上幹”是讓用戶看過圖表後,立刻就能在行動上有所調整,所以“馬上幹”更多還是一個數據指标設計的話題。
數據通常有3方面價值,追溯過去做根因分析、展示現狀做異常監控、預判未來做決策輔助。我們選擇的數據指标,應該至少具備其中一種價值。同時,指标應該盡可能貼近具體要做的事情。比如,我們要改善端到端交付時長這個北極星指标,可以拆解出一個過去3個月研發各環節時長指标,這樣用戶看到這個指标就能直接知道過去哪個環節出了問題;拆解出一個交付各環節需求數量指标,并做分環節預警提示,這樣用戶看到異常就能下鑽直接知道具體哪個需求快超時或已超時了,甚至可以直接操作處理。總結來講,設計一個指标要提前預判用戶可以采取的行動措施,如果指标不能直接與用戶的行動産生關系,則應該更換或挖掘指标。當然,在設計指标時不可空想,需要多次跟業務方溝通确認。
數據可視化産品根據用戶、場景、需求等不同,有不同的側重方向,比如酷炫大屏、業務人員自助BI、網站統計、無埋點用戶畫像、大數據用戶行為分析、數據中台等。在選擇或設計(抄襲)數據可視化産品時,需要先明确自己的用戶、場景和業務需求,在功能上有取有舍。比如,如果數據可視化非業務的核心方向,則選購一個輕量級、集成性好的産品更佳(适合OEM);如果企業的數據量大、需求大,有專門的數據開發、運營崗位,則選購一個重量級、功能強的産品更合适。筆者不太建議小團隊自行研發數據可視化産品,因為投入做這個事的人力成本要遠高于選購第三方産品,同時産品使用體驗卻差很多。
滿足用戶易理解、開發實施易用、集成能力強的Dashboard産品并不多,本文先簡單聊下數據可視化Dashboard産品的基礎功能,再分别從終端消費用戶角度和開發設計用戶角度聊聊産品可能需要的一些功能。
以開發一個Dashboard的步驟來梳理基礎功能,通常的步驟包括:數據源接入、數據集選擇、數據加工與分析、圖表組件選擇、展示數據選擇、圖表配置、Dashboard配置、圖表/Dashboard發布及通用功能等。下文簡要介紹産品功能模塊,并借助“用Excel做圖表”類比解釋。
數據源管理:可通過本地文件或在線API、數據庫連接等方式獲取數據,如上傳Excel、連接各類數據庫等。該模塊類似于,把數據原始文件拷貝到電腦上等能力。
數據集管理:通過數據導入、SQL、存儲過程調用、JSON數據集等手段,生成一個特定業務的行列二維關系型表格,并采用分組、命名等方式作為可複用的公共業務數據。該模塊類似于,創建Excel文件寫入數據,并通過文件夾進行管理等能力。
數據加工與分析:通過ETL、内置函數、内置算法等手段加工數據,用于統一數據格式、計算出想要的數據結果等。該模塊類似于,Excel中通過删除、替換、格式化、公式等方式處理數據等能力。
圖表組件庫:提供餅圖、柱狀圖、折線圖、雷達圖等多種類型的可選圖表。該模塊類似于,Excel中所有圖表、插入圖表等能力。
圖表配置:配置圖表所需的數據、美化圖表并配置交互功能,如修改前背景色、漸變、警戒線、标題、圖例,以及配置數據下鑽、聯動、篩選、提示、鍊接等。該模塊類似于,Excel中設置圖表區格式、填充、邊框等能力。
Dashboard配置:通過拖拉将多個圖表組合在一個頁面上,并設置位置、大小、标題、背景圖、圖表容器框、容器Tab頁、輪播、公共篩選條件、APP端适應調整等。該模塊類似于,Excel中插入多個圖表并拖拽布局等能力。
圖表/Dashboard發布:設定訪問權限、鍊接、頁面嵌入代碼、郵件推送、下載導出,以及管理已發布的圖表、Dashboard等。該模塊類似于,Excel中另存為PDF、加密等能力。
對終端用戶而言,需求出發點是“在需要的時候,方便、快速獲取,對自己有用、易于理解的數據”,可以考慮規劃的功能如:
數據推送:從“人找數據”到“數據找人”,具體功能包括,支持周期性數據報告推送;支持設置數據告警,在數據異常時報告自動推動;支持運營人員定向推薦數據報告。
圖表管理:在數據報告較多後,尋找特定的報告或圖表會變得低效,可以通過圖表層級歸類、自定義收藏、自定義标簽、自定義Dashboard、關鍵字查詢等,便于用戶查找與管理報告或圖表。
線下使用:貼近用戶線下使用場景,如支持自定義數據報告,數據報告可導出PDF、PPT,圖表可下載為透明底色圖片,可在線組合打印等。
頁面嵌入:圖表可嵌入其他頁面并接受傳參,如迷你圖嵌入表格中,審批工單詳情頁中嵌入圖表并有數據聯動等。
設計統一:通過重複降低用戶認知成本,如提供統一Dashboard布局樣式,統一色系及顔色意義,常用數據指标推薦特定圖表等。
對開發設計者而言,需求出發點是“用省事的方式,配置出高性能、漂亮的圖表”,可以考慮的功能如:
輕量數據倉庫:有時候圖表源數據獲取不便,如,數據庫有訪問權限隻能通過API取數,隻能獲取實時數據缺失曆史數據,取數邏輯複雜,有髒數據或數據格式需要處理等,此時,一個輕量級的數據倉庫不僅可以提高開發者獲取數據便利度,也會改善性能。
數據集複用:業務中很多報表、圖表會有一些公用的、需要多表關聯查詢的中間數據,這些數據可以定義為公共數據集,在使用時讓開發者通過單表即可查找相關數據集、相關圖表,以便于快速定位到可複用的數據集和可參考的數據呈現方式。
圖表配置:圖表有很多配置屬性,為提升配置修改效率,需要“所見即所得”,支持可視化 代碼兩種配置屬性調整方式;自帶持久化數據,允許直接在表格中調整數據,預覽圖表變化,以便在花時間提取數據前先讓客戶确認數據指标和效果;産品内置 自定義模闆圖表色系,根據數據、圖表類型自動統一着色,減少顔色配置工作量;支持自定義導入指定格式圖片、圖表,以豐富自定義圖表庫,同時支持在線圖表商店以發布圖表任務、發布或下載圖表。
Dashboard配置:産品内置 自定義模闆布局結構,讓開發者隻需從圖表倉庫中将要展現的圖表直接拖放到布局容器(類似背景框,可配置是否顯示、顯示樣式等)中即可;在自由布局中,全局默認容器内外邊距、寬高、對齊等,無需開發者手工拖放調整;自動多端适配,配置PC布局可自動轉換默認的手機端布局,也可通過PC“所見即所得”的自定義調整手機端布局。
首先,作為一個産品經理,筆者肯定要推薦自己做的産品。但公司雖有可視化産品模塊,一未包裝成獨立産品,二更偏向于大屏,三不在筆者控制範圍。未來或有改觀,敬請期待!
關于選購數據可視化産品,筆者選購思路主要分四步,需求調研、評分表制作、産品體驗評分和商務談判。其中,最重要的是需求調研,需要明确當前核心痛點、業務期望、消費用戶、消費頻率、開發用戶、開發用戶技能水平等。根據需求調研的結果,有針對性的制作評分表、分配評分權值。筆者曾用的選購評分表設計了50餘個評分指标,主要評分模塊包括:集成能力、開放性、UI呈現、功能特性、數據能力、性能、易用性、複用能力、售前響應、售後服務、商務模式、産品價格等。
複盤數據可視化工作中,曾踩過一些坑,希望大家可以避免。
多年前給運營商交付項目大屏時,過于追求炫酷和高度滿足客戶需求,造成開發成果可複用性低。給不同的客戶交付時幾乎都要重新設計、開發,抑或拿舊包來改,但冗餘代碼會造成性能優化困難。啟示:及時抽象和産品化可以降低成本,提高交付效率。
從大屏轉向做Dashboard後,依然按照做大屏的思路來做。追求Dashboard背景、圖表形式、色彩、整體美觀度等,耗費精力很大,但用戶需求變化快,調整不便且成本高。啟示:Dashboard更注重數據本身和靈活性,過度追求視覺效果是喧賓奪主、華而不實。
為了增加首頁美觀度,放了一些全業務的數據統計圖表。但在用戶實際工作中,根據不關注這些和個人無關的圖表,隻是拖慢了首頁加載速度;同時,由于占據黃金空間,造成用戶使用時需要滾動鼠标,或者增加一次點擊才能完成。啟示:用戶不關心的數據,硬塞隻會降低用戶體驗。
為響應客戶“流程提效”、“精益數據運營”、“精細化數據分析”号召,從流程效率、異常告警、業務狀态、業務監控4個維度對具體業務實體建立了全面的指标體系,涉及數據指标多達上百種。然而,在實際使用中,這些預定義的指标大多不常消費,反而造成常用數據報表尋找困難。同時,實際工作中的數據需求這些預定義指标又無法完全滿足,需要二次開發。啟示:數據指标應該盡量簡潔,隻做最常用的核心指标即可。當有數據細化分析的需求時,再根據需求開發數據即可。新開發的數據若不常用,不應進入數據指标體系,作為下鑽或臨時數據使用即可。
【往期推薦】
深入看透低代碼
深入B端SaaS産品設計核心理念
用“系統思考”看破産品開發團隊與項目實施團隊的相愛相殺
看破皇帝的新裝:OKR不一樣的視角
B端大客戶項目交付中棘手的8個需求問題
作者:李曉傑;産品曉說(ID:pmxiaosi)。10年以上産品、項目管理實戰經驗,近7年服務大B端客戶運營商(移動、聯通),核心産品為企業信息化與協同,包括低代碼平台、DevOps研發協同、項目及财務管理、OA協同、企業門戶、數據可視化等。喜歡讀書、分享,希望與同路人共同探索産品經理成長之路。
,更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!