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

注：本文所講的B端産品，主要是指通用型B端産品 ，不涉及定制化開發的B端産品，兩種類型的産品設計流程有着本質的差異，通用型B端産品以滿足某個群體客戶的通用需求為目标。

當我們計劃做某個功能時，如何開展設計呢？是确定叠代任務後立刻思考解決方案？還是直接構思功能細節？

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

先說流程，再詳細講解：

1. 找準核心場景；
2. 明确此次設計要達到的目标；
3. 看行業内的競品，看公司内的産品；
4. 設計功能整體結構；
5. 基于整體結構，開展具體的設計；
6. 思考默認值、異常場景；
7. 模拟用戶路徑，驗證功能設計的可行性。

本文主要講解功能設計流程裡的第一個環節：找核心場景。

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

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

一、場景為什麼重要

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

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

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

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

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

所以，場景很重要：

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

二、明确合格場景的标準

場景很重要，但是如果我們直接去閱讀原始的場景描述，就像看故事一樣，它們可讀性夠了，但是條理性不夠，可分析性也比較差，很難看出這些場景描述裡缺少哪些關鍵信息。

我們需要對原始場景的描述進行提煉和整理，便于我們補充關鍵信息，以及為後續做歸類和優先級評估建立良好的基礎。

什麼是合格的場景？

合格的場景指的是對客戶原始場景描述進行有條理地提煉，合格的場景是一個标準，其與場景的屬性、優先級無關。

不管場景是哪一類，其都要盡可能地符合這個标準，通過對原始需求場景進行提煉，可以讓我們更好地做需求場景分析。

基于以往工作中的沉澱、思考和讨論，我們明确了場景是用戶發生的完整故事，包括：什麼角色、為了達到什麼目的、目前使用了什麼樣的方式、出現了什麼問題、他想要什麼如何解決。

标準格式如下：

注意，我們常說的“需求場景”，實際上是場景 需求，雖然場景和需求經常放在一起描述，但是我們要明白：場景不是需求。有需求一定有場景，有場景不一定有需求。

對場景和需求關系的理解，将影響我們後續尋找核心場景和核心需求的流程。

示例：員工小A上班時的可選出行方式有：地鐵、開車、騎電動車。這三種出現方式對應的就是三個場景。

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

三、尋找核心需求場景

回到本文要解決的問題：做産品時首要步驟就是明确方向，明确方向指的即找到核心需求場景。

1. 什麼是核心需求場景

在第一部分，我們提到“需求場景”實際上是場景 需求，而“核心需求場景”就是對場景、需求的優先級綜合分析得出的結果。

• 場景可以劃分成：高優場景、一般場景、邊緣場景。
• 需求可以劃分成：高優需求，一般需求，邊緣需求。

價值排序：

高優場景的高優需求＞高優場景的一般需求/一般場景的高優需求＞一般場景的一般需求＞邊緣場景的所有需求/所有場景的邊緣需求。

注：通常情況下，我們評估場景的優先級主要是看場景頻次，但是實際上場景的優先級不隻局限于頻次，還會有市場價值的考量、安全類場景權重較高等考量，所以評估場景的重要性時不能隻看頻次，而要綜合考量。

理想的核心需求場景就是高頻場景下的高優需求。接下來講一下想要找到核心需求場景，具體可行的動作。

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

對于大型的功能，場景和需求可以拆開分析，先分析場景，再分析需求。對于中小型的功能，場景和需求其實可以放在一起分析。

場景和需求的歸類分析流程類似，如下：

• 第一步：按照合格的需求場景标準，對需求場景進行羅列；
• 第二步：歸類；
• 第三步：優先級評估。

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

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

1）客戶描述的需求未必是其内心的根本訴求，并且客戶可能會将多個需求摻雜到一起描述，要挖掘客戶最根本的訴求是什麼，并合理拆分；

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

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

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

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

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

找核心需求場景方法今天就講到這裡，想要了解在B端産品設計流程中，後續環節的方法，可以關注我，會持續更新。

本文由 @維克先生 原創發布于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。

,

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

查看全部