B端產品設計相對於C端，更注重行業經驗和業務邏輯。本文作者分享了在實際工作中總結出來的B端產品設計全鏈路流程，讓我們一起來看看吧。

B端如何做產品設計？

B端產品設計相對於C端，更注重行業經驗和業務邏輯，所以設計思路明顯不同。本篇文章將和大家分享我在實際工作中不斷最佳化的B端數字化產品設計全鏈路流程，希望可以給你一些啟發。

B端產品接收到的業務需求一般來自老闆、業務方或者產品自己，如何更高效、更準確的將其轉為IT人員能看懂的產品需求就是考驗產品經理的設計功力了。

另外，在產品設計環節主要交付物有業務調研報告、產品地圖、產品流程圖、資料寬表、原型介面、產品需求文件，如何把這些更有機的連結在一起便是產品思維和產品方法論了。

一、調研報告

調研業務需求，一定要做的三步：

1。 識別系統涉及的利益方

涉及的外部角色【客戶】

涉及的內部角色【使用者】

角色的職能【參與者、執行者、決策者】

職能的邊界

角色、職能的互動

2。 識別業務場景

梳理業務場景清單、業務處理流程，然後繪製出業務基本流程圖。這也是方便進一步識別業務當前各個環節出現的潛在問題。

3。 識別問題矛盾點

一定要識別業務當前遇到問題的痛點，產品要解決的什麼問題？目前B端產品也是趨於穩定，當下企業更注重業務價值導向，而不是一味的技術導向。

最終，輸出產品調研報告。

二、產品地圖

基於上述業務調研報告，接下來就需要輸出產品地圖，即構思系統骨架。

產品地圖，它是系統設計的一個整體性指導性檔案，要想擁有一個完善完整的產品地圖是急不得的。

那如何完善自己的產品地圖？一般我的操作思路大致是：透過不斷的梳理業務場景、業務流程、業務規則，按照低耦合、高複用原則，以及MVC的軟體架構模式，逐步確認產品骨架。有了產品地圖也就有了產品規劃方向，便可以著手做原型設計了。所以可以看出我將產品地圖作為產品設計的整個環節的主要鏈條以及切入點。

系統架構設計的重點原則要做到低耦合、高複用：

所謂低耦合：按照業務相關性設計多個系統應用，它們之間透過API進行互動。這樣，單個應用的升級，對其他應用的影響就小很多，從而提高了系統的敏捷性。比如，把預算管理中的預算編制、預算控制、預算審批就可以獨立為多個應用。

所謂高複用：將各個模組通用的功能抽離出來，單獨形成一個系統應用。這樣，一方面確保了資訊來源的一致性，另一方面也簡化了系統架構，避免了重複開發。

通常產品地圖包含以下層級，每層都是起到承上啟下的作用：

業務層：主要展示上游系統功能模組或者下達操作的指令。

閘道器層：主要提供通用介面供上游呼叫，完成業務層和應用層互動，而無需關注架構或底層發生的怎樣的變化。

應用層：主要負責對資料層的操作，即系統邏輯的組合模組，也是系統的主要核心邏輯層。

資料層：主要展示各類模組的資料寬表，通常是結合上下游，以及系統響應模組對資料需求整合而成。

服務層：主要提供基礎服務能力，比如為應用層傳遞的訊息，為資料層提供的基礎資料等。

示例如下：

三、產品流程

B端產品往往需要支援多部門、多角色協同。因此需要在整理完業務行為與場景後，找到各角色與職能，我們便可以提煉出系統核心運轉的產品流程。

在範圍上，整體流程圖需要覆蓋所有關鍵流程。在顆粒度上，只需要展示關鍵操作環節即可，不需要細緻到具體功能頁面。

示例如下：

四、資料寬表

資料寬表確認方式，一般是結合上游應提供給我的資料，下游需要我提供的資料，再結合我自己需要的資料，將三者歸納聚合在一起，就有了資料寬表及API規範。

五、許可權管理

B端業務開展，是基於多個部門的相互協同和相互監督的。當用戶在使用B端系統時，流程流轉、資料安全性都必須符合企業協同與管控的要求。

因此就需要我們針對系統設定許可權管理，這是必不可少的一步。許可權管理說明一般需要包含系統許可權樹說明以及對應許可權配置要求，方便IT人員在ERP上針對角色分配許可權。

示例如下：

六、產品原型

基於以上內容，確定產品規劃後，我們便需要思考系統功能頁面的流轉圖了，這裡主要是設計使用者可操作頁面demo，讓系統相關角色提前感知系統上線後的操作邏輯，獲取他們對產品設計環節的不足之處，並得到及時修改建議。

示例如下：

最後，我大致和大家分享下在產品設計環節時間分佈，大概是：框架規劃：50%；介面設計：20%；評審溝通：10%；摸魚：10%。

大部分的時間主要是放在框架規劃上，因為在我看來，這個才是產品經理的核心競爭力。

作者：姚明

本文由 @姚明 原創釋出於人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。