産品需求是如何落地到原型設計的？本文将結合案例和大廠産品經理常用的方法論，通俗化講解如何系統拆解産品需求，希望對你有所收獲。
一、産品經理設計思路是什麽樣
面臨新業務線拓展或者産品升級的時候，在收集到一大堆亂七八糟的需求後，你可能會想，我要怎麽着手呢？答案是，搭框架找思路。
這是一個産品經理通用的設計思路框架，遵循由粗到細、自上而下的流程，具體如下：
戰略層—–業務目标是什麽，即定方向，含用戶、使用終端、市場競争力和解決方案、項目計劃；想清楚做什麽，即把具備價值的需求進行梳理優先級排序包括形成産品初步架構
搭框架—–（功能和 DFX 非功能框架）難點在于梳理功能的全面和思路；dfx 需求：保證用戶使用産品的安全、性能、可拓展等需求注：DFX 其實很重要但大部分都會被忽視，此文不做拓展、後續會通過一篇文章進行詳細說明，（産品經理千萬不能隻盯住功能做産品）
拆細節—–業務流程（重點梳理異常分支和外圍數據交互）、業務操作、信息結構）
畫界面—–交互設計、信息設計
以上的思路大家可以按需參考，本文着重講解拆解 2 步驟的方法，即搭建初步功能框架，并可落地到原型指導設計。
二、如何搭建功能框架呢？
注：搭功能框架也是從寬度上定義業務範圍，而不是要深挖細節、要注意避免陷入思路混亂、把握好分寸、見好就收。
1. 用例驅動設計法（UDD）
用例驅動設計是一種基于用戶行爲和需求來設計軟件開發的方法，有步驟有層次梳理出系統功能的方法，可粗淺理解爲用戶故事，是一個通用的搭框架方法；如類似網購下單、酒店預定、銀行貸款等場景；
整體思路遵循：識别參與者使用場景及問題—–定義描述用例（目标層用例—步驟層用例— - 實現層用例）并簡化
（1）識别使用場景及問題
首先，我們通過華爲 IPD 需求管理思路那篇，知道産品需求 = 基于場景的解決方案，因此拿到一個産品需求，我們需要想清楚對應的場景，即 5w1h1e。
who（面向對象）、why、when+where（場景）、what（幹什麽）、以及 how（怎麽實現）、else（限前置和後置）
比如要做一個訪客預約系統，按照上面的描述方法，我們明白了系統的使用場景是這樣：
一個基于外來訪客，由于園區爲了保障安全管理，在臨時進入園區前，需要進行線上登記個人資料、并實名認證的産品，并且園區審核通過，驗證身份才可以進入和離園。
（2）拆分：目标層 - 步驟層 - 實現層
結合上面的例子：
訪客進入園區就是目标層用例，爲了實現這個整體目标，我們需要步驟層用例進行支撐，這時候就可以拆分爲第一個大框架
具體爲：
步驟 1：訪客在系統上提前登記—–線上預約
步驟 2：訪客填寫登記資料—–填寫表單
步驟 3：園區通過系統審核資料并通知訪客結果—–審核管理
步驟 4：訪客接收通知— - 消息提醒
步驟 5：訪客查看提交記錄—–預約記錄
步驟 6：訪客獲得許可進入園區—身份驗證
步驟 7：訪客離園确認—身份驗證
那針對每一個步驟層、具體如何實現呢？按照這個思路，通過拆分形成實現層用例（也就是用什麽方案實現）
最終這個功能框架會形成這樣、（注意把不同用戶端分開保證用例全面）如圖：
當然這是初步框架，僅作部分舉例說明，你們可以自行拓展，隻要保證覆蓋全部的用例就行。
在這裏，我們要注意幾點：
在多種實現方案并存的情況下，如何權衡呢？
1、結合功能實現成本、第三方對接周期、客戶需要、技術實現能力、外圍的交互模塊等多方面因素進行決策，選擇一個較爲合理的實現方案：
2、如上面的進出身份驗證，給了 4 種方案，有通行掃碼、臨時卡、人臉識别、指紋、語音，包括我們常見的支付也可以多種路徑實現，如現金支付、信用卡支付、微信支付等
小結：
1、工具：建議用思維導圖、或者用例圖進行梳理
2、目标：是形成産品功能結構（含一級特性、二級特性、甚至三級特性）
3、适用項目：比較獨立、小型或需要快速叠代和更新的項目，注重從用戶的角度出發來描述系統的功能需求
4、特點：方便快捷、拓展性較差、易于理解協作，但難以适用複雜業務
2. 流程驅動設計法（PDD）
适用于業務協作方較多，具備較複雜的業務層級及審核，更注重流程标準化管理的産品，如 CRM、ERP 系統、工單管理系統、采購系統、數據精細管理等。
整體思路遵循：識别關鍵業務流程—–拆分目标層用例—–業務操作
比如 CRM 系統的流程是有明顯前後順序的，且爲了精準做好客戶關系管理，标準化的流程非常重要。通常按照以下步驟進行操作：
1、客戶檔案創建和維護—–客戶管理流程
2、銷售機會（Lead）創建和跟進——銷售管理流程
3、市場活動的策劃、執行和跟進—— - 市場活動管理流程
結合以上順序流程，就很适合用 PDD 來搭框架，我們大概拆分出幾個目标層，并進一步落地到具體的功能模塊中。下面是一些可能包括的模塊：
客戶管理模塊：
a. 客戶檔案：創建、查看、編輯、删除客戶資料；
b. 客戶分類：對客戶進行分組和标記，例如根據客戶來源、優先級、交易狀态等進行分類；
c. 客戶關系曆史記錄：記錄客戶與企業之間的活動曆史，包括通話、郵件、漏鬥進展等。
銷售管理模塊：
a. 銷售機會（Leads）：創建、跟進、評估及關閉銷售機會，可以關聯相關的客戶信息；
b. 産品 / 服務信息：錄入、查看、編輯和删除産品或服務信息；
c. 報價單 / 訂單：創建、發送、聽取意見、确認并完成報價和訂單交付等流程；
d. 合同信息：建立一個合同管理庫存儲合同信息，以追蹤合同執行情況和收款計劃。
市場活動管理：
a. 活動策劃：創建市場活動，定義主題，摘要、預算、時間表等參數；
b. 活動跟蹤：批量創建活動推廣計劃來實現對活動方案的執行，包括在線廣告、email、電話營銷等；
c. 活動分析：記錄活動成效，比如郵件打開率、轉化率等進行績效統計，以及對活動與銷售數據的關系分析。
在設計過程中，功能模塊要盡量緊密貼合上述 CRM 系統的整體流程，具體實現時，也可依據企業的運營或者工作方式進行特定的定制。
例如，在某些企業中市場活動管理可能更爲重要，根據不同的客戶屬性，社交媒體營銷方式有些偏年輕化公司會利用大量互聯網和移動設備，而傳統行業的企業上門拜訪更常見。
1、适用項目：PDD 适用于更大型、複雜或需要對業務流程進行全面分析和優化的項目。
2、工具：UML 流程圖、狀态圖等
3、優點：幫助理清内部系統數據、業務流程，基于過程建模，從整體到局部深度設計，複雜業務簡單化
4、缺點：過于關注流程，導緻各個子系統業務耦合較高，難以實現拓展
3. 領域驅動設計（DDD）
領域驅動設計（Domain-Driven Design，DDD）是由領域驅動設計之父埃裏克 · 埃文斯提出的，涵蓋面較廣，其核心思想是先梳理領域信息結構和業務規則，再梳理業務的用例、流程和操作等内容。
整體思路遵循：确定場景領域— - 識别核心領域對象（信息結構）— - 業務規則（定義對象之間的屬性關系及行爲）—–其他模塊的交互
舉例：場景領域— - 電子商務平台
我們識别到的核心對象爲：
商品管理：包括商品信息的管理、上架、下架、分類、标簽等。
訂單管理：包括訂單的生成、查詢、修改、删除等。
用戶管理：包括用戶信息的注冊、登錄、個人信息維護等。
支付管理：包括各種支付方式的接入、支付狀态的管理和處理等。
物流管理：包括訂單狀态的跟蹤、配送信息的記錄、快遞單信息的管理等。
售後服務：包括退換貨的處理、客戶服務的管理、投訴反饋的處理等
這裏以訂單管理爲例，用類圖表達信息結構。
信息結構表述了信息内容之間的關系。這種關系可以用類圖（Class Diagram）來表達。
該圖片來源于圖書【" 圖解 " 産品：産品經理業務設計與 UML 建模】作者擎蒼
當我們使用類圖來識别領域模型和實體關系後，需要根據業務需求和限制條件定義對象、屬性、操作業務規則和流程，如買家隻能在特定時間段内下單，不能重複購買同樣的商品；訂單滿足 3 人立刻成團進入待支付；訂單超時未支付自動取消等。
最後，在實現層，我們需要識别系統内的其他部分或與系統交互的部分，并确定他們對業務領域的影響。比如，與支付相關的銀行接口、第三方支付接口、物流跟蹤動态數據的集成等都是我們必須考慮的。
适用行業：複雜且靈活多變的行業需求，開發此軟件的公司，通常是行業的引領者，如中台等大型團隊項目
工具：UML 類圖、思維導圖
優點：低耦合可擴展、能靈活應對複雜業務變更需求、可增強代碼質量
缺點：團隊技能要求高、時間成本高、協調難度高、編碼量增加（長期來看是值得的）
注：通過選擇合适的方法論，我們完成了産品設計第 2 步：搭框架，後續再通過第 3 步拆細節，重點梳理各分支下的異常流程，逐步完善細節，最後一步，再進行頁面信息收集填充，剩下的就是畫原型了，此處不做展開。
三、面對不同項目，如何選擇？
綜上，通過以上 3 種搭功能框架的方法論，我們知道，産品設計方法論，包含用例驅動設計發（UDD）、流程驅動設計法（PDD ) 、領域驅動設計法（DDD），我們來整體再做個對比總結，通過以下維度進行決策，方便我們在具體的項目設計中，選擇較爲合适的方法。
當然，他們各自有優缺點，在一個項目裏，完全可以結合交叉使用。
四、拆解需求需要具備的能力和思維
設計思維：清晰的産品設計思路、并形成自己的通用方法論，掌握并應用（如上面的 3 種方法）、包括其他的成熟模型（如 AARRR 模型…）
設計方案：内心要有很多成熟可用的方案思維和評估方案的能力，就需要多練多看、多去關注一些最新的技術，不然沒法梳理框架裏具體都包含什麽，怎麽實現
深度思考能力：多使用結構化思維培養深度思考能力、體現在異常流程、外圍數據交互處理上（平時要多觀察競品、多問幾個爲什麽、包括開發階段潛在的問題、面對開發的質疑才可以真正說不）
最佳的 UI 感及交互設計能力（審美、人機交互最佳策略）
工具使用能力：巧用 UML 建模，事半功倍（重點關注類圖、用例圖、狀态圖、流程圖）、還有其他思維導圖等
五、其他想說的話
本文的重點是教大家如何通過成熟的方法論，拆解需求指導原型設計，在寫的時候，裏面其實包含了很多知識點，并沒有展開：
比如最容易被忽視的 DFX 需求：UDD、PDD、DDD3 種方法論如何靈活保證系統的 DFX 需求，這部分産品經理必須有相應地思考和考量，不能老是産品做了用不起來或者代碼混亂、後面維護難、叠代難……
UML 建模能力的學習：高效輔助産品經理工作，梳理需求和團隊協作、包括作爲評審材料後期可進行系統設計檢視，很值得研究運用，但不是都要學；
再比如産品設計由靜态到動态，框架的各個模塊之間如何進行交互設計關聯；頁面信息結構怎麽收集并合理展示…… ..
後續我也會慢慢整理總結、輸出。
最後，我們還可以問自己一個問題，從程序員角度，逆向考慮下，程序員拿到一個需求，都是怎麽拆解并實現的？
或許你會知道，你設計的功能是不是相對完美的。
本文由 @凱拉 Kella 原創發布于人人都是産品經理，未經作者許可，禁止轉載。
題圖來自 Unsplash，基于 CC0 協議。
