從需求到功能,B端產品設計四步法

6 評論 17476 瀏覽 179 收藏 12 分鐘

一個B端產品經理自身產品設計的質量和效率,直接決定了項目的結果與效率。但很多人一開始并沒有這樣的經驗,缺乏相對統一的思考框架及能力體系,難以快速輸出產品設計。作者結合自身經驗,總結了B端產品設計四步法,幫助你少走一些彎路。

之前在公司《產品學習小組》會上,我們討論過一個話題,就是產品經理有沒有相對統一的思考框架和能力評估體系。

結果,各個方向的產品負責人都有一個共識:就是技術的培養和評判標準,相對成體系一些,但是對產品經理來說,就會變得不太容易。

一方面是因為產品細分的方向比較多,另一方面產品跟業務走得近,相對屬性也會離散一些。所以就導致了產品的成長環境和路徑都會帶有非常強的個人色彩。

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

算是在宏觀上,把產品分析的過程有了一個框架的抽象。

經過學習演練,我也深受其益,一直在使用。

不過這個模型,我發現有一定的使用范圍。那就是比較適合于用戶比較確定且相對獨立的,C端適用性更強,或B端某一個特定用戶在限定場景內。

那如果是一個完整的B端產品,涉及到非常多用戶角色參與并相互協作,那就會需要另外一些方法來補充。

我覺得本質上,C端產品操作或B端在特定場景操作,是一個使用需求;但對一個完整的B端產品,各個用戶角色的使用更像是一個過程,他們共同協作操作完成的那個結果,才是B端產品本身的需求達成。

今天,我就嘗試來聊聊,B端產品設計的思考框架。

PS:以下文章內容,我們重點討論“產品設計”環節的一些方法。我們假定產品設計對應的需求價值分析沒問題,產品決策已經做過了。

不知道,大家在日常工作中會不會遇到這樣一個現象?

一些人接到一個需求后,馬上就會開始進入到功能設計:流程圖畫系統流程,xmind列功能清單,甚至直接axure開始畫交互頁面。

在這樣的操作下。大概率在需求評審環節、開發環節甚至上線后,他會遇到以下情況:細節遺漏、忘記協同其他部門進場、遇到無法解決的技術/資源卡點,最終導致項目不斷返工、延期,甚至停工。越大規模項目,問題會越嚴重。

在我的實際工作中,我也遇到很多以上這樣的情況。到最終,可能一個人需要很多項目的血淚經驗,才能慢慢做得成熟一些。

B端產品的基本面,是講究產品可用性的,各個鏈條環節的問題,都會影響最終結果。

這也是B端產品要求重邏輯和專業性的原因。

所以,一個B端產品經理自身產品設計的質量和效率,直接決定了項目的結果與效率。

那么,在B端產品設計中,有沒有一些像產品五步法一樣的方法,能指引產品設計,讓大家少走一些彎路呢?

過去一段時間內,我自己在部門內也做一些論證,也提煉了一套我認為比較有效的方法,我稱之為“B端產品設計四步法”。

接下來,我們按步驟講解下:

一、拆需求(用戶->場景->需求)

一個最小的子需求,應有3個要素組成:用戶**在**場景下的**需求。

那一個完整的大需求,就需要N多個子需求所組成。

但是,一個人如果想要直接面向子需求顆粒度去分析,對于大項目復雜項目,基本是不可能完成的任務。

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

按照這個框架,我們需要依次代入每個用戶的視角,來窮舉不同用戶在不同場景下的需求點。

PS:場景1、2、3、4,盡量按照信息流的時間線順序(大概率是可以的)。

注意,在這個環節大家不要考慮任何系統功能和實現,就用白話來描述需求點。因為后邊有其他步驟來做轉化的事情。

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

完成第一遍之后,還需要繼續第二遍,第三遍的review。

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

串聯時候,一定要做到保證邏輯(不是系統邏輯,而是自然邏輯)自洽。

