本文将從目的、需求收集/整理、設計模塊、輸出原型這幾方面來完成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協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部