一個B端產品經理自身產品設計的質量和效率，直接決定了項目的結果與效率。但很多人一開始并沒有這樣的經驗，缺乏相對統一的思考框架及能力體系，難以快速輸出產品設計。作者結合自身經驗，總結了B端產品設計四步法，幫助你少走一些彎路。

之前在公司《產品學習小組》會上，我們討論過一個話題，就是產品經理有沒有相對統一的思考框架和能力評估體系。

結果，各個方向的產品負責人都有一個共識：就是技術的培養和評判標準，相對成體系一些，但是對產品經理來說，就會變得不太容易。

一方面是因為產品細分的方向比較多，另一方面產品跟業務走得近，相對屬性也會離散一些。所以就導致了產品的成長環境和路徑都會帶有非常強的個人色彩。

不過最終，產品出身的BOSS還是傳授給我們了一套他沉淀方法論——“萬能產品五步法”：① 用戶 – ② 需求 – ③ 場景/路徑 – ④ 痛點/訴求點 : ⑤ 解法

算是在宏觀上，把產品分析的過程有了一個框架的抽象。

經過學習演練，我也深受其益，一直在使用。

不過這個模型，我發現有一定的使用范圍。那就是比較適合于用戶比較確定且相對獨立的，C端適用性更強，或B端某一個特定用戶在限定場景內。

那如果是一個完整的B端產品，涉及到非常多用戶角色參與并相互協作，那就會需要另外一些方法來補充。

我覺得本質上，C端產品操作或B端在特定場景操作，是一個使用需求；但對一個完整的B端產品，各個用戶角色的使用更像是一個過程，他們共同協作操作完成的那個結果，才是B端產品本身的需求達成。

今天，我就嘗試來聊聊，B端產品設計的思考框架。

PS：以下文章內容，我們重點討論“產品設計”環節的一些方法。我們假定產品設計對應的需求價值分析沒問題，產品決策已經做過了。

不知道，大家在日常工作中會不會遇到這樣一個現象？

一些人接到一個需求后，馬上就會開始進入到功能設計：流程圖畫系統流程，xmind列功能清單，甚至直接axure開始畫交互頁面。

在這樣的操作下。大概率在需求評審環節、開發環節甚至上線后，他會遇到以下情況：細節遺漏、忘記協同其他部門進場、遇到無法解決的技術/資源卡點，最終導致項目不斷返工、延期，甚至停工。越大規模項目，問題會越嚴重。

在我的實際工作中，我也遇到很多以上這樣的情況。到最終，可能一個人需要很多項目的血淚經驗，才能慢慢做得成熟一些。

B端產品的基本面，是講究產品可用性的，各個鏈條環節的問題，都會影響最終結果。

這也是B端產品要求重邏輯和專業性的原因。

所以，一個B端產品經理自身產品設計的質量和效率，直接決定了項目的結果與效率。

那么，在B端產品設計中，有沒有一些像產品五步法一樣的方法，能指引產品設計，讓大家少走一些彎路呢？

過去一段時間內，我自己在部門內也做一些論證，也提煉了一套我認為比較有效的方法，我稱之為“B端產品設計四步法”。

接下來，我們按步驟講解下：

一、拆需求（用戶->場景->需求）

一個最小的子需求，應有3個要素組成：用戶**在**場景下的**需求。

那一個完整的大需求，就需要N多個子需求所組成。

但是，一個人如果想要直接面向子需求顆粒度去分析，對于大項目復雜項目，基本是不可能完成的任務。

在這里，我建議大家使用「角色×流程」象限圖表法。

按照這個框架，我們需要依次代入每個用戶的視角，來窮舉不同用戶在不同場景下的需求點。

PS：場景1、2、3、4，盡量按照信息流的時間線順序（大概率是可以的）。

注意，在這個環節大家不要考慮任何系統功能和實現，就用白話來描述需求點。因為后邊有其他步驟來做轉化的事情。