讀到這里,有人可能會問:這個象限圖表,看起來不就是多個用戶在驅動一個流程場景變化,能不能就是一個流程圖來呈現呢?

大部分場景下,是不能等同的。

嚴謹來說流程圖更多是單一主線隨時間變化的呈現,但是這個圖表中,其實會包含更多個流程圖,例如上邊說的信息流、資金流、實物流等等。

另外,還有一些前置準備信息、后置信息,都跟流程沒太多強耦合關系。畫成流程圖,特別容易遺忘這些需求點。

第1步「拆需求」,是產品設計最重要的一環,這個環節有偏差,后邊幾個環節都要跟著重新返工,會影響整體項目效率。所以,大家一定要在這個環節多花一些功夫。

二、需求轉譯事件

當第1步完成之后,我們就會得到不同用戶一個個明確的需求點。

那么第2步,我們就側重于需求怎么達成,這里給一個公式。

一個需求的結果 = 事件1+事件2+事件3+……

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

一個事件,可以是一個頁面的按鈕點擊,也可能是一個邏輯的執行,也可能是一個sop的執行等等。

注意,不同事件之間,可能有先后順序或依賴關系。

在這一步中,因為是事件視角,就要關心能不能達成的問題,尤其是一些核心卡點??茨男┦录耐瓿?,依賴外部、依賴資源、依賴技術可行性等等。

理論上,在這一步,就需要大面上確定各個事件的可行性。如果是關鍵環節不能達成,那就要尋找替代方案,如果找不到,那基本上也就不能繼續往下走了。

不少人,就是在這個環節內,沒有對關鍵環節做論證,導致詳細方案出完才發現有卡點,需求做不了。

我自己的經驗,第2步完成之后,才能去做項目立項。

三、事件模塊化聚合

第1步是按照用戶視角。

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

完成前兩步之后,所有需求都被事件轉譯,接下來我們需要收斂一下功能點。

大家發現一個事件的元素組成是:用戶**通過**做**,這里面通過“**”這個對象,更多就是領域模塊。例如交易訂單、促銷、支付、清結算、業財、物流等等,當然這個模塊顆粒度可以更粗也可以更細,大家根據實際情況來決定即可。

這個步驟的主要作用,就是將離散的功能點所需要的承載體,聚類聚合。

因為需求最終落地的最細劃分會到模塊,而模塊一般情況其實跟崗位職責是對應起來的。例如A同學考慮A模塊的設計,B同學考慮B模塊的設計。

另外,功能點聚類之后,也能一次性get到大需求內所有對單模塊的影響點,便于一次性分析,省得來回倒騰。

四、詳細設計

完成以上3個步驟之后,其實產品設計的主要工作基本就完成80%。

剩余的,就是如何落地到具體細節設計和描述。要不就是新增一個能力,要不就是改動一個能力。

詳細設計的對象,可能是頁面的交互、一個自動腳本、系統校驗邏輯、線下SOP等等。

產品設計一定要結合現在系統的現況。一方面是現在系統的邏輯,另一方面是新能力疊加已有能力的成本。

這個環節會用到專業知識和設計經驗,每個人情況不同,我默認大家這個環節已經比較熟練,不再贅述。

不管如何,如果前面幾個步驟做得比較扎實,這個第4步我覺得問題不大。因為到這個步驟,技術已經完全跟產品站在同一個起跑線了,會“補位”或“掰扯”產品功能如何實現的。

本文由 @減形簡遠 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 太抽象了,有沒有案例解釋一下

    來自廣東 回復
  2. 沒有案例太抽象了

    來自上海 回復
    1. 是的

      來自江蘇 回復
  3. 能舉個小案例嗎

    來自上海 回復
  4. 如果有具體案例來分析的話就更直觀更好了

    來自江蘇 回復
    1. 是的,建議舉一下實踐過的小例子

      來自廣東 回復