本文將從目的、需求收集/整理、設計模塊、輸出原型這幾方面來完成B端產品調研方法論的講解。

寫本篇文章的目的：第一個目的是作者即將步入第一個三年，對以往的工作進行總結，準備進階突破；第二個目的就是與大家分享與討論。

我們都知道B端產品的設計最主要的是業務邏輯與錯綜復雜的業務流程，設計B端產品的時候要有清晰的思路，否則就像身處在迷宮之中，迷失了方向。

那么接下來我給大家講解一個梳理B端產品切實可行的方法，來幫助你們完成B端產品的設計。

下面我將從目的、需求收集/整理、設計模塊、輸出原型這幾方面來完成我的方法論講解：

第一步 明確目的

我把目的劃分為三個層次：

• 第一層屬業務層次，此層次目的為用信息化手段讓業務流程標準化，從而形成有效數據，拋棄紙質或獨立個體表格數據，形成部分可共享查看的數據；
• 第二層為管理目的，包括進一步改善不合理的流程，通過業務數據提取計算職工的部分PKI或通過系統約束職工的某種違規行為；
• 第三層為公司為了長遠發展而提出的一些戰略目的。

第一層和第二層的調研目標均為管理者和執行者，第一層偏向執行者，第二層偏向中層管理者，而第三層則需要和公司高層領導進行深入的溝通。

就我目前而言只修煉到了第二層，可通過系統幫助管理者完成一些業務流程的優化和提取KPI等目的，并不能駕馭第三層為產品注入公司的戰略靈魂。

明確目的建議在項目啟動會中完成，項目的相關負責人以及領導都會到場，此時明確目的是最佳時機，以免造成溝通障礙。調研目的時可從這幾個問題中展開：

1. 為什么要做此項目（做此項目的目的）？
2. 希望此項目解決什么問題？
3. 期望達到什么樣的效果？

此外項目立項中我們還需要明確項目的范圍和先關干系人。

第二步 需求調研/整理

需求調研對于初級者來說是個坑，常常是拿到項目之后就去組織召開調研會議，對于一頭霧水的初級者不知道具體調研什么，也就成了調研對象說什么然后記什么，會議結束后發現這些需求根本連不上也無法整理。

所以調研一定要講究方法去分步調研，文章開頭說B端產品邏輯流程最重要，所以我們要先搞清楚業務流程與邏輯。調研業務流程的方法可是走訪部門也可是會議的形式，無論是哪種形式，都需注意一點，要循序漸進的調研，什么意思呢？就是業務流程是分層級的，注意每次調研所處的層級。

在設計流程的時候要注意這幾個問題：

1. 有沒有流程顛倒的情況？
2. 每個流程點是否有分流程?
3. 每個流程是否是必須存在的?
4. 此流程的上下游是什么?

1. 明確流程

第一步

調研總體流程的時候就不要去糾結細節，調研時要首先聲明此次調研的目的，如果有人過度展開時要即時提醒，不要被他的思路帶入細節中去，否則你會有種盲人摸象的感覺。

比如以采購為例，那么我們首先要了解采購的大致流程：

這張圖表達了采購流程的各個階段，每個階段需要做什么事情，具體由哪個部門去做。

如果第一步能做到把這張圖調研清楚，那么此次調研就算是成功了，這里每個節點都可進行展開，但不要在此調研層級展開。

第二步

我們要繼續進行深入調研，這步我們需要明確某個階段的流程是怎樣的，此時也需要繼續注意層級的概念，此步驟要有種只見森林不見樹的感覺，知道這是一片森林，但是里面具體都是什么樹卻看不清。

比如我們調研采購的付款環節：

雖然看上去這張圖是很清晰每個步驟要干什么，但真正到了詳細步驟的時候只根據這張圖是看不出具體做法來的，所以這就叫做只見森林不見樹。

2. 整理需求

