編輯導語：作為産品經理，除了關注最外顯的設計規範，同時也要思考産品底層邏輯是否存在不一緻的問題。那麼這就需要一套規則來進行規範。本文将圍繞數據産品設計規範來展開，分别從産品規劃、産品形态、産品設計、産品規範這四個方面來規範産品設計的邏輯一緻性。值得閱讀學習。

我經常讀到一些關于設計規範的文章。每次閱讀完都有種醍醐灌頂的感覺。同時我也會去反思自己負責的産品，是否也存在設計、交互不一緻的問題。作為産品經理，除了關注最外顯的設計規範（大到頁面布局，小到icon顔色），我也在思考産品底層邏輯是否也存在不一緻的問題。于是腦袋裡湧現出一個想法——除了最外顯的視覺和交互設計外，可能産品設計邏輯也需要一些“規範”。

應該有不少同學在訪問一個系統/APP的不同頁面或者不同功能模塊時，可能都會産生“這個孩子有幾個爸媽”的疑問？這種感覺一方面可能是來源于外顯的設計不一緻導緻的，另一方面可能是産品設計邏輯不一緻導緻的。

互聯網是個高速發展的行業，互聯網産品也有快速疊代的特征，在一輪又一輪的疊代中，産品、開發、設計等不同職能的同學都有可能換了好幾代。開發更替對用戶使用産品的影響是相對最小的，用戶并不能明顯感知到變化，隻是要辛苦開發同學苦苦啃别人的代碼（恨不得分分鐘重寫），設計和産品更替對用戶影響更為明顯，如果改動不是很大，用戶可能會理解為又疊代了，如果改動很大，用戶可能就會理解為人員變動。換人是常态，但換人的背後還是需要一些規範和規則來維護産品在用戶心中的品牌标識。小到一個icon的交互，大到整個系統/APP的框架邏輯都需要圍繞産品定位及目标進行設計。

本人目前在做的是數據産品，本次分享更多的會圍繞數據産品設計規範來展開。産品設計的邏輯一緻性可以從四個方面來規範，分别是【産品規劃】、【産品形态】、【産品設計】、【産品規範】。

一、面向企業外部的數據産品

在分享之前，再簡單介紹下數據産品及其分類。數據産品以數據為基礎，通過技術處理、産品策略挖掘數據價值，從而輔助用戶/企業更優的做決策的一種産品形式。數據産品根據分類維度不同，可以分成若幹類型。這裡主要分享的是具備SaaS服務能力的數據産品，也叫做面向企業外部的數據産品。這類數據産品由企業或個人開發，主要提供給外部企業使用，具備數據采集，計算，存儲，展示和分析等功能。

SaaS數據産品有兩大類型，一種是工具型，通過提供組件和報表服務，幫助業務提高數據分析效率，既包括SPSS、minitab之類的數據統計工具，也包括tableau、powerbi之類的數據可視化工具。另一種是平台型，具備數據采集、處理與分析能力，結合業務痛點提供可視化産品和解決方案。

目前本人負責的是偏業務的數據産品，即數據的價值最終需要用于指導具體業務的開展，促進業務實現增長。業務導向的數據産品，從産品規劃到産品設計各個環節都需要圍繞解決業務痛點開展，從而最大化實現數據的價值。

二、産品規劃：設計的先導

産品規劃是産品經理工作的重要組成部分，也是産品設計的先導，那麼該如何做好産品規劃呢？産品規劃交底書應該盡可能大而全，就像産品的北極星目标一樣，這份規劃能夠指引産品在不同階段的發展。

在開始構建一個産品前，建議先規劃好這個産品至少近2年的最終全貌，讓整個團隊充分了解到産品布局；如果産品已經在構建中了，建議定期review規劃，根據行業背景和業務需求等因素，判斷是否需要變更。想清楚一個較長遠的産品規劃後，還需要把這個規劃進行拆解，按時間維度拆解到一年的、半年的、一個月的；或是按目标實現維度拆解成A模塊、B模塊。

制定任一産品規劃都需要基于充分的市場研究、行業分析以及用戶/客戶需求分析。在做好市場、行業、用戶的基礎功課後，剩下的便是需要結合戰略的、組織的、産品的等不同層級的目标來設計産品的定位、目标以及具體的打法。假設戰略、組織等因素在一定周期内相對穩定，我們來具體看下如何來制定産品規劃。

