編輯導語：用戶故事的存在，可以幫助業務人員精準地找到用戶需求，進而推動產品設計策略的落地。然而不少人可能會將用戶故事當作某種形式主義。如何才能發揮用戶故事的真實作用呢？本文作者進行了總結，一起來看一下。

相信你沒做過沒用過也至少應該聽過用戶故事。

用戶故事，設計師作品集里的?？?，方法論大軍的重要成員。

那么用戶故事到底是什么？

如果你去百度的話，會發現用戶故事的解釋很多，其實我覺得簡單來說就是一句話：

記錄一類人完成一件事情的過程。

一、談“用戶故事”色變

設計師很喜歡把用戶故事加到自己的作品集中去，這些用戶故事可能是真的，但也確實存在很大一部分裝飾型用戶故事，用結果去倒推用戶故事，使得用戶故事成為一個不痛不癢的存在。

甚至逐漸形成一種潛規則，默認作品集中的用戶故事基本都是無用的包裝。

導致這樣結果的原因主要有兩個：

其一，完整的用戶故事地圖做起來很復雜。

在網上搜關鍵詞“用戶故事”，你就可以看到一張張很詳細的用戶故事地圖，從問題痛點、一級故事二級故事到想法痛點機會等等，分析起來繁瑣且冗長。

不是說這樣分析不好，能這樣面面俱到徹底分析當然求之不得，但是現實情況是需求多，時間緊，留給我們做這樣細致用戶故事的時間太少了。

等我們把故事完整分析一遍，需求可能早就上線了。

其二，很多人沒有養成事前分析的習慣。

你應該聽過一句話叫做 “為什么聽了這么多道理還是過不好這一生”。

因為只是聽，沒有做，知行不合一。

雖然我們在網上也看了學了不少方法論，但是很多時候只是放到收藏夾吃灰，我也總干這事。

我的印象筆記可沒少收藏好文章，但是真正用上的卻寥寥無幾。

大部分設計師做需求的方式都是拿來就開干，做到一半發現有問題了再改，甚至方向錯了推倒重來，等到面試做作品集的時候，就用結果來倒推過程，久而久之人們對用戶畫像的印象就變樣了。

難道用戶故事在實際工作中就真的派不上用場嗎？

或者說只有大公司才會有時間和精力去做用戶故事？

答案是否定的。

咱們先思考思考為什么要做用戶故事這件事兒？

肯定不是為了做而做，也不是為了能夠在作品集里炫耀所謂的方法論而做。

我認為用戶故事是一個幫我們梳理需求，讓我們找到更加精準的設計表達的工具。

關鍵詞是：工具。

稱手的工具才是好工具。

何謂稱手？就是得適合自己，盲目套模板肯定容易水土不服，也就導致了上面的問題，用戶故事逐漸淪為了形式主義。

那么用戶故事到底要怎么用，才能真正幫助我們做設計呢？

二、用戶故事3步走

工作中面臨著時間短任務重的現實問題，很難把用戶故事做細，而用戶故事用好了又確實能幫助我們做出更好的設計。

下面給你分享一些我做用戶故事的經驗，如何在不充裕的時間內利用用戶故事來輔助設計產出。

我把這樣的用戶故事表達稱為實用型用戶故事，用更加接地氣的方式來演化方法論。

1. 首先，以文代圖

咱樸實一點，直接用文字梳理，別繪圖甚至不用Excel表格，就用最樸實的文字，甚至不用打開Word，用一個便簽就能寫。

當你拋棄一切形式主義的時候，就能更加專注于內容本身。

2. 然后，梳理角色

把需求中涉及到的所有角色都梳理出來，同一個需求不同的角色需要完成的任務不同，就會產生不同的用戶故事，需要區分出來。

例如我做的教育直播中，就會有老師、助教等角色，老師和助教的操作流程不一樣，用戶故事自然也不同。

3. 最后，寫故事

準備好上面兩步，下面就可以開始寫故事了。

