有很多工作1-5年的産品，在設計系統或平台産品時，往往束手無策，甚至需求不清晰、場景遺漏、流程不通順等問題。作者結合自己的工作經驗，抽象出一套通用産品從0到1的搭建方法論，适用于大多數行業。

文章篇幅有限，本文不涉及市場、競品分析相關的内容和方法。

（文章用到的截圖是在日常工作、學習中設計的，已做簡化和模糊等處理，僅作為參考）

一、關于業務背景（用戶需要什麼，為什麼做這件事）

軟件産品是滿足客戶（用戶）訴求的一個方案，它可以是一個小工具，也可以是一個系統、一個平台。因此在我們設計系統時，一定要摒棄手拿錘子看到的都是釘子的思維，第一步就是要先理解業務。

“業務理解”是指明白客戶（用戶）需要什麼。對業務理解往往是刨根問底，通過5W1H的方式來界定客戶想要什麼，但我們無法這麼精細化的思考，那麼最簡單的方式就是“誰 在什麼場景下 訴求是什麼”，最後轉化成系統需求。比如倉庫人員集中對訂單進行發貨，後台隻能一單一單的操作，因此希望增加批量發貨的功能，那麼需求是按訂單号進行批量物流信息的錄入并導入到發貨系統。

第二步是确認我們為什麼要做這件事情，這件事情是否可以真正的服務客戶、為業務帶來增長等等。比如在SaaS産品開發中，業務方需要在标準的下單流程内，增加用戶的電子簽名功能，其實這個功能場景很少，不适合做為标準流程。當考慮到客戶項目給業績帶來增長的情況下，我們将電子簽名作為可配置的選項，支持了項目開展。

二、關于目标設定（給産品設定目标）

設定産品的目标，是讓我們聚焦在如何實現目标的問題上，再對問題拆解和方案的制定。另外對目标的設定會讓我們重新審視這件事的價值所在，是否和公司、部門規劃的方向一緻。目标最好是可以量化的，比如是對商城的GMV進行提升10%，我們再結合GMV=UV*客單價*轉化率，進一步來獲取新客戶或提高老用戶的留存等做法，再結合數據反饋的結果，對目标達成、做法進行分析。

三、關于産品設計（6步實現産品的搭建）

确定背景、目标後，我們開始來設計一款可以輔助目标達成的産品，這裡會涉及到角色用例分析、流程、系統架構、功能與需求拆解、信息架構、原型繪制與說明這6步。

1. 角色用例

産品一定是服務客戶（用戶）的，那麼在設計一款産品時，我們首先是對産品涉及到的各類角色進行分析，弄清楚這些參與方使用産品的主要内容，這就是角色用例分析。好處一是在設計系統時可以明白功能和邊界是什麼；好處二是抽象出的用例，有助于産研人員對業務更加清晰理解。比如商家入駐平台進行賣貨，大的參與方有：平台、商家、用戶。MVP版本的用例如下圖所示：

可以看出上圖的用例顆粒度比較大，隻是一個大概的框架，還無法支持工作的開展，那麼在實際的工作中我們可以進一步的細化，比如商家入駐的用例：

通過細化後的用例可以看出作為商家，他的主要工作内容是簽訂協議、提交資料、繳費；作為平台入駐管理人員，他的主要工作是審核商家的資料信息；作為平台财務人員，他的主要工作是審核财務信息和繳費信息。通過這些調研，我們可以知道給商家，有提交資料的入口，給平台人員有審核資料信息的入口，并可以查看到是誰提交的。

角色用例一定是我們在客戶（用戶）調研後的基礎上繪制的，此時我們已經知道他們每個人想要的功能是什麼，接下來結合業務來梳理具體的流程。

提示：實際工作中通過腦圖就可以完成角色用例的工作，不用糾結于形式。

2. 流程

流程是為達到某個結果，進行的一系列動作，我們可以分為單線程的流程、多部門之間的處理流程。在繪制多系統的流程時，我們可以先把大概的信息流、資金流、物流做出，然後再補充具體的細節，比如平台售賣自營商品的流程：

對于産品設計者而言，我們需要先了解業務流程，然後再繪制出系統流程，其中系統流程更加細化，裡面會增加更多的判斷來輔助完善系統。業務流程是指具體的角色需要做什麼事情，和各個角色之間的上下遊關系；系統路程是指角色所在哪個系統，系統需要做什麼事情，以及系統實現的邏輯。比如更新移動端狀态，是無法在業務流程進行提現的。