産品規劃核心是要找到産品的賣點，也就是産品的核心競争力。确保産品賣點是符合市場和行業的趨勢的前提下，盡量去挖掘用戶、客戶的需求，将瑣碎的需求按照特定維度進行歸納和分類，同時深度挖掘需求的本質和産品定位，找到二者的契合點。

如何理解“需求本質和産品定位兩者的完美結合”呢。數據産品需要極緻挖掘數據的價值，将數據轉化為可視化産品。挖掘數據的價值需要專研數據本身，基于使用場景去拆解數據信息，按照不同維度把數據進行歸納。

假設現在有一條視頻數據，這條視頻數據就包含了标題、圖文、賬号、播放量、評論等數據，這麼多數據就可以根據場景來進行分類。如果場景是分析爆款，則可以從标題、圖文、評論等數據着手，如果場景是分析up主，則可以從賬号數據着手。産品定位就很好理解了，原則上來說數據的價值應該是服務産品定位的。産品經理的工作就是需要基于對數據的理解，努力實現需求和産品定位兩者的匹配。

三、産品形态：多樣的服務

有了産品規劃之後，下一步就可以去構想産品形态了。當然産品形态也需要結合用戶、客戶的使用場景。數據産品與其他産品差異性在于，數據産品通常是基于大量數據分析聚類後呈現的結果。而這一過程就涉及到數據波動、數據異常、數據敏感等諸多場景，針對這些場景對數據産品形态就有了更多的需求。數據産品形态大緻可分為三類，分别是平台系統、推送服務、專項服務。

平台系統解決的使用場景是“日常分析”，即用戶需要了解業務的明細，并且需要針對異常進行下鑽分析。通過構建平台/系統的産品形式無疑是最好的選擇。這類數據系統通常包含三個大的模塊，一個是首屏的數據看闆，将最重要的、總結性的數據呈現在看闆裡，用戶基于看闆了解概況；第二個是若幹産品模塊，按照解決用戶使用場景痛點的思路去構建；第三個是數據明細，滿足用戶了解詳情、自助分析的需求。

推送服務解決的使用場景是“下場幹預”，即用戶需要在第一時間甚至提前獲知信息，以留足時間構想預案并下場幹預。結合數據産品業務來看，推送服務根據内容性質可以分為兩類，一類是異常的數據，可以用“預警”的推送形态。所謂預警就是要以最快且最高效方式觸達用戶，通常觸達的内容不需要太多，達到突出重點、言簡意赅程度即可，目的是保證及時将信息推送給用戶并且引起用戶關注，常見的觸達方式包括短信、消息等形式。一類是常規的數據，可以用“報告”的推送形态。所謂報告是比較正式的推送，要求觸達的内容盡可能全面、詳細，能夠讓用戶通過報告大緻掌握信息，通常以郵件方式下發觸達。

專項服務解決的使用場景是“決策評估”，即用戶提出了一個比較複雜的指定需求，依靠系統自動化的能力可以解決一部分，未能解決的部分依賴于專家咨詢服務。專項服務往往是線下服務，需要懂業務的專家參與分析和決策。數據産品常見的專項服務場景是實現增長。通過數據産品發現異常後，比如活躍降低，然後利用産品下鑽分析能力快速定位到原因，最後提供提高活躍的解決方案，從而幫助用戶提高活躍，實現增長。專項服務往往是數據産品核心競争力之一，也能夠體現數據産品的核心價值——“發現問題-定位原因-閉環解決”。

四、産品設計：框架到模塊

根據用戶的使用場景，确定了相對應的産品形态後，接下來就要具體思考産品設計了。産品設計規範原則上來說是通用的。就數據産品特點而言，數據産品模塊和功能較多，在頂層設計前需要先搭建好系統框架，再往框架裡填充内容；在填充内容過程中需要遵循共同的産品結構，讓客戶/用戶感知到産品的整體性。

首先講下系統框架，任何産品設計都要從需求出發，系統框架也不例外。系統框架的工作是把收集到的各種零散的需求結合産品規劃進行整合，從而提煉出大的模塊，來作為産品發展的指南針。在梳理框架的時候，需要處理好模塊獨立性和關聯性。

所謂獨立性，即各模塊之間的功能和作用應該是相互獨立的。獨立性通常需要結合業務場景來考慮，在産品上表現即是多個菜單欄提供的功能及其要解決的痛點應該是相互獨立的，不要出現交叉。

