編輯導語：當設計師有了一定的工作經驗后，往往會發現工作的范圍不再只限于輸出設計方案。這就要求我們除了專業的深度累積，也還需要拓寬橫向職業技能。本文作者今年完整的參與了一個從策劃到運營全程跟進的項目，在探索過程中，累積了一些產品搭建的基礎知識，并且分享給大家。

在我的認知體系中，將產品的類型進行了如下劃分：

以主體維度劃分，產品類型可分為“消費級產品”和“企業級產品”，也就是我們常說的“C端產品”和“B端產品”。消費級產品和企業級產品的區分特征在于，產品的客戶和用戶是否為同一主體。

所謂客戶，就是付費的那類人；所謂用戶，就是使用的那類人。消費級產品，付費的和使用的都是同一類人；而企業級產品，付費的和使用的不是同一類人。

基于以上的闡釋，我們可以給出書面的定義：

• 消費級產品，是指客戶和用戶為同一主體的產品。
• 企業級產品，是指客戶和用戶非同一主體的產品。

以需求維度劃分：產品類型可分為“工具類“、“社交類”、“生活類“、“信息類”、“娛樂類”、“游戲類“六種。具體的類型定義我就不做冗余闡述了，這些類型還是比較好理解的。

有了前序的產品類型分類后，明確要設計的產品是屬于哪種類型，接下來進入從0到1的必經之路。

一、評估產品的投入和產出

在建設任何一個產品或功能前，首先都需要考量建設的必要性。對于必要性的考量，無非就是要回答以下幾個問題：

1. 能帶來什么價值？

這個問題是產品的基石，實際是在思考用戶的本質需求。在這個階段我們很容易犯的錯誤就是把解決方案當成是價值本身。

用個大家爛熟于心的例子，用戶說想要一匹馬，但用戶的本質需求其實是想要提高通勤效率。

那么我們在回答這個問題時，就不能淺顯的認為答案是“我可以給用戶提供一匹汗血寶馬”，“提供馬”只是帶來價值的一種解決方案，并不是價值本身。

2. 價值怎么量化？

以工具類產品為例子，其價值就是降本或增效。到底能降多少本、能增多少效，是需要給出量化評估的。成本一般可用人力成本、硬件成本來評估，效率一般可用耗時來評估。

這里給出的量化評估，細化后就是后續產品的關鍵指標和目標。

3. 影響范圍有多大？

影響范圍其實可以歸入到價值量化的問題中，這里單拎出來的原因是因為這一點很多時候會被我們忽略。在系統產品中，影響范圍一般可通過角色數、用戶數來進行評估。

同樣的，影響范圍也是后續產品的關鍵指標和目標。

4. 需要投入多少資源？

設計師也應該需要具備一定的成本意識，對于產品開發的投入，一般會通過工時（人日）、硬件、外部采購這三個緯度來評估顯性成本。

同時，從經濟學的角度看，人力資源、部門預算屬于私用品，有時我們還需要考量其他產品因未能使用到資源而產生的價值損失等這類隱性成本。

TIPS：前三個問題是從“產出”的角度出發，第四個問題是從“投入”的角度出發。正如微觀經濟學的廠商理論中，會分為生產理論和成本理論兩個方向來研究。

二、業務流程與產品架構

當驗證完產品建設的必要性，決定要開發這款產品后，就該進入到業務流程的梳理和產品架構的設計階段。這是產品從0到1建設時獨有的一個必經階段，我們必須嚴肅、認真、敬畏。

業務流程，包括了業務流、狀態流、數據流，涉及錢的系統還會有資金流。產品架構，是指產品中的功能模塊或子系統組合。

對于復雜的系統，一般需要先梳理業務流程，再設計產品架構。產品架構會隨著業務流程的梳理而逐步呈現，這是一個很自然而然的過程。

在這個階段，我們會需要借助一些圖工具，包括業務流程圖、狀態圖、權限表、時序圖等工具。工具的種類是很多的，以下僅舉例我在項目中使用過的幾個工具。

