一個(gè)B端產(chǎn)品經(jīng)理自身產(chǎn)品設(shè)計(jì)的質(zhì)量和效率，直接決定了項(xiàng)目的結(jié)果與效率。但很多人一開始并沒有這樣的經(jīng)驗(yàn)，缺乏相對(duì)統(tǒng)一的思考框架及能力體系，難以快速輸出產(chǎn)品設(shè)計(jì)。作者結(jié)合自身經(jīng)驗(yàn)，總結(jié)了B端產(chǎn)品設(shè)計(jì)四步法，幫助你少走一些彎路。

之前在公司《產(chǎn)品學(xué)習(xí)小組》會(huì)上，我們討論過一個(gè)話題，就是產(chǎn)品經(jīng)理有沒有相對(duì)統(tǒng)一的思考框架和能力評(píng)估體系。

結(jié)果，各個(gè)方向的產(chǎn)品負(fù)責(zé)人都有一個(gè)共識(shí)：就是技術(shù)的培養(yǎng)和評(píng)判標(biāo)準(zhǔn)，相對(duì)成體系一些，但是對(duì)產(chǎn)品經(jīng)理來說，就會(huì)變得不太容易。

一方面是因?yàn)楫a(chǎn)品細(xì)分的方向比較多，另一方面產(chǎn)品跟業(yè)務(wù)走得近，相對(duì)屬性也會(huì)離散一些。所以就導(dǎo)致了產(chǎn)品的成長環(huán)境和路徑都會(huì)帶有非常強(qiáng)的個(gè)人色彩。

不過最終，產(chǎn)品出身的BOSS還是傳授給我們了一套他沉淀方法論——“萬能產(chǎn)品五步法”：① 用戶 – ② 需求 – ③ 場(chǎng)景/路徑 – ④ 痛點(diǎn)/訴求點(diǎn) : ⑤ 解法

算是在宏觀上，把產(chǎn)品分析的過程有了一個(gè)框架的抽象。

經(jīng)過學(xué)習(xí)演練，我也深受其益，一直在使用。

不過這個(gè)模型，我發(fā)現(xiàn)有一定的使用范圍。那就是比較適合于用戶比較確定且相對(duì)獨(dú)立的，C端適用性更強(qiáng)，或B端某一個(gè)特定用戶在限定場(chǎng)景內(nèi)。

那如果是一個(gè)完整的B端產(chǎn)品，涉及到非常多用戶角色參與并相互協(xié)作，那就會(huì)需要另外一些方法來補(bǔ)充。

我覺得本質(zhì)上，C端產(chǎn)品操作或B端在特定場(chǎng)景操作，是一個(gè)使用需求；但對(duì)一個(gè)完整的B端產(chǎn)品，各個(gè)用戶角色的使用更像是一個(gè)過程，他們共同協(xié)作操作完成的那個(gè)結(jié)果，才是B端產(chǎn)品本身的需求達(dá)成。

今天，我就嘗試來聊聊，B端產(chǎn)品設(shè)計(jì)的思考框架。

PS：以下文章內(nèi)容，我們重點(diǎn)討論“產(chǎn)品設(shè)計(jì)”環(huán)節(jié)的一些方法。我們假定產(chǎn)品設(shè)計(jì)對(duì)應(yīng)的需求價(jià)值分析沒問題，產(chǎn)品決策已經(jīng)做過了。

不知道，大家在日常工作中會(huì)不會(huì)遇到這樣一個(gè)現(xiàn)象？

一些人接到一個(gè)需求后，馬上就會(huì)開始進(jìn)入到功能設(shè)計(jì)：流程圖畫系統(tǒng)流程，xmind列功能清單，甚至直接axure開始畫交互頁面。

在這樣的操作下。大概率在需求評(píng)審環(huán)節(jié)、開發(fā)環(huán)節(jié)甚至上線后，他會(huì)遇到以下情況：細(xì)節(jié)遺漏、忘記協(xié)同其他部門進(jìn)場(chǎng)、遇到無法解決的技術(shù)/資源卡點(diǎn)，最終導(dǎo)致項(xiàng)目不斷返工、延期，甚至停工。越大規(guī)模項(xiàng)目，問題會(huì)越嚴(yán)重。