所謂關聯性，即各模塊之間部分功能是具有相關性的，體現産品的全鍊路能力。這種相關性在産品層面有兩類表現，一類是簡單的功能跳轉，比如從A模塊跳轉到B模塊，實現A和B在某些功能上的關聯。一類是複雜的功能複用，比如C模塊需要用到A和B模塊的部分功能，實現C模塊的多維度綜合分析。

在獨立性和關聯性的原則下搭建好産品的框架後，接下來就要進行各模塊具體功能填充了。既然是一個系統性的産品，那麼同類模塊産品設計應該具有一緻性。具體來講，就是産品的結構（各功能的排列組合）應該是相同的。這就類似于寫作文一樣，需要考慮以什麼樣的結構去呈現文章。

數據産品常用的結構是總分，即在頭部呈現用戶最感興趣的内容，然後在進行下鑽分析。每一個模塊的頭部大概就是首屏的位置，通常需要把結論性的信息展示出來，呈現的信息需要盡量簡潔明了，必要的信息附上鍊接跳轉，方便用戶針對感興趣的或者有疑問的結論進行詳細分析。每一個模塊的軀幹部分就是支撐頭部結論的詳細數據，在産品展示上面，先借助可視化圖表提煉關鍵信息，然後再展示相關結論的詳情數據。

五、産品規範：細節的魔力

最後是産品設計的具體規範了，數據産品設計規範的核心目的還是在于保持産品的一緻性。盡量把産品、交互的每一個細節做好，自然就會赢得用戶的口碑。大多數數據産品都是基于大數據作業的，系統上幾乎是滿屏的數值，所以首先要講下數值的規範。

1. 數值的表示

為了方便用于閱讀并快速獲取信息，建議4位數及其以下用千分位表示，如1,234；大于5位及以上，用w表示，比如234.4w。對于大數值，千分位需要用戶再反映下，用w表示更為直觀明了，用戶一下子就能了解到數值涉及的影響面。

2. 小數的位數

到底是保留一位小數還是兩位小數呢？具體需要看數據的重要性。像股票、基金類的産品，小數一般是保留兩位，就算是百分數也保留了兩位，畢竟股票和基金的微小的漲跌幅都直接影響股民和基民的收益，當然是越精确越好。大多數數據産品都具有統計意義，數值都比較大，一般來說對于小數的精确度要求沒這麼高，保留一位即可。

無論是數值的表示還是小數的位數，最重要的都需要統一，從細節讓用戶感知到系統的質量。不能A功能數值用千分位，保留兩位小數，B功能用w來表示，保留1位小數。

産品設計規範還需要保證“異常”情況的交互一緻性。首先需要明白異常情況是産品并不希望出現的，但卻又是不可控的，所以一旦出現異常情況，勢必會對用戶造成負面影響。針對異常，産品設計出發點應該是盡可能去引導用戶。

對于大數據産品，經常出現的異常就是某個頁面無數據，最簡單粗暴的産品提示為“暫無數據”4個大字，這類提示隻能說比空白頁面好（容易讓用戶認為是bug）。面對“暫無數據”這4個字用戶可能還是會有疑問，究竟是真實數據出錯還是程序計算出錯而導緻呢？優秀的無數據産品提示建議說明無數據原因或者是引導用戶進行下一步操作。

針對不同場景産品設計方案：

1. 客觀無數據

建議提示：暫無相關數據，系統無法計算結果2. 因為數據量過少導緻某功能無數據建議提示：數據量過少，系統無法計算結果3. 因為用戶沒有配置而導緻無數據建議提示：暫無數據，請前往xxx配置4. 不知道原因無數據建議提示：暫無數據，如有疑問請聯系xx

最後再總結下數據産品設計理念：第一，在産品規範階段充分考慮用戶痛點，結合産品定位打造産品競争力第二，在産品形态階段根據不同使用場景構建相對應的産品及其服務第三，在産品設計階段先搭建頂層産品框架，再設計具體的産品功能第四，在設計規範階段注意數據産品的統一性，友好處理異常流情況

以上僅是本人在從事大數據産品策劃工作中的一些經驗，歡迎大家交流讨論，補充更多的産品設計方法和規範。

作者：morazhou，騰訊IEG産品策劃；公衆号：騰訊大講堂

本文由 @騰訊大講堂 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議

,