為了更好的對比業務流程和系統流程，通過貨到付款進行說明，用戶進入某款購物APP-選擇商品-填寫收貨地址并下單-快遞送貨到家-用戶收貨并付款（妥投）。

貨到付款業務流程為：

貨到付款系統流程為：

提示：産品不僅僅有正向流程，還有逆向流程和異常流程，形成閉環的流程才是完整的。

3. 系統架構

在梳理完角色用例和流程後，我們對整個系統的架構已經有了比較清晰的認識，可以規劃出需要做哪些功能，以及和現有平台能力的對接。系統架構搭建的關鍵是明白客戶（用戶）系統、支撐系統的差别，客戶系統是指客戶操作的系統，支撐系統是滿足客戶操作的底層功能。

下圖是對B2B電商平台的完整架構圖：

任何系統的建設絕非一朝一夕就可完成，那麼在系統架構的梳理過程中，可以加入對規劃的功能點。下圖是在搭建cms系統組建的架構圖，優先上線圖文組建與營銷組建等功能，未來增加素材庫和更多的個性化組件：

提示：系統架構非常考驗從業者的對行業的積累，對業務的思考要先于現有需求。

4. 功能與需求拆解

分析完系統架構後，我們就可以對自己負責的模塊進行功能拆分，最終用表格或腦圖的形式來呈現，當然用表格的方式呈現是最好的，可以在具體的需求後面增加完成進度、負責的産品人、時間等信息。

下圖是以腦圖的形式展示訂單系統前、後端的功能與需求：

提示：前、後端産品經理思考的差異點在前端重交互，可替代性強，後端産品經理重邏輯，需要大量的時間進行積累。

5. 信息架構

系統的有效運行離不開對數據的應用，那麼在實際業務的開展過程中，我們需要對數據進行記錄，那麼哪些數據是關鍵數據，需要根據實際業務來定。比如我們在某APP上注冊/登錄商城，相應的商城會記錄我們的注冊信息，如手機号、賬戶号、賬戶名、注冊方式、注冊時間等等，在下次登錄時直接調取這些信息。

另外通過信息架構，還可以輔助開發建庫建表，下圖是訂單表的内容：

提示：梳理信息架構時，是對現有業務運行的表單進行收集，當你負責一款從未涉及過的産品時，具體需要在系統展示哪些信息，可以對現有業務的表單進行搜集，并彙總羅列。

6. 原型與說明

原型設計是産品設計工作的最後一步，也是最直觀的看到産品的界面、交互規則等。在與業務、技術評審時，原型圖是必不可少的，那麼什麼樣的原型算是好的原型呢？

我認為好的原型有2點，第一點，頁面全面。完整的原型包含不同狀态的數據展示、異常狀态的數據展示，比如支付接口返回成功、失敗的結果，在前、後端如何展示；頁面停留超時等如何展示。

第二點，規則清楚。清楚明白的定義出輸入框限制字符、異常提示、交互樣式等，可以方便開發、測試的工作。下圖是C端、B端原型案例：

提示：PRD文檔是否撰寫根據公司情況而定，其中自研産品團隊考慮到快速叠代可以不需要PRD文檔，在原型上說明并做好留存即可。

綜上，産品設計的過程中會經曆角色用例、流程、系統架構、功能架構、功能與需求拆解、信息架構、原型與說明，這6步是把業務不斷抽象為系統應用，但在實際的工作中時間成本等問題，産品人可以直接進行用例、流程、功能與需求、原型的設計。

四、結果

系統成功上線後，代表着下一次叠代工作的開始，因此我們在上線前需要進行數據的埋點，以此來統計上線後的數據結果。再根據數據反饋指導下一次的叠代方向。具體需要搜集哪些關鍵數據，是根據業務而定。

下圖是分享活動上線後的每日結果：

當涉及到用戶體量大，需要進行AB測試後，我們需要進行數據對照分析，找到最優的方案再進行全部用戶的版本叠代。

下圖是不同推薦策略的結果：

以上是我個人淺見，希望能做到抛磚引玉的效果，歡迎大家在評論區私信我。最後送大家一句話：面對複雜的系統或事物，不用害怕和擔心，在一次次叠代、完成中，我們可以做的更好。

本文由 @産品汪的自我救贖 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議

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

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部