從0到1設計一款B端産品，分不開兩個階段，一個是整體設計階段，另一個是詳細設計階段。其中都有哪些工作需要準備，一起來看看作者是怎麼說的，希望對産品初學者、一直在做産品功能設計的産品人帶來幫助。
幾天前，跟兩個工作5年以上的産品經理聊産品設計。令我驚訝的是，他們居然不清楚B端産品的設計分為兩個階段，一個是整體設計階段，另一個是詳細設計階段。
分析原因，大概是因為他們一直在基層崗位擰螺絲，接觸的都是詳細設計階段的内容，對整體設計不熟悉也就不足為奇了。這就是在大廠擰螺絲的弊端吧。
有感于此，我才準備寫本篇文章，從整體上介紹如何從0到1設計一款B端産品，并努力做到圖文并茂吧。希望能對産品初學者、一直在做産品功能設計的産品人有一些幫助，讓他們從更高的視野來看待産品設計這件事。
文章較長，目錄如下。
一、第1次業務調研
在決定好做某個方向的産品，并聯系好調研的客戶之後，就開始了第1次業務調研。
這裡有一個常見的誤區，認為業務調研是一次完成的。實際上，由于B端産品涉及的業務較為複雜，是以，業務調研往往不是一次就能完成的，通常需要多次調研。
多次調研并非随意調研，而是按照由上至下、由大緻小、從粗到精的順序進行調研。就像剝洋蔥一樣，從業務架構開始一層一層剝，直至業務細節。
1.1 調研前的準備工作
由于是第1次業務調研，也是第1次與客戶接觸，是以我們需要給客戶展現我們的專業性，讓客戶信賴我們，讓客戶相信我們。是以，在第1次業務調研前，需要了解行業裡通用的業務模式。在與客戶溝通交流的時候，能夠與客戶平等對話。
比如，客戶想做一套自己的電商系統，那麼在去客戶那裡調研前，我們需要搞清楚通用的電商業務模式。
1.2 調研的目的
第1次業務調研的目的如下。
- 明确業務範圍；
- 梳理客戶的業務現狀；
- 了解客戶業務的痛點和問題，以及客戶的期望。
1.3 調研哪些内容
由于我們已經知道通用的業務模式，是以調研的重點就放在客戶個性化的業務上，如此可以減輕我們調研的負擔。
具體來說，需要調研的内容包括：梳理整體業務流程、明确客戶的痛點/問題以及期望，了解客戶的組織架構。
1.3.1 整體業務流程
由于本次調研的目的之一是明确業務範圍，是以不用調研業務細節，隻需要弄清楚客戶的整體業務流程。
一般來說，整體業務流程需要達到的細度是，能夠表達出各參與方在哪裡做什麼事情。換句話說，就是搞明白三要素：參與方、現有業務系統、各參與方在業務系統中的業務活動。
我們以某電商的業務為例，說明整體業務流程，如下。本篇文章後續的例子，将基于該電商的業務展開。
在梳理整體業務流程時，需要注意兩點。
首先，需要搞明白業務流程中存在的痛點和問題，這是我們後續做方案時需要解決的。
比如，在上面的某電商整體業務流程中，供應商通過線下手工方式給平台提供商品資訊，由平台在電商平台端錄入商品資訊。随着買家需求的增長，供應商和供應商提供的商品資訊均在逐漸增多，平台錄入商品資訊需要的人力也逐漸增加，這給平台帶來很大的負擔。
其次，需要搞明白客戶現在用的系統有哪些，各個系統的作用是什麼，客戶對這些系統的替代或內建是怎麼考慮的。這是我們後續考慮系統內建方案的基礎。
1.3.2 組織架構
B端産品的客戶往往具有多層級組織架構。比如，集團下面有各個公司，公司下面有子公司，子公司下面有孫公司，孫公司下面有門店、項目部等。
了解清楚客戶的組織架構，将有利于後續的權限設計。
1.4 調研後需要傳遞什麼
調研結束後，不是簡單跟上司彙報調研情況就可以的，而是需要寫一份調研報告。調研報告的内容包括：
- 客戶業務現狀，會用到整體業務流程圖，并輔以文字說明；
- 客戶業務存在的問題，以及客戶的期望；
- 哪些問題可以用産品解決；
- 問題的優先級清單。
調研報告完成後，需要與客戶溝通并獲得客戶确認。
二、整體方案設計
客戶認可調研報告後，我們開始産品整體方案的設計。相比于細節方案設計，整體方案設計更宏觀，不涉及業務細節和産品原型。
2.1 整體方案流程設計
根據我們在第1次業務調研中得到的痛點和問題，對客戶整體業務流程進行改進，形成整體方案流程。
整體方案流程需要表達出的三要素是，參與方、系統（現有的和将要做的）、各參與方在系統中的業務活動。
針對平台錄入商品資訊負擔重的問題，給出了解決方案。建設一個電商供應商端，由各個供應商送出商品資訊，然後平台負責稽核商品資訊。這可以降低平台錄入商品資訊的負擔。同時，供應商送出的商品資訊需要經過平台稽核，可以有效避免供應商錄入資訊不規範的問題。
2.2 産品定位
産品定位是要闡明，系統（産品）為誰提供什麼服務。
我們舉的例子中，電商供應商端的定位是，為供應商提供商品資訊送出與管理等功能。
如果系統涉及的參與方比較多，那麼可能需要将系統拆分為若幹子系統，并分别闡明各子系統為誰提供什麼服務。
2.3 功能子產品設計
功能子產品設計，就是考慮為使用者提供哪些功能子產品，以滿足産品定位。
這是一個做加法的過程，把能想到的功能子產品都羅列出來。在這個過程中，可以參考競品的功能子產品。
2.4 應用架構設計
應用架構設計的目的有兩個，一個是說明各個功能子產品之間的關系，一般指資料流轉關系；另一個是說明系統的功能子產品與公司内部其他功能子產品間的關系，是改造還是重新開發。
由于電商系統中已經有訂單管理子產品，且訂單管理子產品包含訂單及其狀态等資訊，是以電商供應商端不需要重複開發訂單管理子產品。為了實作電商供應商端的訂單清單和訂單取消申請兩個子產品，隻需對訂單管理子產品的接口進行改造。
2.5 産品路标設計
産品路标設計，就是依照業務優先級确定功能子產品的實作節奏，即YY1年MM1月DD1日實作哪些功能，YY2年MM2月DD2日實作哪些功能……
做完以上5個步驟，就完成了産品的整體方案設計。在進行第2-n次業務調研前，需要與客戶确認整體方案。
三、第2-n次業務調研
3.1 調研哪些内容
第1次調研的内容比較宏觀，是以第2次調研需要搞清楚各個功能子產品所涉及業務的現狀、存在的問題和痛點，以及使用者的期望。
具體來說，需要梳理出各個功能子產品所涉及的業務流程，并畫出業務流程圖。同時，需要對客戶的報表需求進行調研。
如果第2次調研後發現還有一些細節沒有弄清楚，那麼就需要更多次調研。但是，最好在調研前做好調研計劃，每次調研内容盡量系統、全面，以減少調研的次數。因為客戶一般都比較忙，不太容易約調研時間。
3.2 調研需要傳遞什麼
調研完成後，需要産出調研報告，并與客戶确認。調研報告的要點與第1次調研後輸出的調研報告相同。
四、詳細方案設計
4.1 詳細方案流程設計
根據第2次調研得到的業務問題、痛點和使用者期望，對目前的業務流程進行改進，并分别繪制各個功能子產品詳細方案流程。
詳細方案流程描述的是角色A在系統B中做事情C。換句話說，詳細方案流程的三要素是角色、系統、活動。
通常，用跨職能業務流程圖表示詳細方案流程。
4.2 頁面流轉圖設計
頁面流轉圖是比詳細方案流程圖更細節的圖。相比詳細方案流程圖，頁面流轉圖描述的是角色A在系統B中為了完成事情C需要的操作D，以及操作涉及的頁面。可以看出，頁面流轉圖的要素是使用者操作和頁面。
基于頁面流轉圖，可以梳理出産品的頁面有哪些，這是後續産品原型設計的基礎。
4.3 産品原型設計
産品原型設計大家都比較熟悉，就是把設計意圖形象、直覺地表示出來。
不同的公司，産品經理在原型設計時的分工稍有不同。有互動設計師的公司，産品經理畫出線框圖就行。如果公司裡沒有互動設計師，那麼産品經理需要把互動設計也做出來。
對于B端産品，最重要的是解決客戶的業務問題，而不是把使用者體驗做到極緻。是以，我們會看到很多B端産品的設計很low。這不是因為B端産品經理的審美水準不行，而是因為客戶并不需要高大上的使用者體驗。但這并不是說使用者體驗就不重要，可以随意瞎搞，而是不需要在使用者體驗上花費大量精力。
4.4 權限設計
B端産品的特點之一是，客戶的組織架構複雜。為了保證資料的安全，需要進行功能或資料的權限控制，這就涉及到權限設計。
通常，權限設計分為功能權限設計和資料權限設計。功能權限設計是對頁面中功能點的通路權限進行設計。功能權限設計有一套經典的理論模型——RBAC模型，一般的B端系統都會基于這個模型設計功能權限。
資料權限設計是對使用者能夠查到的資料範圍進行設計。通常而言，使用者的資料權限和他在組織架構中的節點有關。
4.5 埋點設計
為了量化産品的使用效果，同時記錄使用者的使用行為，需要進行埋點設計。通過埋點，可以擷取使用者的行為資料，進而對該資料進行分析，進而得出有價值的結論，例如，如何改進産品的功能。
至此，就完成了一個B端産品從0到1的設計。
作者：産品經理伯庸；微信公衆号：産品經理伯庸；
本文由 @産品經理伯庸 原創釋出于人人都是産品經理。未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協定
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。