編輯導語：B端產(chǎn)品設計時確定方向以及找準需求場景很重要，本篇文章作者分享了B端產(chǎn)品設計的具體流程，以及講述了有關(guān)需求場景的內(nèi)容，感興趣的一起來看一下，希望對你有幫助。

注：本文所講的B端產(chǎn)品，主要是指通用型B端產(chǎn)品 ，不涉及定制化開發(fā)的B端產(chǎn)品，兩種類型的產(chǎn)品設計流程有著本質(zhì)的差異，通用型B端產(chǎn)品以滿足某個群體客戶的通用需求為目標。

當我們計劃做某個功能時，如何開展設計呢？是確定迭代任務后立刻思考解決方案？還是直接構(gòu)思功能細節(jié)？

需要說明的是：有序的做事和無序的做事在效率和質(zhì)量上是有很大差別，尤其是對于具有前置依賴特點的環(huán)節(jié)，若前置動作做不好，返工和走彎路是常事，而這些不必要的成本我們其實是可以避免的。

先說流程，再詳細講解：

1. 找準核心需求場景；
2. 明確此次設計要達到的目標；
3. 為目標達成找到最優(yōu)方案；
4. 設計功能整體框架；
5. 基于整體框架，完成具體的設計；
6. 明確默認值、補充異常場景；
7. 模擬用戶路徑，驗證功能設計的可行性；

本文主要講解功能設計流程里的第一個環(huán)節(jié)：找核心場景。

假如我們要去旅行，那么我們首先要確定的就是方向（要去陽光沙灘還是草原騎馬？），以此類比我們的功能設計，找核心需求場景就是明確方向，這是后續(xù)所有動作的前置條件。

做事情時，方向一定不能出問題。否則再努力，也是南轅北轍。

一、場景為什么重要

本文中，我們將不斷地提及“場景”，場景是什么？為什么我們不直接分析需求，不直接去設計方案，而要在“場景”上投入這么多精力？

通過一個簡單案例，了解一下場景的重要性。

案例：一個小超市，來了個客人想要買一些500ml“農(nóng)夫山泉”，但是此時店里沒有500ml的“農(nóng)夫山泉”。如果不聊具體的場景，我們怎么知道客人是因為口渴了想買水，還是還想些水會議招待，亦或者是只是想給家里屯點水。

在沒有具體的場景做支撐時，我們無法判斷是該從其他店里調(diào)一些500ml“農(nóng)夫山泉”過來，還是應該給客戶推薦500ml的“怡寶”，亦或者350ml或5L的“農(nóng)夫山泉”，甚至說推薦客戶買幾塊雪糕。

明確了場景，我們才可以避免陷入“基于問題解決問題”的直線思維。

場景很重要：

• 場景是討論價值和方案的前提，場景沒有或者不對，一切休談；
• 場景是不變的，方案是可變的，我們需要先明確場景，再分析可選方案。
• 場景是把需求從抽象到具象的過程，脫離場景去談談需求，是抽象的，每個人的理解可能都會不一樣。

二、需求和場景的關(guān)系

人們通常會把需求和場景放到一起描述，稱其為“需求場景”，然而場景和需求并非是一體的，它們是存在依賴關(guān)系的兩個對象：

• 場景不是需求，而是需求發(fā)生的背景；
• 有需求一定有場景，有場景不一定有需求。

所以，“需求場景”指的是“場景+需求”，對場景和需求關(guān)系的理解，將影響我們后續(xù)尋找核心需求場景的流程。

通過一個案例，再加深一下理解：

案例：員工小A上班時的可選出行方式有：地鐵、開車、騎電動車。這三種出現(xiàn)方式對應的就是三個場景，有些場景下有需求，有些場景下無需求。

1. （有場景有需求）在開車場景下， 小A的需求是期望公司能夠提供一個停車場；
2. （有場景有需求）在騎電動車場景下，小A的需求時期望公司可以提供充電樁；
3. （有場景無需求）在坐地鐵場景下， 小A沒有什么需求；

三、合格需求場景的標準

我們想要找核心需求場景就需要對諸多需求場景進行分析，但是如果我們直接去閱讀原始的描述，就像看故事一樣，可讀性夠了，但是條理性不夠，可分析性也比較差，并且很難看出這些場景描述里缺少哪些關(guān)鍵信息。

因此，我們需要對原始需求場景的描述進行提煉和整理，便于我們補充關(guān)鍵信息，以及為后續(xù)做歸類和優(yōu)先級評估建立良好的基礎。

什么是合格的需求場景？

