編輯導語：產品詳細設計，是對產品的具象化呈現，是向研發團隊展示產品的實現邏輯、業務規則等內容。本文作者從建立業務模型、確認系統底層結構、系統操作流程三個步驟，拆解了“詳細設計”，希望看后對你的B端產品設計會有所幫助。

在整體解決方案中完成了產品定位和規劃等工作（整體方案詳見上一篇），也明確了產品在不同階段分別要實現的功能模塊，接下來的產品詳細設計由此展開。

什么是產品詳細設計？是對產品的具象化呈現，是向研發團隊展示產品的實現邏輯、業務規則等內容。在呈現內容上需要保持簡潔明了，將復雜的邏輯通俗且直觀的表達出來，讓其他成員更容易理解。

在實際操作中，我們可以通過3個步驟依次分解：

1. 通過“建立業務模型”確認系統底層結構；
2. 通過“系統操作流程”描述用戶執行任務的路徑；
3. 通過“繪制產品原型”呈現產品的界面、交互、規則。

接下來開始我的表演。

一、建立業務模型

建系統猶如建房子，先確定房子的框架，然后打地基、搭鋼架、添磚加瓦。

在整體方案中確定了系統框架，詳細設計將從打地基開始，而不是一上來就添磚加瓦。建立業務模型就是系統的“打地基”，直接影響系統底層結構。后續的詳細設計是在業務模型下進行拓展，如果業務模型設計偏差，系統從開始也就歪了。

注意：一旦底層的業務模型涉及大范圍調整，則后續設計和開發都將受到嚴重影響。業務模型的建立也是對底層數據歸類的過程，可以從3個步驟來實現，并通過ER圖或其他方式進行展示。

1. 要素抽離：根據之前梳理的業務流程進行再次抽象，提取流程中出現的關鍵業務要素；
2. 2找準關系：羅列關鍵業務要素，結合業務邏輯找到關鍵要素之間的關聯關系；
3. 設計模型：考慮業務訴求、資源限制、系統拓展性等情況，設計出對應模型。同時配備對應文字解讀，避免看圖出現遺漏信息。

舉例：Z公司TMS項目中，通過訪談方式對業務流程進行了全面梳理。部分業務流程為：計劃員創建運單任務（訂單），調度員根據訂單的運輸量、物料等要素對運單進行拆分或合并，再根據承運資源池中不同車輛任務分配情況指派給對應司機生成車次。

在梳理過程中找到了諸多要素，部分關鍵要素為：訂單、運單、車次。下圖以簡化版的業務模型為例，看看不同圖形表達的呈現效果。

圖1

圖2

上圖中，業務模型想要表達以下信息：

1. 1個訂單可以和1個或多個運單進行關聯；
2. 1個或多個運單可以和1個車次進行關聯；
3. 來自不同訂單產生的運單可以關聯到同1個車次。

二、系統操作流程

經過業務模型了解了業務關鍵要素關系，接下來可以著手系統操作流程設計。流程合理、角色任務清晰是系統設計成功的前提。我們應遵循從業務起點至終點、從主流業務到分支業務、從正向流程到逆向流程的設計思路，同時考慮各任務的邏輯先后順序和依賴關系。

系統操作和業務是存在著對應關系，都是由一個個任務銜接而成，可以從角色和任務2個維度來拆解，并通過跨部門流程圖+備注進行展示。單個環節可以從以下4點細化：

1. 參與角色：對應任務的參與角色，包含了人員或物體（如設備、單據等）；
2. 任務觸發：滿足什么樣的條件來觸發對應任務的執行，如預設的執行時間、上游的輸出物等；
3. 任務執行：在當前任務中，參與角色需要完成的事項；
4. 結果輸出：事項完成后產生了什么交付物，并通過什么方式向下游進行傳遞。

系統操作流程確定后就可以繪制頁面流轉圖，即用戶完成對應任務需要訪問的頁面及頁面跳轉的順序，頁面流轉圖可以更好的幫助團隊成員理解用戶的操作行為路徑。

舉例：Z公司TMS項目中，通過對業務模型的完善，接下來對訂單、運單、車次的簡化版系統操作進行描述。我們通過Visio的多泳道流程圖來呈現，并配上關鍵節點的文字描述。

1. 創建訂單

• 角色：計劃員
• 描述：通過在系統后臺手動創建，或者是通過Excel表單導入，把排產計劃轉變為訂單。

2. 訂單審核

• 角色：計劃員
• 描述：訂單創建之后，需要管理員進行審核，確認訂單內容沒有錯誤審核通過之后，系統會自動生成運單。

3. 運單拆分

• 角色：調度員
• 描述：運單生成之后，當運單的物料過多，一輛車裝不下的時候，可以進行運單拆分，將運單拆為多單。

4. 運單指派

• 角色：調度員
• 描述：運單確認無誤后，可以指派對應的車輛和司機去執行這個運單。支持1單1車和多單1車。

5. 調度審核

• 角色：調度員
• 描述：審核運單指派的車輛和司機，確認調度無誤后即可執行。

6. 生成車次

• 角色：調度員
• 描述：運單指派審核通過之后，系統自動生成車次。同時支持打印派車單。

7. 運輸執行

• 角色：司機
• 描述：司機接到車次任務之后進入運輸執行環節。包含到達取貨點、已裝車、到達送貨點、已簽收等多個環節。

三、繪制產品原型

經過了業務模型、系統操作流程、頁面流轉圖等相關內容的輸出，已經做到了對產品從全局到細節的全面了解，最后輸出PRD交付研發團隊即可。

產品原型是PRD的重要組成部分之一，原型需要將系統頁面元素和排版、交互效果、系統規則等信息通過簡單明了的方式進行展現，幫助團隊成員更好地理解需要實現的效果。

原型工具有很多，如Axure、墨刀、摹客等。

在繪制原型圖時將需要的元素和排版表達到位即可，堪比UI稿的高保真原型是沒有必要的。比如配色可使用黑、白、灰、藍、紅進行表達，復雜配色對研發和UI團隊來說并不一定友好，同時也會消耗自己大量的時間資源。

B端產品系統主要由4類頁面組成，通過了解頁面類型設計時可以結構化的組織信息，便于向用戶提供可預期的操作，降低使用成本。如下：

• 表單頁：用戶在系統中進行新增、刪除、修改等提交信息動作的操作頁面。如登錄頁，提交用戶名和密碼；
• 詳情頁：系統向用戶展示對應詳細信息的頁面。如任務詳情頁，展示任務編號、時間、狀態、內容等信息；
• 列表頁：系統向用戶展示對應同類型的數據信息。如任務列表頁，展示編號、名稱、狀態、操作等字段；
• 圖表頁：系統向用戶展示綜合型頁面，此類頁面多有圖形和表單構成，常見如數據分析頁面。

舉例：Z公司TMS項目中，以運單管理為例展示運單列表頁、運單詳情頁、指派司機彈窗的原型及對應規則備注（示例中的原型和規則備注方式還可以進行優化）。

圖1：運單列表頁

圖2 ：運單詳情頁

圖3：指派司機彈窗

交互設計關注點：

• 遵循“尼爾森十大可用性原則”：從多個方面保障交互的合理性、可用性、友好性，甚至可以在設計完成后進行復查；
• 不建議設計復雜交互：B端產品目的在于幫助企業解決業務問題，交互優先級并不高，復雜交互不利于用戶操作同時也過多占用研發資源；
• 采用標準模板和控件：行業內會很多成熟的商業軟件，獲得了用戶認可，可以借鑒系統布局、交互方式等，幫助提高設計效率。

以上。

本文由 @耳目不染 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議