有很多工作1-5年的產(chǎn)品，在設(shè)計(jì)系統(tǒng)或平臺產(chǎn)品時，往往束手無策，甚至需求不清晰、場景遺漏、流程不通順等問題。作者結(jié)合自己的工作經(jīng)驗(yàn)，抽象出一套通用產(chǎn)品從0到1的搭建方法論，適用于大多數(shù)行業(yè)。

文章篇幅有限，本文不涉及市場、競品分析相關(guān)的內(nèi)容和方法。

（文章用到的截圖是在日常工作、學(xué)習(xí)中設(shè)計(jì)的，已做簡化和模糊等處理，僅作為參考）

一、關(guān)于業(yè)務(wù)背景（用戶需要什么，為什么做這件事）

軟件產(chǎn)品是滿足客戶（用戶）訴求的一個方案，它可以是一個小工具，也可以是一個系統(tǒng)、一個平臺。因此在我們設(shè)計(jì)系統(tǒng)時，一定要摒棄手拿錘子看到的都是釘子的思維，第一步就是要先理解業(yè)務(wù)。

“業(yè)務(wù)理解”是指明白客戶（用戶）需要什么。對業(yè)務(wù)理解往往是刨根問底，通過5W1H的方式來界定客戶想要什么，但我們無法這么精細(xì)化的思考，那么最簡單的方式就是“誰+在什么場景下+訴求是什么”，最后轉(zhuǎn)化成系統(tǒng)需求。比如倉庫人員集中對訂單進(jìn)行發(fā)貨，后臺只能一單一單的操作，因此希望增加批量發(fā)貨的功能，那么需求是按訂單號進(jìn)行批量物流信息的錄入并導(dǎo)入到發(fā)貨系統(tǒng)。

第二步是確認(rèn)我們?yōu)槭裁匆鲞@件事情，這件事情是否可以真正的服務(wù)客戶、為業(yè)務(wù)帶來增長等等。比如在SaaS產(chǎn)品開發(fā)中，業(yè)務(wù)方需要在標(biāo)準(zhǔn)的下單流程內(nèi)，增加用戶的電子簽名功能，其實(shí)這個功能場景很少，不適合做為標(biāo)準(zhǔn)流程。當(dāng)考慮到客戶項(xiàng)目給業(yè)績帶來增長的情況下，我們將電子簽名作為可配置的選項(xiàng)，支持了項(xiàng)目開展。

二、關(guān)于目標(biāo)設(shè)定（給產(chǎn)品設(shè)定目標(biāo)）

設(shè)定產(chǎn)品的目標(biāo)，是讓我們聚焦在如何實(shí)現(xiàn)目標(biāo)的問題上，再對問題拆解和方案的制定。另外對目標(biāo)的設(shè)定會讓我們重新審視這件事的價值所在，是否和公司、部門規(guī)劃的方向一致。目標(biāo)最好是可以量化的，比如是對商城的GMV進(jìn)行提升10%，我們再結(jié)合GMV=UV*客單價*轉(zhuǎn)化率，進(jìn)一步來獲取新客戶或提高老用戶的留存等做法，再結(jié)合數(shù)據(jù)反饋的結(jié)果，對目標(biāo)達(dá)成、做法進(jìn)行分析。

三、關(guān)于產(chǎn)品設(shè)計(jì)（6步實(shí)現(xiàn)產(chǎn)品的搭建）

確定背景、目標(biāo)后，我們開始來設(shè)計(jì)一款可以輔助目標(biāo)達(dá)成的產(chǎn)品，這里會涉及到角色用例分析、流程、系統(tǒng)架構(gòu)、功能與需求拆解、信息架構(gòu)、原型繪制與說明這6步。

1. 角色用例

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

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

通過細(xì)化后的用例可以看出作為商家，他的主要工作內(nèi)容是簽訂協(xié)議、提交資料、繳費(fèi)；作為平臺入駐管理人員，他的主要工作是審核商家的資料信息；作為平臺財(cái)務(wù)人員，他的主要工作是審核財(cái)務(wù)信息和繳費(fèi)信息。通過這些調(diào)研，我們可以知道給商家，有提交資料的入口，給平臺人員有審核資料信息的入口，并可以查看到是誰提交的。

角色用例一定是我們在客戶（用戶）調(diào)研后的基礎(chǔ)上繪制的，此時我們已經(jīng)知道他們每個人想要的功能是什么，接下來結(jié)合業(yè)務(wù)來梳理具體的流程。

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

2. 流程

流程是為達(dá)到某個結(jié)果，進(jìn)行的一系列動作，我們可以分為單線程的流程、多部門之間的處理流程。在繪制多系統(tǒng)的流程時，我們可以先把大概的信息流、資金流、物流做出，然后再補(bǔ)充具體的細(xì)節(jié)，比如平臺售賣自營商品的流程：

對于產(chǎn)品設(shè)計(jì)者而言，我們需要先了解業(yè)務(wù)流程，然后再繪制出系統(tǒng)流程，其中系統(tǒng)流程更加細(xì)化，里面會增加更多的判斷來輔助完善系統(tǒng)。業(yè)務(wù)流程是指具體的角色需要做什么事情，和各個角色之間的上下游關(guān)系；系統(tǒng)路程是指角色所在哪個系統(tǒng)，系統(tǒng)需要做什么事情，以及系統(tǒng)實(shí)現(xiàn)的邏輯。比如更新移動端狀態(tài)，是無法在業(yè)務(wù)流程進(jìn)行提現(xiàn)的。

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

貨到付款業(yè)務(wù)流程為：

貨到付款系統(tǒng)流程為：

提示：產(chǎn)品不僅僅有正向流程，還有逆向流程和異常流程，形成閉環(huán)的流程才是完整的。