合格的需求場景指的是對客戶原始需求場景進行有條理地提煉，合格的需求場景是一個標準，其與需求場景的屬性、優(yōu)先級無關(guān)。不管場景是哪一個層級、哪一個類別，其都要盡可能地符合這個標準。

基于以往工作中的沉淀、思考和討論，我們明確了需求場景是用戶發(fā)生的完整故事，包括：什么角色、為了達到什么目的、目前使用了什么樣的方式、出現(xiàn)了什么問題、想要什么如何解決。

標準格式：

四、尋找核心需求場景

回到本文要解決的問題：做產(chǎn)品時首要步驟就是明確方向，明確方向指的即找到核心需求場景。

1. 什么是核心需求場景

在第一部分，我們提到“需求場景”實際上是場景+需求，而”核心需求場景“就是對場景是否為核心、需求的優(yōu)先級綜合分析得出的結(jié)果。

• 場景可以劃分成：核心場景、次核心場景、非核心場景。
• 需求可以劃分成：高優(yōu)需求，一般需求，邊緣需求。

場景沒有優(yōu)先級之分，但是有核心程度的區(qū)別，我們可以基于產(chǎn)品定位、市場價值、安全類場景等維度，評估場景是否為核心；

需求是依賴于場景的，我們評估需求時有一套標準（例如需求頻次、阻塞程度、體驗提升程度等），而場景是否核心會對需求評估的優(yōu)先級增加權(quán)重。

價值排序：

核心場景的高優(yōu)需求＞核心場景的一般需求/次核心場景的高優(yōu)需求＞次核心場景的一般需求＞非核心場景的所有需求/所有場景的邊緣需求。

我們理想的核心需求場景就是核心場景下的高優(yōu)需求。接下來講一下想要找到核心需求場景，具體可行的動作。

2. 對場景和需求進行歸類和分析

流程如下：

1）場景歸納：基于各種渠道的需求，歸納出所有相關(guān)的場景；

2）場景分類：對場景劃分層次；

3）核心場景評估：評估出核心場景、次核心場景、非核心場景；

4）需求優(yōu)先級評估：評估出各個場景下的高優(yōu)需求、一般需求、邊緣需求；

如果場景的核心程度已經(jīng)明確，則可以直接做第四步，如果場景是否核心不夠明確（開發(fā)新產(chǎn)品、新模塊時會不清楚哪些是核心場景），則需要從第一步開始做起，我們需要做到：評估需求時，其對應的場景是否為核心一定要是明確的。

避免錯誤地把成本投入到非核心場景上，或者在次核心場景上付出過高的成本。

上面提到的動作里，每一個動作其實都可以單獨拎出來做單獨的方法論總結(jié)，但是本文主要是講整體的流程，所以不展開。

但是要說明的是，我們找核心場景時，有以下幾點需要注意：

1）客戶描述的需求未必是其內(nèi)心的根本訴求，并且客戶可能會將多個需求摻雜到一起描述，要挖掘客戶最根本的訴求是什么，并合理拆分；

• 客戶通常都會把想要某個功能當作自己的訴求，但是實際上我們滿足客戶的訴求可能是用其他方案；
• 舉例子：客戶想要一瓶”農(nóng)夫山泉“，有可能我們給一瓶”怡寶“或者給一塊”雪糕“也能滿足需求，所以要挖根本訴求；

2）梳理時不要引入自己主觀推測的需求場景，羅列出的場景要有支撐依據(jù)（來源于客戶、競品功能等）；

• 需求場景決定了我們的動作，如果引入主觀推測的需求場景，這些推測出來的需求場景和真實的需求場景放在一起考慮，會干擾我們的分析和具體動作。
• 舉例子：用戶想要對業(yè)務指標進行監(jiān)控通知的功能，如果我們推測可能還會有對系統(tǒng)異常情況進行監(jiān)控通知的需求，那么我們分析時就需要考慮這一項，甚至可能會錯誤地把自己推測的需求列到要解決的需求場景里。

3）分析出的核心需求場景存在不夠準確的風險，如果覺得判斷不準，可以直接找客戶溝通或找最接近客戶的職能同事進行溝通，驗證自己的判斷。

• 如果發(fā)現(xiàn)判斷的有問題，改就是了，通過分析判斷+面向客戶驗證，可以保證大方向很難出錯，這一步一定不要想著省事；
• 最終要達到的程度：自己對這個核心場景非常認可，不管誰有疑問，都可以解釋清楚。

找核心需求場景方法今天就講到這里，想要了解在B端產(chǎn)品設計流程中，后續(xù)環(huán)節(jié)的方法，可以關(guān)注我，會持續(xù)更新。

本文由 @維克先生 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。