業務流程圖主要描述的是業務需要經歷的主步驟，是狀態圖、權限表的基石。

完整的業務流程圖幫助產品、設計、研發、測試等各個角色的參與人快速了解業務全貌。

可以直接從業務流程圖中洞察業務邏輯是否合理，在更進一步的細化工作開始前，就能先砍掉很多不必要的分支流程（功能），或是修正顯而易見的邏輯錯誤。

狀態圖

主要描述的是業務步驟中存在的各種狀態，是梳理異常業務流的強有力的工具。

可以清楚的看到會有多少同頁面的不同狀態。設計師在初次接觸狀態圖時，容易忽略系統產生的路徑與頁面狀態，或是把系統路徑與角色路徑混淆在一起。

權限表

主要描述的是各角色對產品各功能模塊的頁面權限、操作權限、數據權限，是基于狀態圖，添加角色后的細分理解。

每種業務狀態都由相應的角色/系統操作產生，而鏈接其中的每條線就是賦予不同角色的權限能力。描述方式上，基于開發的語言，和技術模型的結果進行表達更清晰易懂。

將各角色與權限單元繪制成網格，每個交叉點網格中描述該角色與權限的數據關系和限制。

時序圖

主要描述的是功能模塊間的業務、數據、信息、資金的流轉，是基于數據流程圖對產品架構的最終呈現。和我們熟悉的服務藍圖比較起來，時序圖更適合面向研發人員，清晰的介紹數據流轉關系。

除了展現產品整體的數據流轉信息外，也可以用以說明某些涉及多平臺多方合作的數據流轉關系，以下的案例便是一個比較簡單且適合向開發哥哥闡述數據關系的時序圖。

TIPS：注意“這是產品從0到1建設時獨有的一個必經階段”的理解。這個階段雖然在后續產品迭代（從1到100）的建設中不是必須經歷，但是并不意味著就完全不會經歷。

一切都在變化之中，產品架構也會跟隨業務變化發生調整。

這并不是鼓勵我們可以隨隨便便的在迭代中重啟產品架構設計，架構設計一旦重啟，就意味著業務主流程的缺失或冗余，隨之而來的就是整個系統問題。

這個時候，就提頭去見開發哥哥吧。

三、優先級的考量

經濟學家說，社會的資源總是不夠的，人類的欲望總是多樣的。同樣的，完成了產品架構的建立，我們對產品所要具備的功能模塊或子系統已經了然于胸，但開發資源是有限的。

這個時候就需要一套機制或一種邏輯支撐我們做抉擇，決定哪些功能要先開發，哪些功能可以后面慢慢迭代。優先級是產品工作中常常掛在嘴邊且永遠繞不開的話題。

優先級本質上是對功能或需求的一種分類維度，而分類標準可以有兩種：用戶價值標準、企業價值標準。

以用戶價值為標準對優先級進行考量，最經典的就是Google的“牙刷理論”。牙刷理論把功能分為三個層次：很多人用、很多人經常用、很多人不僅經常用而且必須用。

以業務價值為標準對優先級進行考量，可以把功能分為三種：生死功能、特性功能、擴展功能。

生死功能是指剛性、痛點、決定產品生死的功能，如數據分析類產品的準確性；特性功能是指為了契合用戶、提高收入的功能，如數據分析類產品的美觀性；擴展功能是指不決定生死、不決定定位、不決定體驗、但又不可缺少的功能。

通過以上兩種標準綜合考量，功能模塊或子系統的優先級基本也可以梳理出來了。

四、概念模型與操作

接下來，我們就要開始進入具體功能模塊的策劃。誒，先別急著交互畫原型。在這個階段，我們需要思考，如何讓用戶理解系統功能的運作方式，這個過程就是在建立概念模型。

舉個簡單栗子，志愿者去為某公益機構服務做善事，我們會把這個過程理解任務認領的過程。

這就是一個簡單的概念模型，基本不用學習，我們就知道要去向機構認領再提交自己做的結果。但在數字環境下數據讀取中，任務認領就不是如我們表面看到的那樣簡單，而是在多個模塊甚至系統間交換數據。

