編輯導語：使用者故事的存在，可以幫助業務人員精準地找到使用者需求，進而推動產品設計策略的落地。然而不少人可能會將使用者故事當作某種形式主義。如何才能發揮使用者故事的真實作用呢？本文作者進行了總結，一起來看一下。
相信你沒做過沒用過也至少應該聽過使用者故事。
使用者故事，
設計師作品集裡的常客，方法論大軍的重要成員。
那麼使用者故事到底是什麼？
如果你去百度的話，會發現使用者故事的解釋很多，其實我覺得簡單來說就是一句話：
記錄一類人完成一件事情的過程。
一、談“使用者故事”色變
設計師很喜歡把使用者故事加到自己的作品集中去，這些使用者故事可能是真的，但也確實存在很大一部分裝飾型使用者故事，用結果去倒推使用者故事，使得使用者故事成為一個不痛不癢的存在。
甚至逐漸形成一種潛規則，預設
作品集中的使用者故事基本都是無用的包裝。
導致這樣結果的原因主要有兩個：
其一，完整的使用者故事地圖做起來很複雜。
在網上搜關鍵詞“使用者故事”，你就可以看到一張張很詳細的使用者故事地圖，從問題痛點、一級故事二級故事到想法痛點機會等等，分析起來繁瑣且冗長。
不是說這樣分析不好，能這樣面面俱到徹底分析當然求之不得，但是現實情況是需求多，時間緊，留給我們做這樣細緻使用者故事的時間太少了。
等我們把故事完整分析一遍，需求可能早就上線了。
其二，很多人沒有養成事前分析的習慣。
你應該聽過一句話叫做 “為什麼聽了這麼多道理還是過不好這一生”。
因為只是聽，沒有做，知行不合一。
雖然我們在網上也看了學了不少方法論，但是很多時候只是放到收藏夾吃灰，我也總幹這事。
我的印象筆記可沒少收藏好文章，但是真正用上的卻寥寥無幾。
大部分設計師做需求的方式都是拿來就開幹，做到一半發現有問題了再改，甚至方向錯了推倒重來，等到面試做作品集的時候，就用結果來倒推過程，久而久之人們對使用者畫像的印象就變樣了。
難道使用者故事在實際工作中就真的派不上用場嗎？
或者說只有大公司才會有時間和精力去做使用者故事？
答案是否定的。
咱們先思考思考為什麼要做使用者故事這件事兒？
肯定不是為了做而做，也不是為了能夠在作品集裡炫耀所謂的方法論而做。
我認為使用者故事是一個幫我們梳理需求，讓我們找到更加精準的設計表達的工具。
關鍵詞是：
工具
。
稱手的工具才是好工具。
何謂稱手？就是得適合自己，盲目套模板肯定容易水土不服，也就導致了上面的問題，使用者故事逐漸淪為了形式主義。
那麼使用者故事到底要怎麼用，才能真正幫助我們做設計呢？
二、使用者故事3步走
工作中面臨著時間短任務重的現實問題，很難把使用者故事做細，而使用者故事用好了又確實能幫助我們做出更好的設計。
下面給你分享一些我做使用者故事的經驗，如何在不充裕的時間內利用使用者故事來輔助設計產出。
我把這樣的使用者故事表達稱為
實用型使用者故事
，用更加接地氣的方式來演化方法論。
1。 首先，以文代圖
咱樸實一點，直接用文字梳理，別繪圖甚至不用Excel表格，就用最樸實的文字，甚至不用開啟Word，用一個便籤就能寫。
當你拋棄一切形式主義的時候，就能更加專注於內容本身。
2。 然後，梳理角色
把需求中涉及到的所有角色都梳理出來，同一個需求不同的角色需要完成的任務不同，就會產生不同的使用者故事，需要區分出來。
例如我做的教育直播中，就會有老師、助教等角色，老師和助教的操作流程不一樣，使用者故事自然也不同。
3。 最後，寫故事
準備好上面兩步，下面就可以開始寫故事了。
只需要3個步驟，是不是很簡單？
先別掉以輕心，咱們重點在寫故事這一個環節，寫故事也分為3步……
哈哈，禁止套娃。
我把寫故事分為三步：
拆——延——痛。
簡稱“拆煙筒”式寫故事（諧音梗屬實要扣錢了……）
簡稱“拆煙筒”式寫故事
1）“拆煙筒”之拆：拆分場景
把每個角色的主要場景拆解出來，有規律的拆解，可以使用時間維度，例如直播前、直播中、直播後。
舉個例子
角色：
老師。
場景：
直播前：把PPT上傳到直播平臺；
直播中：講課、切換PPT、回答學員問題；
直播後：檢視直播資料。
角色：
助教。
場景：
直播前：建立直播間、傳送直播連結給老師和學員；
直播中：監控直播畫面，回覆學員問題；
直播後：匯出直播資料。
2）“拆煙筒”之煙：延展故事
把簡單的場景描述延展為一個具體的故事，故事需要包含3個要素：時間、地點、人物。
拿上面老師回答學員問題這一場景來舉例。
晚上9點，老師張明明在公司的辦公室直播講課，講課來到了答疑環節，老師說讓大家在聊天室內積極提問，他將抽取大家的問題來進行回答。
老師檢視聊天室，聊天室內出現了很多新訊息，老師向下滑動聊天室檢視歷史訊息，篩選將要回答的問題。
老師看到問題A，覺得是個典型問題，於是說就回答問題A，於是老師針對問題A進行了回答，回答後追問說大家是否聽懂了，聽懂了扣1，不懂的扣0 ，聊天室內出現了很多1的訊息，接著老師繼續翻看聊天室回答下一個問題。
這個場景的故事到這就結束了，需要注意的是，
描述上儘量客觀，多使用動作。
例如“滑動頁面”“翻看”等詞語，動作類詞語可以幫助我們更好地將老師的行為和軟體介面聯絡起來，幫助我們更好地找到問題所在。
3）“拆煙筒”之筒：
痛點挖掘
延展出來的故事可以幫助我們更加清楚地看到使用者使用過程中的痛點。
你可能會問，我用腦子想象不行嗎？非得寫下來嗎？
我的建議是寫下來。
我們的大腦是會騙人的，還記得格式塔原則中的封閉性原理嗎？
人們在視覺上會把不完全封閉的物象當成一個統一的整體。
為什麼？
因為我們的大腦非常會腦補，幫我們補充剩餘的圖形，但是實際上想象出來的可能是錯誤的。
電影《泰坦尼克號》的淚奔情節
所以如果我們僅靠大腦的想象，我們的大腦會在把故事當成點來標記，而導致遺漏了點與點之間的細節，因為在大腦中點與點也能串聯為一個故事。
例如老師回答問題這個場景大腦會認為是完整的點， 但是其實其中還包含了老師詢問學生、老師用滑鼠翻閱聊天室訊息、老師回答某一個問題、老師詢問大家是都聽懂了等等細節，所以
僅靠想象就很容易把這些細節遺漏掉。
岔遠了，話題拉回來，透過場景細節如何發現痛點？
還拿老師答疑這一場景舉例。
老師檢視學員的提問，他的動作是使用滑鼠滑動訊息檢視歷史記錄。
問題來了，如何保證不斷有新訊息湧入的情況下不影響老師檢視訊息？
老師答疑後如何快速回到最新訊息？
這一個動作是不是就發現了使用痛點？
接著分析。
老師答疑的時候，如何讓學生把老師的回答和問題對應上？
你上學的時候聽課應該有經驗，當問題比較複雜的時候，不看著問題來對應回答，一走神就容易忘了問題是什麼。
看，我們可以根據場景描述細節把痛點梳理出來。
痛點都梳理出來了，解決策略可以有很多，選一個最適合的就可以了。
其實關鍵不是怎麼解決問題，而是找到問題是什麼。
最後總結一個模板
本文由 @餿麵包 原創釋出於人人都是產品經理，未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議