編輯導語：當我們在某個場景遇到了想做的事情時，便産生了需求，根據需求，産品經理需要滿足其需求并制定對應的解決方案。作者分享了他關于産品設計流程的一些思路，從場景、需求、解決方案的角度來思考産品的設計流程，希望對你有所幫助。

一、場景産生需求，解決方案滿足需求

什麼是場景呐？

• 場：指的是時間和空間；
• 景：在情景和互動下觸發用戶的情緒，使用戶産生意見和想法或者身體上的反應。

場景作用于用戶從而産生需求——想要做什麼、欲望。為了滿足需求需要制定解決方案——去做什麼。

二、從場景、需求、解決方案的角度來思考産品的設計流程

産品設計是從發散到收斂，從抽象到具象，從宏觀到細節的的過程。在設計新的産品時需要按照 【明确服務對象—梳理場景—判斷需求—解決方案—功能落地】的流程來：

1. 明确服務對象

我經常把我的服務對象分為3種類型：客戶、用戶以及業務方（包括老闆）——

①客戶（買單的人）是誰，客戶的特征畫像、客戶的需求、客戶的細化目标是什麼。

②用戶（實際使用的人），用戶的特征畫像、用戶的需求、用戶的細化目标是什麼，注意：其中用戶不一定是客戶，用戶一般會涉及到多個角色，往往上下級關系要涉及到管理權限和流程的設置。

③我所在的業務是TO B的業務，所以我對接的業務為我們公司的銷售，需要明确他們在對外銷售的時候在産品功能方面需要展示哪些高大上的功能來吸引客戶購買，哪些模塊方便打包售賣等。

2. 梳理場景

場景的核心是在空間加時間的點上觸發别人的情緒，如果你架構的場景不能影響别人的情緒，不能形成對别人情緒的觸發，它就不是一個場景。例如同樣是售賣書籍，如果是在知名作家的新書發布會上，激發了參會者的購買欲，圖書一售即空；但是在書店裡擺放着書就無人問津 ，無法激發用戶的情緒，所以就不構成一個場景。

用戶消費産品的本質是消費場景。例如爬泰山時，半山腰上的礦泉水的價格是平時的10倍，但是仍舊有很多人去買。

表象用戶是消費的是礦泉水，本質消費的是 用戶在爬泰山時身體對水的渴望以及不知道錯過這家商店，下一家商店需要往上爬多久之後才會出現的對未知的擔心。

前幾天去滑雪，在滑雪場一桶泡面15元，如果放在平時，肯定會無人問津。但是當時沒有其他的商店，小夥伴們需要吃飽飯才能補充體力來保證下午繼續快樂地滑雪，所以即便是這個價位大家依然排隊購買。所以說消費者購買的在某個場景下的需求。

梳理真實用戶的使用場景，C端産品可以創建場景來引導用戶需求，例如直播軟件的主播PK功能、抖音的模仿功能。B端産品存在業務壁壘，必須還原真實的客戶場景，才能解決客戶真正想要解決的問題。

3. 需求判斷

用戶需求=目标用戶（特征、經驗） 用戶場景

不同的用戶在同樣的場景下産生的需求是不一樣的。例如乘坐地鐵的場景，在從家到公司的路上乘坐地鐵的碎片化時間内，觸發了用戶需要利用碎片化時間做點事情的想法。愛學習的用戶需求是提升自己的專業知識，解決方案可以選擇為讀專業書；愛玩的用戶需求是想要放松自己，解決方案可以選擇為玩一會開心消消樂。

同樣的用戶在不同的場景下需求也是不一樣的。例如同一個用戶，在工作日午餐時間産生饑餓的場景中，需求是在較短的時間内補充足夠的能量消除饑餓感可以支持下午的工作。在周末的午餐時間産生饑餓感的場景中，需求是吃大餐消除饑餓感獎勵辛苦工作的一周，為了心心念念的美食，大家排隊1個多小時等位也是欣然接受的。

分析場景中産生的需求，以及該需求是否有必要去滿足從而界定需求邊界以及優先級的規劃。例如剛才提到的工作日吃飯補充能量的需求優先級遠高于周末吃頓大餐獎勵自己的需求優先級。