3. 系統(tǒng)架構(gòu)

在梳理完角色用例和流程后，我們對整個系統(tǒng)的架構(gòu)已經(jīng)有了比較清晰的認(rèn)識，可以規(guī)劃出需要做哪些功能，以及和現(xiàn)有平臺能力的對接。系統(tǒng)架構(gòu)搭建的關(guān)鍵是明白客戶（用戶）系統(tǒng)、支撐系統(tǒng)的差別，客戶系統(tǒng)是指客戶操作的系統(tǒng)，支撐系統(tǒng)是滿足客戶操作的底層功能。

下圖是對B2B電商平臺的完整架構(gòu)圖：

任何系統(tǒng)的建設(shè)絕非一朝一夕就可完成，那么在系統(tǒng)架構(gòu)的梳理過程中，可以加入對規(guī)劃的功能點(diǎn)。下圖是在搭建cms系統(tǒng)組建的架構(gòu)圖，優(yōu)先上線圖文組建與營銷組建等功能，未來增加素材庫和更多的個性化組件：

提示：系統(tǒng)架構(gòu)非常考驗(yàn)從業(yè)者的對行業(yè)的積累，對業(yè)務(wù)的思考要先于現(xiàn)有需求。

4. 功能與需求拆解

分析完系統(tǒng)架構(gòu)后，我們就可以對自己負(fù)責(zé)的模塊進(jìn)行功能拆分，最終用表格或腦圖的形式來呈現(xiàn)，當(dāng)然用表格的方式呈現(xiàn)是最好的，可以在具體的需求后面增加完成進(jìn)度、負(fù)責(zé)的產(chǎn)品人、時間等信息。

下圖是以腦圖的形式展示訂單系統(tǒng)前、后端的功能與需求：

提示：前、后端產(chǎn)品經(jīng)理思考的差異點(diǎn)在前端重交互，可替代性強(qiáng)，后端產(chǎn)品經(jīng)理重邏輯，需要大量的時間進(jìn)行積累。

5. 信息架構(gòu)

系統(tǒng)的有效運(yùn)行離不開對數(shù)據(jù)的應(yīng)用，那么在實(shí)際業(yè)務(wù)的開展過程中，我們需要對數(shù)據(jù)進(jìn)行記錄，那么哪些數(shù)據(jù)是關(guān)鍵數(shù)據(jù)，需要根據(jù)實(shí)際業(yè)務(wù)來定。比如我們在某APP上注冊/登錄商城，相應(yīng)的商城會記錄我們的注冊信息，如手機(jī)號、賬戶號、賬戶名、注冊方式、注冊時間等等，在下次登錄時直接調(diào)取這些信息。

另外通過信息架構(gòu)，還可以輔助開發(fā)建庫建表，下圖是訂單表的內(nèi)容：

提示：梳理信息架構(gòu)時，是對現(xiàn)有業(yè)務(wù)運(yùn)行的表單進(jìn)行收集，當(dāng)你負(fù)責(zé)一款從未涉及過的產(chǎn)品時，具體需要在系統(tǒng)展示哪些信息，可以對現(xiàn)有業(yè)務(wù)的表單進(jìn)行搜集，并匯總羅列。

6. 原型與說明

原型設(shè)計(jì)是產(chǎn)品設(shè)計(jì)工作的最后一步，也是最直觀的看到產(chǎn)品的界面、交互規(guī)則等。在與業(yè)務(wù)、技術(shù)評審時，原型圖是必不可少的，那么什么樣的原型算是好的原型呢？

我認(rèn)為好的原型有2點(diǎn)，第一點(diǎn)，頁面全面。完整的原型包含不同狀態(tài)的數(shù)據(jù)展示、異常狀態(tài)的數(shù)據(jù)展示，比如支付接口返回成功、失敗的結(jié)果，在前、后端如何展示；頁面停留超時等如何展示。

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

提示：PRD文檔是否撰寫根據(jù)公司情況而定，其中自研產(chǎn)品團(tuán)隊(duì)考慮到快速迭代可以不需要PRD文檔，在原型上說明并做好留存即可。

綜上，產(chǎn)品設(shè)計(jì)的過程中會經(jīng)歷角色用例、流程、系統(tǒng)架構(gòu)、功能架構(gòu)、功能與需求拆解、信息架構(gòu)、原型與說明，這6步是把業(yè)務(wù)不斷抽象為系統(tǒng)應(yīng)用，但在實(shí)際的工作中時間成本等問題，產(chǎn)品人可以直接進(jìn)行用例、流程、功能與需求、原型的設(shè)計(jì)。

四、結(jié)果

系統(tǒng)成功上線后，代表著下一次迭代工作的開始，因此我們在上線前需要進(jìn)行數(shù)據(jù)的埋點(diǎn)，以此來統(tǒng)計(jì)上線后的數(shù)據(jù)結(jié)果。再根據(jù)數(shù)據(jù)反饋指導(dǎo)下一次的迭代方向。具體需要搜集哪些關(guān)鍵數(shù)據(jù)，是根據(jù)業(yè)務(wù)而定。

下圖是分享活動上線后的每日結(jié)果：

當(dāng)涉及到用戶體量大，需要進(jìn)行AB測試后，我們需要進(jìn)行數(shù)據(jù)對照分析，找到最優(yōu)的方案再進(jìn)行全部用戶的版本迭代。

下圖是不同推薦策略的結(jié)果：

以上是我個人淺見，希望能做到拋磚引玉的效果，歡迎大家在評論區(qū)私信我。最后送大家一句話：面對復(fù)雜的系統(tǒng)或事物，不用害怕和擔(dān)心，在一次次迭代、完成中，我們可以做的更好。