一個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步我覺得問題不大。因為到這個步驟，技術已經完全跟産品站在同一個起跑線了，會“補位”或“掰扯”産品功能如何實現的。

本文由 @減形簡遠 原創發布于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,