只需要3個步驟，是不是很簡單？

先別掉以輕心，咱們重點在寫故事這一個環節，寫故事也分為3步……

哈哈，禁止套娃。

我把寫故事分為三步：拆——延——痛。

簡稱“拆煙筒”式寫故事（諧音梗屬實要扣錢了……）

簡稱“拆煙筒”式寫故事?

1）“拆煙筒”之拆：拆分場景

把每個角色的主要場景拆解出來，有規律的拆解，可以使用時間維度，例如直播前、直播中、直播后。

舉個例子?

角色：老師。

場景：

• 直播前：把PPT上傳到直播平臺；
• 直播中：講課、切換PPT、回答學員問題；
• 直播后：查看直播數據。

角色：助教。

場景：

• 直播前：創建直播間、發送直播鏈接給老師和學員；
• 直播中：監控直播畫面，回復學員問題；
• 直播后：導出直播數據。

2）“拆煙筒”之煙：延展故事

把簡單的場景描述延展為一個具體的故事，故事需要包含3個要素：時間、地點、人物。

拿上面老師回答學員問題這一場景來舉例。

晚上9點，老師張明明在公司的辦公室直播講課，講課來到了答疑環節，老師說讓大家在聊天室內積極提問，他將抽取大家的問題來進行回答。

老師查看聊天室，聊天室內出現了很多新消息，老師向下滑動聊天室查看歷史消息，篩選將要回答的問題。

老師看到問題A，覺得是個典型問題，于是說就回答問題A，于是老師針對問題A進行了回答，回答后追問說大家是否聽懂了，聽懂了扣1，不懂的扣0 ，聊天室內出現了很多1的消息，接著老師繼續翻看聊天室回答下一個問題。

這個場景的故事到這就結束了，需要注意的是，描述上盡量客觀，多使用動作。

例如“滑動頁面”“翻看”等詞語，動作類詞語可以幫助我們更好地將老師的行為和軟件界面聯系起來，幫助我們更好地找到問題所在。

3）“拆煙筒”之筒：痛點挖掘

延展出來的故事可以幫助我們更加清楚地看到用戶使用過程中的痛點。

你可能會問，我用腦子想象不行嗎？非得寫下來嗎？

我的建議是寫下來。

我們的大腦是會騙人的，還記得格式塔原則中的封閉性原理嗎？

人們在視覺上會把不完全封閉的物象當成一個統一的整體。

為什么？

因為我們的大腦非常會腦補，幫我們補充剩余的圖形，但是實際上想象出來的可能是錯誤的。

電影《泰坦尼克號》的淚奔情節?

所以如果我們僅靠大腦的想象，我們的大腦會在把故事當成點來標記，而導致遺漏了點與點之間的細節，因為在大腦中點與點也能串聯為一個故事。

例如老師回答問題這個場景大腦會認為是完整的點， 但是其實其中還包含了老師詢問學生、老師用鼠標翻閱聊天室消息、老師回答某一個問題、老師詢問大家是都聽懂了等等細節，所以僅靠想象就很容易把這些細節遺漏掉。

岔遠了，話題拉回來，通過場景細節如何發現痛點？

還拿老師答疑這一場景舉例。

老師查看學員的提問，他的動作是使用鼠標滑動消息查看歷史記錄。

問題來了，如何保證不斷有新消息涌入的情況下不影響老師查看消息？

老師答疑后如何快速回到最新消息？

這一個動作是不是就發現了使用痛點？

接著分析。

老師答疑的時候，如何讓學生把老師的回答和問題對應上？

你上學的時候聽課應該有經驗，當問題比較復雜的時候，不看著問題來對應回答，一走神就容易忘了問題是什么。

看，我們可以根據場景描述細節把痛點梳理出來。

痛點都梳理出來了，解決策略可以有很多，選一個最適合的就可以了。

其實關鍵不是怎么解決問題，而是找到問題是什么。

最后總結一個模板?

本文由 @餿面包 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議