一個(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ì)上,，我們討論過(guò)一個(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)理來(lái)說(shuō),，就會(huì)變得不太容易。

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

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

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

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

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

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

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

今天,，我就嘗試來(lái)聊聊,，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)做過(guò)了,。

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

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

在這樣的操作下,。大概率在需求評(píng)審環(huán)節(jié)、開發(fā)環(huán)節(jié)甚至上線后,，他會(huì)遇到以下情況：細(xì)節(jié)遺漏,、忘記協(xié)同其他部門進(jìn)場(chǎng)、遇到無(wú)法解決的技術(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ì),，讓大家少走一些彎路呢,？

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

接下來(lái),，我們按步驟講解下：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

嚴(yán)謹(jǐn)來(lái)說(shuō)流程圖更多是單一主線隨時(shí)間變化的呈現(xiàn),，但是這個(gè)圖表中，其實(shí)會(huì)包含更多個(gè)流程圖,，例如上邊說(shuō)的信息流,、資金流、實(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ù)?1 步完成之后，我們就會(huì)得到不同用戶一個(gè)個(gè)明確的需求點(diǎn),。

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

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

其中,，事件 X= 用戶 ** 通過(guò) ** 做 **

一個(gè)事件，可以是一個(gè)頁(yè)面的按鈕點(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)譯,，接下來(lái)我們需要收斂一下功能點(diǎn)。

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

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

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

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

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

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

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

詳細(xì)設(shè)計(jì)的對(duì)象,，可能是頁(yè)面的交互,、一個(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)的,。

本文由 @減形簡(jiǎn)遠(yuǎn) 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可,，

題圖來(lái)自 Unsplash,，基于 CC0 協(xié)議

查看原文