要做到又見森林又見樹，需要對業務進行詳細的調研，并將調研的需求進行整理歸類，以此來洞察用戶行為，此步驟要捋清每個操作環節具體的流程以及業務邏輯，所以此步驟是最重要也是最容易混亂的，所以在調研此步驟時我借用了C端產品的用戶故事地圖，來完成此項任務：

第一個階段是根據第二步得出的流程，用戶需求是調研中用戶所提出的需求，用戶行為是需要將用戶的需求整理成用戶行為描述出來，這樣每個節點的邏輯與流程就出來了，最后記錄存在的問題。

在完成此步驟時需要考慮這幾個問題：

1. 某個流程節點下用戶都需要做哪些行為？
2. 需求中是否包括用戶的所有行為？（偽命題，不要嘗試窮舉所有行為）
3. 用戶會在什么情況下做這個行為？

跟圖這張圖可畫出詳細的流程圖或直接引用這張圖也可：

這樣我們就完成了業務流程與邏輯的調研，不過有人會問，這樣真的滿足了對方所有情況了嗎？我的答案是否定的。一家公司一般意識到想要發展信息化，至少要有10年左右的歷史，那么你要用短短的幾個月時間把這個流程全部搞清楚是不可能的，這家公司也未必能和你說清楚，所以需要一個迭代過程。

3. 鑄魂（管理）

以上是我們完成了一個關于應付賬款的調研，如果按照上述需求去做設計，那肯定會滿足他們的需求，實際操作中也不會出現什么問題，那為什么還要做第三步呢？

我認為我的產品是不能輕易被打敗的，也不會別人介紹我的產品的時候說“和某某產品類似”之類的話，我希望我的產品是一個有靈魂的產品。

這個事情是很難做到的，這里我所說的給產品鑄魂也是注入管理的靈魂，管理這東西虛無縹緲，你說他沒有，但是他有，你說他有但又看不見。

所以管理是存在每個環節中的，甚至一個小小的按鈕都能體現管理的作用。比如在采購物料編碼存在過多重復性垃圾數據時，系統如何幫助物料管理者去除重復的垃圾；在供應商過多時，如何為管理者提供篩選供應商的依據；如何幫助管理者有效管理員工。這些都是管理，我們將這些細節注入到產品中，就形成了我們的產品“魂”。

第三步 設計模塊

用腦圖清晰的表述出每個模塊的作用與功能，此步驟的目的在于幫助你再次回到全局的角度看此環節是否有遺漏或者不合理的地方。

模塊設計分為兩種：一種是站在系統角度將模塊進行劃分；一種是站在業務角度去劃分模塊。

其中我個人認為都有利弊，站在系統角度會更加清晰，開發人員理解起來也比較方便，但是使用者可能不是很習慣。業務角度去劃分會便于使用者去操作系統，很容易就能看出下一步我該干什么，在哪干，但是和開發解釋起來會比較麻煩，而且相對復雜。

比如同樣是合同，一個公司可能有采購合同、施工合同、銷售合同還有勞動合同，系統角度的話可以把合同單獨建立一個模塊，所有人只要做合同就來這個模塊；但是業務角度來設計的話就是采購合同歸屬于采購系統下的模塊，銷售合同歸屬于銷售系統下的模塊，這樣使用者操作起來是不是更方便。

當然你們從我的話語中可以感覺得到我更偏向第二種，但是要注意數據統一管理的問題，如果讓公司老板看的話，他可能會從全局去看，更像是系統角度。

第四步 設計原型

設計原型的工具推薦Axure，我不是給Axure打廣告，但是我認為這個確實比墨刀什么的強太多，Axure就好比PS，墨刀之類就好比美圖秀秀，雖然都可以處理圖片，但是自定義程度是不一樣的。

設計原型時你只要按照腦圖的模塊去建目錄按照用戶故事地圖去寫功能和邏輯就好了，這里就不過多介紹了，還需要注意的就是你們公司的產品規范，一個好的產品一定是有一套好的產品規范去約束，所以怎樣建立產品規范也是重中之重。

最后是這樣的：

本文由 @墨紫衣 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議