按照以上的原則，把各個象限表格填寫完成。

完成第一遍之后，還需要繼續第二遍，第三遍的review。

在后邊的每一遍檢查中，可以嘗試按不同流程（例如場景中包含的信息流、資金流、實物流等等）、按不同用戶（例如按照用戶生命周期時間線）來交叉比對信息。

串聯時候，一定要做到保證邏輯（不是系統邏輯，而是自然邏輯）自洽。

讀到這里，有人可能會問：這個象限圖表，看起來不就是多個用戶在驅動一個流程場景變化，能不能就是一個流程圖來呈現呢？

大部分場景下，是不能等同的。

嚴謹來說流程圖更多是單一主線隨時間變化的呈現，但是這個圖表中，其實會包含更多個流程圖，例如上邊說的信息流、資金流、實物流等等。

另外，還有一些前置準備信息、后置信息，都跟流程沒太多強耦合關系。畫成流程圖，特別容易遺忘這些需求點。

第1步「拆需求」，是產品設計最重要的一環，這個環節有偏差，后邊幾個環節都要跟著重新返工，會影響整體項目效率。所以，大家一定要在這個環節多花一些功夫。

二、需求轉譯事件

當第1步完成之后，我們就會得到不同用戶一個個明確的需求點。

那么第2步，我們就側重于需求怎么達成，這里給一個公式。

一個需求的結果 = 事件1+事件2+事件3+……

其中，事件X=用戶**通過**做**

一個事件，可以是一個頁面的按鈕點擊，也可能是一個邏輯的執行，也可能是一個sop的執行等等。

注意，不同事件之間，可能有先后順序或依賴關系。

在這一步中，因為是事件視角，就要關心能不能達成的問題，尤其是一些核心卡點?？茨男┦录耐瓿?，依賴外部、依賴資源、依賴技術可行性等等。

理論上，在這一步，就需要大面上確定各個事件的可行性。如果是關鍵環節不能達成，那就要尋找替代方案，如果找不到，那基本上也就不能繼續往下走了。

不少人，就是在這個環節內，沒有對關鍵環節做論證，導致詳細方案出完才發現有卡點，需求做不了。

我自己的經驗，第2步完成之后，才能去做項目立項。

三、事件模塊化聚合

第1步是按照用戶視角。

第2步也是按照用戶視角和功能視角。

完成前兩步之后，所有需求都被事件轉譯，接下來我們需要收斂一下功能點。

大家發現一個事件的元素組成是：用戶**通過**做**，這里面通過“**”這個對象，更多就是領域模塊。例如交易訂單、促銷、支付、清結算、業財、物流等等，當然這個模塊顆粒度可以更粗也可以更細，大家根據實際情況來決定即可。

這個步驟的主要作用，就是將離散的功能點所需要的承載體，聚類聚合。

因為需求最終落地的最細劃分會到模塊，而模塊一般情況其實跟崗位職責是對應起來的。例如A同學考慮A模塊的設計，B同學考慮B模塊的設計。

另外，功能點聚類之后，也能一次性get到大需求內所有對單模塊的影響點，便于一次性分析，省得來回倒騰。

四、詳細設計

完成以上3個步驟之后，其實產品設計的主要工作基本就完成80%。

剩余的，就是如何落地到具體細節設計和描述。要不就是新增一個能力，要不就是改動一個能力。

詳細設計的對象，可能是頁面的交互、一個自動腳本、系統校驗邏輯、線下SOP等等。

產品設計一定要結合現在系統的現況。一方面是現在系統的邏輯，另一方面是新能力疊加已有能力的成本。

這個環節會用到專業知識和設計經驗，每個人情況不同，我默認大家這個環節已經比較熟練，不再贅述。

不管如何，如果前面幾個步驟做得比較扎實，這個第4步我覺得問題不大。因為到這個步驟，技術已經完全跟產品站在同一個起跑線了，會“補位”或“掰扯”產品功能如何實現的。