在我們平時和需求方溝通時，對方經常說自己看到競品有什麼功能，我們也要來一個。或者自己意想出一個什麼什麼功能，作為産品這個時候要思考挖掘的是 對方到底想要在什麼場景下解決什麼問題，最終達到什麼目标。

舉一個作為一個互聯網人都快聽吐了的例子：

福特公司的創始人福特先生到處跑去問客戶：“您需要一個什麼樣的更好的交通工具？”

幾乎所有人的答案是：“我想要一批更快的馬。”

很多人聽到這個答案可能立刻為客戶尋找更好的馬。

但是福特先生繼續問：“你為什麼需要一批更快的馬？”

客戶：“因為可以跑的更快！”

福特先生：“你為什麼需要跑的更快?”

客戶：“因為這樣我就可以更早到達目的地。”

福特先生：“所以，你想要一批更快的馬真實用意是？”

客戶：“用更短的時間、更快地到達目的地！”

最後福特先生就發明了汽車，更好的滿足了用戶的需求。

4. 解決方案的設計

在設計解決方案時，要對需求中多個解決方案進行對比，界定系統邊界，選擇成本更低，用戶體驗更好，更利用産品長期發展的方案。

對于用戶的體驗路徑來說，要搞清楚用戶在使用前、使用中、使用後的各個出發點，确保設計方案形成完整的閉環（線上 線下）。

對于産品的長期發展來說，要平衡好産品的性價比，給用戶提供良好服務的同時，要保證産品的收益持續化（金錢或者流量），這樣才能為後續的産品疊代支持提供支持。通常解決方案的細化表現形式為——流程圖或者線框圖

5. 功能實施落地

功能的實施落地主要就是跟進開發，保證項目的正常進度。在此過程中，會涉及到技術問題或者成本問題導緻技術方案替換的問題，時間問題導緻功能簡化或者放到下一期版本疊代的問題。

對于一些不在計劃内的情況，産品崗盡可能 本着能實現最終的産品目标和業務目标的原則下，和各方合作人員開開心心把工作搞定的心态來處理。

三、使用“用戶故事”分析場景和需求

提到場景、需求等概念，自然會關聯到用戶故事。用戶故事是需求側的概念，就是客觀存在的需求産生（人 場景）和需求被滿足的過程，直白講就是不用身份的用戶要達成某個目标需要做的一系列事情（時間、地點、人物 發展 …），是為了規劃需求使用的工具。

場景産生了需求，在滿足這個需求的過程中又會出現不同更細的場景。

簡單來說就是在實施具體的解決方案實現需求時，在每個環節又有可能會細分産生多個小場景，每個小的場景又産生了對應的小需求。建議使用“用戶故事法”來分析。

用戶故事通常的表達格式為：作為一個<用戶角色>, 我想要<完成活動>, 以便于<實現價值>。

舉個栗子吧：

某個場景——工作日早上很餓，但是還有半個小時就要上班了。

場景産生了需求——要在上班之前補充能量消除饑餓感。

為了滿足需求選擇了一個解決方案——去公司食堂吃早餐。

在執行解決方案時，産生了新的場景——食堂中不同窗口都排起了隊&15分鐘後部門就要開晨會了。

新場景産生的新需求——盡快買到飯不耽誤按時參加晨會。

新需求的解決方案——找了一個排隊人數比較少的窗口并打包帶走了食物。

好的用戶故事除了格式規範，要素完整外，還應該遵循INVEST原則：

• Idependent（獨立的）
• Negotiable（可協商的）
• Valuable（有價值的）
• Estimatable（可評估）
• Small（小的）
• Testable（可測試的）

以後有機會了再詳細分享。

關于用戶此波此結束啦，希望能夠幫助需要的小夥伴能夠更好地分析場景，做出能真正滿足用戶需求的好産品。拒絕僞需求，從認真分析每個場景開始~

本文由 @Grace 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自Unsplash，基于 CC0 協議

,

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

查看全部