在我的實(shí)際工作中，我也遇到很多以上這樣的情況。到最終，可能一個(gè)人需要很多項(xiàng)目的血淚經(jīng)驗(yàn)，才能慢慢做得成熟一些。

B端產(chǎn)品的基本面，是講究產(chǎn)品可用性的，各個(gè)鏈條環(huán)節(jié)的問題，都會(huì)影響最終結(jié)果。

這也是B端產(chǎn)品要求重邏輯和專業(yè)性的原因。

所以，一個(gè)B端產(chǎn)品經(jīng)理自身產(chǎn)品設(shè)計(jì)的質(zhì)量和效率，直接決定了項(xiàng)目的結(jié)果與效率。

那么，在B端產(chǎn)品設(shè)計(jì)中，有沒有一些像產(chǎn)品五步法一樣的方法，能指引產(chǎn)品設(shè)計(jì)，讓大家少走一些彎路呢？

過去一段時(shí)間內(nèi)，我自己在部門內(nèi)也做一些論證，也提煉了一套我認(rèn)為比較有效的方法，我稱之為“B端產(chǎn)品設(shè)計(jì)四步法”。

接下來，我們按步驟講解下：

一、拆需求（用戶->場(chǎng)景->需求）

一個(gè)最小的子需求，應(yīng)有3個(gè)要素組成：用戶**在**場(chǎng)景下的**需求。

那一個(gè)完整的大需求，就需要N多個(gè)子需求所組成。

但是，一個(gè)人如果想要直接面向子需求顆粒度去分析，對(duì)于大項(xiàng)目復(fù)雜項(xiàng)目，基本是不可能完成的任務(wù)。

在這里，我建議大家使用「角色×流程」象限圖表法。

按照這個(gè)框架，我們需要依次代入每個(gè)用戶的視角，來窮舉不同用戶在不同場(chǎng)景下的需求點(diǎn)。

PS：場(chǎng)景1、2、3、4，盡量按照信息流的時(shí)間線順序（大概率是可以的）。

注意，在這個(gè)環(huán)節(jié)大家不要考慮任何系統(tǒng)功能和實(shí)現(xiàn)，就用白話來描述需求點(diǎn)。因?yàn)楹筮呌衅渌襟E來做轉(zhuǎn)化的事情。

按照以上的原則，把各個(gè)象限表格填寫完成。

完成第一遍之后，還需要繼續(xù)第二遍，第三遍的review。

在后邊的每一遍檢查中，可以嘗試按不同流程（例如場(chǎng)景中包含的信息流、資金流、實(shí)物流等等）、按不同用戶（例如按照用戶生命周期時(shí)間線）來交叉比對(duì)信息。

串聯(lián)時(shí)候，一定要做到保證邏輯（不是系統(tǒng)邏輯，而是自然邏輯）自洽。

讀到這里，有人可能會(huì)問：這個(gè)象限圖表，看起來不就是多個(gè)用戶在驅(qū)動(dòng)一個(gè)流程場(chǎng)景變化，能不能就是一個(gè)流程圖來呈現(xiàn)呢？

大部分場(chǎng)景下，是不能等同的。

嚴(yán)謹(jǐn)來說流程圖更多是單一主線隨時(shí)間變化的呈現(xiàn)，但是這個(gè)圖表中，其實(shí)會(huì)包含更多個(gè)流程圖，例如上邊說的信息流、資金流、實(shí)物流等等。

另外，還有一些前置準(zhǔn)備信息、后置信息，都跟流程沒太多強(qiáng)耦合關(guān)系。畫成流程圖，特別容易遺忘這些需求點(diǎn)。

第1步「拆需求」，是產(chǎn)品設(shè)計(jì)最重要的一環(huán)，這個(gè)環(huán)節(jié)有偏差，后邊幾個(gè)環(huán)節(jié)都要跟著重新返工，會(huì)影響整體項(xiàng)目效率。所以，大家一定要在這個(gè)環(huán)節(jié)多花一些功夫。

二、需求轉(zhuǎn)譯事件

當(dāng)?shù)?步完成之后，我們就會(huì)得到不同用戶一個(gè)個(gè)明確的需求點(diǎn)。