點擊就可認領任務，就是一種方便用戶理解在數據流轉方面如何運作的概念模型。

試想，如果系統直白的將它原本的運作方式呈現給我們使用，我們甚至需要編寫一段代碼才可以成功解讀一個任務描述，再將任務歸屬到我的賬戶系統下，估計我們很多人一時半會兒學不會。

看完這個栗子相信大家應該對概念模型這個東西有點感覺了。概念模型幫助我們把復雜的物理現象轉化成可用的、可理解的心理模型，它是組織和理解復雜事物的非常重要的工具。

一個好的概念模型，可以化繁為簡，減少用戶的學習成本，這也是概念模型的意義所在。

完成了概念模型的選型和建立，用戶在這個功能模塊中需要執行哪些操作以及操作的步驟都將很自然的呈現出來。

TIPS：無論在產品開發環節還是在用戶與產品的交互環節，固有的復雜度都無法依照我們的意愿去除，只能設法調整、平衡。所以在建立概念模型時，產品經理不能僅僅關注用戶使用的復雜度，還需要考慮當前概念模型的技術可行性，要多和開發哥哥交流。

五、信息架構與頁面交互

這個階段處理的是用戶體驗要素中“框架層”和“表現層”的事物，是設計師擅長和熟悉的階段。也是我們本來就掌握和熟練的領域，所以在此處不展開細說。

六、關鍵指標制定

產品的效果必須要有可量化的指標來衡量，而且在產品的不同階段，需要關注的指標也會有所差異，關鍵指標的制定需要遵循以下3個步驟：

1. 明確產品階段；
2. 明確每個階段需要關注或突破的問題；
3. 針對問題制定有效反饋指標。

根據以上步驟，對系統產品，我們可以梳理出以下關鍵指標：

其中，“系統觸達業務”是指使用系統功能完成了某個業務任務，“系統觸達業務數”是指使用系統功能完成了某個業務任務的數量。

這個指標主要反映的是，用戶是在使用系統功能來處理業務，還是仍然按照傳統方法在處理業務。

七、發布計劃制定

發布之前，必須要做的是找一個專業的測試工程師來全盤測試幾輪。

與他們深度溝通，讓他們了解清楚整個系統的設計意圖，他們是幫助產品發現系統問題的重要角色，能大量的減少上線后出bug的問題。

這個階段還要解決的問題，是如何讓用戶更快更好更容易的接受產品新功能。

我們可以用一句話來描述：在什么時間點，針對哪些角色，針對哪些用戶，灰度或全量發布什么產品內容，發布后通過哪些方式教育用戶。

總結一下就形成以下的表格：

其中發布策略包括：灰度、全量。教育方式包括：額外的培訓、頁面指引、頁面宣傳等。

八、反饋的收集與分析

在這個階段的指導思路，我們可以采用望、聞、問、切：

• 望，觀察用戶的操作，可以通過可用性測試、眼動測試等實現。
• 聞，聽用戶的吐槽、抱怨、建議，可以使用兔小槽等工具輔助收集。
• 問，向用戶提問，注意要區分目的性提問和探索性提問。
• 切，分析指標數據，注意要對數據進行清洗和修正。

TIPS：問題的答案不是重點，重點是問題背后的意義。不了解問題背后的意義，即使知道答案，也只是照貓畫虎、東施效顰。

最后想說的：

產品搭建的套路是相通的，以上的8個步驟是我從交互設計師轉型產品體驗設計師的過程中，摸索的產品搭建基礎套路，是大部分產品都會經歷的起步流程。

產品搭建的套路又是不通用的，方法的適合度總是因人而異。所以，試著在你目前的產品建設中對以上套路實踐一番，你或許能理解的更到位，同時還能改造優化成更適合你自己的一套方法論

作者：louiezheng；公眾號：騰訊CDC體驗設計

來源：https://mp.weixin.qq.com/s/bohax0mVJh1x-566oXShdg

本文由 @騰訊CDC體驗設計 授權發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議