本篇文章中，作者整理了數據可視化產品需求的必備要素，以及經常會被忽略和遺漏的點，從數據產品需求文檔的常規結構開始講起，到易漏細節自查清單，讓你的數據產品需求文檔更加無可挑剔，成為別人眼中靠譜的產品經理。

最近做的項目主要是負責數據可視化分析模塊的產品，找了外包團隊進行開發變現。

如果是公司內自己的研發，需求不完善，臨時變需求最多會被開發吐槽或者打一頓，刷個臉陪個笑，喝個咖啡吃個飯，最終還是會幫忙解決問題。但是外包生意就是生意，沒有那么多人情，需求范圍簽合同時基本確定。

為了減少溝通成本和避免后期扯皮，所以在需求方面，做了充分的澄清。順帶整理分享下數據可視化產品需求的必備要素，以及經常會被忽略和遺漏的點，讓你的數據產品需求文檔更加無可挑剔，成為別人眼中靠譜的產品經理。

一、數據產品需求文檔的常規結構

一般來說，對于一個數據產品需求來說，PRD文檔主要會包含以下幾個部分：

1.需求背景及目標

這個部分的作用一方面可以讓開發團隊更加清楚的知道自己做這個需求的業務背景和價值是什么，否則就只是被動地執行完成需求，對于為什么做卻一知半解。知道了這個事情是公司重點戰略，做好了會被老板關注，可能開發自己就愿意花心思把事情做好，否則就是做完產品交代的工作，其他榮辱與我無關。此外，PRD的作用之一還是資產沉淀，健全準確的背景目標描述，后期工作交接也會非常方便。

2.用戶及權限

C端產品面向的是普羅大眾，B端尤其是數據產品，一個報表可能是服務的特定用戶群體，所以做數據產品時，需要厘清核心用戶和覆蓋用戶分別是誰。

而用戶權限方面，主要是不同用戶對頁面、數據指標以及維度（區域、品類等）的具體權限清單，從而保證數據安全。

3.數據需求說明

常見數據需求模板可參考如下：

數據需求是數據可視化產品的核心模塊，準確描述數據統計邏輯可以節省很多開發溝通成本。為什么說數據產品最好要具備SQL能力，主要是因為可以做一些基礎的數據探查工作，這樣做產品設計的時候才能數據是怎樣的，否則辛辛苦苦設計出來的產品，最后沒數據或者數據做不了，就白費時間

4.產品功能說明

上圖是一個最常規的可視化報表的功能頁面，產品需求描述時，需要針對各個模塊做詳細的說明，比如篩選器的默認值設定，聯動邏輯，指標展示內容，圖表類型及圖表信息設置等等。

二、易漏細節自查清單

1.無數據提示頁

數據產品不同的維度組合往往會存在無數據的情況，比如某些區域就是這一天沒數據，如果直接展示一個空白頁面，用戶會分不清到底是沒數據還是系統問題。

2.無權限提示及引導流程

有數據權限限制，當用戶訪問頁面無權限時，需要友好地進行提示，并且加以引導，直接提供申請權限入口或者申請方法（比如給XX發郵件）

3.性能要求

數據產品對海量大數據的ETL處理同步到前端頁面查詢時，一般要求圖表的加載和響應時長不能過長，比如3S，太長時間用戶焦躁。如果不提前寫清楚性能要求，技術實現上可能是完全不同的數據存儲和查詢方案。上線之前性能老板不滿意，再去改方案就非常麻煩。

4.數據異常提醒

數據ETL到最終展示需要經過很長的數據鏈路，經常因為集群、服務、數據開發問題導致數據異常，如果因為任務延遲導致數據缺失，給業務帶來錯誤的決策，后果非常嚴重。所以需要有一些異常的提醒和容錯機制，比如展示數據前先判斷任務狀態以及數據質量監控的結果，發現問題時，展示數據異常提醒頁面。

5.數據格式說明

不同數據指標展示上需要明確對應格式，比如是整數，單位用什么，是否需要千位分隔符展示，小數保留幾位小數，有些指標需要百分比展示等。

6.tooltips細節

鼠標懸浮在不同圖表、不同位置時，展示什么指標或者維度信息，數據的格式如何等等

7.篩選器層級聯動

對于層級維度，如區域、省份、城市等，需要前后級聯的要求

8.默認值及排序

篩選器的默認值，如默認展示昨日或者最近7天的數據，表格數據排序按數據大小降序，按照數據日期降序等。曾經見過一個表格，新增數據每次排到最后一頁，用戶添加了數據保存后沒反應，還以為沒加上，又加了一次。最后發現，表格排序是把最新更新的加到了最后一行。

9.異常數值處理，枚舉值數量過多

有些維度比如城市、細分三級品類等，一般來說數據量非常大，餅圖、折線圖、柱狀圖等如果超過了5個以上，圖表基本上沒法看，所以需要定義好展示多少個，其他的數據是直接舍棄還是說歸到其他一類當中。

10.文字對齊方式，比如指標右對齊

一般來說，維度的文字左對齊，數據指標右對齊，這樣可以更加方便的看出數據的差異。