那么第2步，我們就側(cè)重于需求怎么達(dá)成，這里給一個(gè)公式。

一個(gè)需求的結(jié)果 = 事件1+事件2+事件3+……

其中，事件X=用戶**通過**做**

一個(gè)事件，可以是一個(gè)頁面的按鈕點(diǎn)擊，也可能是一個(gè)邏輯的執(zhí)行，也可能是一個(gè)sop的執(zhí)行等等。

注意，不同事件之間，可能有先后順序或依賴關(guān)系。

在這一步中，因?yàn)槭鞘录暯?，就要關(guān)心能不能達(dá)成的問題，尤其是一些核心卡點(diǎn)?？茨男┦录耐瓿?，依賴外部、依賴資源、依賴技術(shù)可行性等等。

理論上，在這一步，就需要大面上確定各個(gè)事件的可行性。如果是關(guān)鍵環(huán)節(jié)不能達(dá)成，那就要尋找替代方案，如果找不到，那基本上也就不能繼續(xù)往下走了。

不少人，就是在這個(gè)環(huán)節(jié)內(nèi)，沒有對(duì)關(guān)鍵環(huán)節(jié)做論證，導(dǎo)致詳細(xì)方案出完才發(fā)現(xiàn)有卡點(diǎn)，需求做不了。

我自己的經(jīng)驗(yàn)，第2步完成之后，才能去做項(xiàng)目立項(xiàng)。

三、事件模塊化聚合

第1步是按照用戶視角。

第2步也是按照用戶視角和功能視角。

完成前兩步之后，所有需求都被事件轉(zhuǎn)譯，接下來我們需要收斂一下功能點(diǎn)。

大家發(fā)現(xiàn)一個(gè)事件的元素組成是：用戶**通過**做**，這里面通過“**”這個(gè)對(duì)象，更多就是領(lǐng)域模塊。例如交易訂單、促銷、支付、清結(jié)算、業(yè)財(cái)、物流等等，當(dāng)然這個(gè)模塊顆粒度可以更粗也可以更細(xì)，大家根據(jù)實(shí)際情況來決定即可。

這個(gè)步驟的主要作用，就是將離散的功能點(diǎn)所需要的承載體，聚類聚合。

因?yàn)樾枨笞罱K落地的最細(xì)劃分會(huì)到模塊，而模塊一般情況其實(shí)跟崗位職責(zé)是對(duì)應(yīng)起來的。例如A同學(xué)考慮A模塊的設(shè)計(jì)，B同學(xué)考慮B模塊的設(shè)計(jì)。

另外，功能點(diǎn)聚類之后，也能一次性get到大需求內(nèi)所有對(duì)單模塊的影響點(diǎn)，便于一次性分析，省得來回倒騰。

四、詳細(xì)設(shè)計(jì)

完成以上3個(gè)步驟之后，其實(shí)產(chǎn)品設(shè)計(jì)的主要工作基本就完成80%。

剩余的，就是如何落地到具體細(xì)節(jié)設(shè)計(jì)和描述。要不就是新增一個(gè)能力，要不就是改動(dòng)一個(gè)能力。

詳細(xì)設(shè)計(jì)的對(duì)象，可能是頁面的交互、一個(gè)自動(dòng)腳本、系統(tǒng)校驗(yàn)邏輯、線下SOP等等。

產(chǎn)品設(shè)計(jì)一定要結(jié)合現(xiàn)在系統(tǒng)的現(xiàn)況。一方面是現(xiàn)在系統(tǒng)的邏輯，另一方面是新能力疊加已有能力的成本。

這個(gè)環(huán)節(jié)會(huì)用到專業(yè)知識(shí)和設(shè)計(jì)經(jīng)驗(yàn)，每個(gè)人情況不同，我默認(rèn)大家這個(gè)環(huán)節(jié)已經(jīng)比較熟練，不再贅述。

不管如何，如果前面幾個(gè)步驟做得比較扎實(shí)，這個(gè)第4步我覺得問題不大。因?yàn)榈竭@個(gè)步驟，技術(shù)已經(jīng)完全跟產(chǎn)品站在同一個(gè)起跑線了，會(huì)“補(bǔ)位”或“掰扯”產(chǎn)品功能如何實(shí)現(xiàn)的。