產品經理和 UI 設計在對接數據可視化大屏的需求時，以下是常見對話：

盡管有的產品經理非常細致，輸出的 demo 詳細到包含圖表類型和交互說明。不過整體來看，開發(fā)步驟是一致的：

大家有沒有疑惑？為什么明確了業(yè)務場景，就能確定關鍵指標？這兩個步驟是如何推導和銜接起來的？

指標就像是冰山在水面之上可視的部分，但水面下隱蔽但關鍵的支撐部分是什么，這里依舊是模糊朦朧的形態(tài)。

探索冰山水面以下的部分，就是今天討論的主題。

用數據講故事

我的疑惑終于在一次查詢資料的時候被解開。這里感謝王亮亮同學分享的經驗《政務可視化設計經驗-故事線》（原文地址見文末），給我很大啟發(fā)。

這篇經驗針對政務類可視化大屏經驗，根據場景提煉出多條故事線。故事線作為一條隱形的線，在當前場景下把各個指標串起來。雖然在大屏主題上和政務類有些偏差（我們是網絡信息安全行業(yè)），但大屏設計的底層邏輯和分析方法是通用的。

其實“故事”這個概念，在數據可視化領域中，并不是一個陌生的名詞，一本有關可視化設計的書，書名就是《用數據講故事》[美] Cole Nussbaumer Knaflic。

沒有人不愛聽故事，好的故事讓受眾感同身受，獲得啟發(fā)和動力。故事的價值同樣可以發(fā)揮在大屏設計上，讓受眾理解數據，感受數據的美和力量。作為大屏的設計者，我們同樣可以利用故事，來組織大屏的內容（指標）。

既然要講故事，我們首先要明確給誰講故事，才能確定怎么講故事。

給誰講故事？

你的受眾越具體，你就越能成功地進行溝通。避免“內部和外部的利益相關者”或“任何感興趣的人”這樣泛化的受眾——一次性嘗試與太多需求不同的人溝通，遠沒有與細分的一部分受眾溝通高效。
你對受眾了解得越多，就越能準確理解如何與之產生共鳴，如何在溝通中滿足雙方的需求?！队脭祿v故事》第一章 1.3.1 你的受眾

在數據可視化大屏需求開發(fā)的場景中，我們首先要明確大屏的展示或匯報對象，才能確定展示內容的類型。

B 端產品面向對象有「用戶」、「客戶」兩個概念。此外還有其他維度的分類方式——按照組織內部架構，可以分領導層、管理層、執(zhí)行層等上下級關系，以及平行部門等；按照建設和總包關系，可以將對象分成甲、乙、丙方等。在分析每個具體的用戶時，要考慮到他存在于整個在坐標體系的哪個位置，這個位置包含了多個坐標軸的信息。

不同坐標點的用戶，核心利益點有共性也有差異化。我們強調關注用戶 or 客戶，其實就是關心其核心利益點。

怎么講故事

1. 兩個萬用模板

我提煉了兩個萬用模板，作為故事腳本的底層框架：

注意這是兩種故事腳本的底層框架，不決定頁面的布局是橫向或豎向。

2. 場景概念展示

因為我們的業(yè)務都是網絡信息安全領域，所以展示的概念也是基于此領域的延伸。

串形故事線

場景：修復對重要資產具有嚴重威脅的漏洞，響應安全事件，排查情報并防護命中資產等。

場景：對日常安全運營工作計劃的執(zhí)行情況進行度量和改進，提升管理成熟度。

場景：在網絡安全領域的不少名詞，本身有類似于「生命周期」的概念，在“初始”和“終結”之間，存在多個“階段”。以下是國標對漏洞管理流程的定義。

樹形故事線

場景：將數據進行多維度的分析，為領導層做出決策提供可靠的數據支撐。

場景：向上級單位或建設單位（甲方）匯報工作成果。

場景：通過對監(jiān)控數據的聚合分析，呈現并預測攻擊態(tài)勢。

嵌套和穿梭

不論是串行還是樹狀，是框架高度抽象后的極簡形態(tài)。在實際情況中更常見的是，一個大屏內兩種形態(tài)互相嵌套，或者多個大屏組合在一起，講述一個更詳細的故事，但這都不影響框架主體結構。

ONE MORE THING

大家發(fā)現沒，雖然這只是大屏需求開發(fā)過程中的一小步，但分析方法也容納了一整個雙鉆模型——第一個鉆石用來探索+聚焦問題，第二個鉆石用來發(fā)散+明確解決方案，遵循發(fā)散-收斂-再發(fā)散-再收斂的規(guī)律。

雙鉆模型是一個通用框架，保證在考慮周全的前提下，探索并輸出最佳方案，避免單線程思考可能陷入一葉障目的陷阱而不自知。

END

我們嘗試總結方法論，以此高效地解決同類問題，但方法論并不天然具備萬能屬性，我們需要帶著循證思維在更多場景中反復驗證它、修正它。

今天的分享旨在拋磚引玉，歡迎大家一起討論。

參考：

• 政務可視化設計經驗-故事線（點擊查看原文）
• 《用數據講故事》[美]ColeNussbaumerKnaflic

歡迎關注作者的微信公眾號：「能呆書房一整天」