我有酒，你有故事嗎？

我們常聊的用戶故事

我有酒，你有故事嗎？我們可以彼此說說故事，但這故事不是你的也不是我的，而是用戶的。在一家業務復雜的2B企業做產品設計，跟一群大腦強悍程序員溝通，難免磕磕絆絆。但自從學會了用故事來溝通和交流，省了不少事，也少惹了很多麻煩。

大家都在說，產品經理要有場景思維，要有同理心，要有“零秒變小白”的能力。當然這些都是很好的思維習慣，但說多了容易形成某種幻覺，以為自己就是這么干的，最后麻木了不以為意。

所以要時常問自己，是不是真的站在了用戶的角度，是否真正理解了最真實的用戶場景。其實這種場景思維不只局限于產品設計上，從產品初期到最后上線，都可以用到，同時也不僅僅是設計人員的專利，將這種方式應用在每個環節的角色上，會大大降低溝通成本?？墒姑總€角色都更加了解自己參與的產品，更有成就感和責任感。

用故事進行溝通

同理心說得容易，其實做起來相當困難，大家不自覺地就會從自我出發，以為其他人都跟自己一樣，你認為的就是別人認為的。以下是溝通過程模型圖，先簡單介紹下，發送方在溝通過程中處于信息傳遞的主動地位，是溝通的起點。

發送方將需要傳達的信息進行編碼，編碼后的表現形式可以多種多樣，比如語言、文字、圖形、動作或表情等等。通過不同的媒介（面對面、電話、電郵、互聯網聊天等）與接受者進行交流。

在傳遞過程中會對信息產生干擾的一切因素都可稱作噪音，噪音越大，信息傳遞障礙越大，效率也越低。

接受者處于溝通過程中的被動地位，對接受到信息需要進行解碼，轉化成需要的信息。

最后一個環節是接受者對發送者進行信息反饋，反饋使溝通過程變成一個閉合循環的過程。而實際溝通過程中，每一個環節的信息量都在遞減。

拿個實際工作例子來說，老板或運營部的人，準備將客戶的需求傳達給產品人員，假設他們都真正理解了客戶的訴求（信息度100%），經過自己整理編碼，信息完整度可能降到90%，然后經過一部分的噪音干擾，產品人員得到的信息可能降到80%，最后被自己的思維處理過濾，估計只剩不到一半的準確信息了。

這個模型中的噪音指的是很多客觀環境，我們暫忽略不計。信息衰減最嚴重的地方一般是發送者對信息的編碼和表述過程，比如剛說的需求傳遞者經常這么干，要么用簡單的幾句話概括，要么直接給你一個自認為合理的設計方案。要是碰到提需求的人恰好是程序員出身，就更慘不忍賭，提需求過程中摻雜著實現方法。他以為自己傳遞得很完美了，其實產品人員在心中痛苦地撕喊，我根本沒有真正理解嘛，心里一堆疑問：

• 誰要用這個功能？
• 使用這個功能的目的是什么？
• 什么時候會用？

…

負責任的產品人員會刨根問底，去挖掘用戶真正的需求。否則只根據不到一半的信息度進行設計，浪費設計人員時間不說，還打擊人家信心，同時影響整個產品進度。

經過幾次這種低效溝通后，尋找發現問題的所在。然后我們開始用說故事的方式進行傳達，因為不是C端產品，很多場景實際上是無法親自體會的。而通過情景代入的確是個好方法。具體做法如下：

• 創建場景列表，在與需求方溝通的時候，隨手記錄場景需求
• 將場景需求拆解成場景步驟，列出每個步驟對應的角色
• 對每個場景步驟繼續拆解成功能，得到功能列表
• 將功能列表進行優先級排序

同時有了這么一份文檔，每次需求會議或簡單傳達時，會及時提醒自己先從理解場景入手，提需求人員也只好乖乖給你講個完整的故事。這樣一份文檔既結合了場景建模和用戶建模又可以進行需求管理。

除了需求來源溝通外，在與開發人員進行討論時，也經常出現溝通障礙。作為產品設計者，當遇到某個“疑難雜癥”需要與開發大哥進行探討時，往往大哥的程序思維會爆棚，把后臺表結構拿來一一講解。

他講得精疲力盡，你聽得昏天黑地，但效果甚微，根本沒有解決問題嘛。換種思路，你講個小故事，有人物有背景，然后最后拋出問題，讓他按照你的思維結構給出答案，這比你去理解程序要快得多。

再說說會議溝通，一般立項時，與會者往往包括產品線幾乎所有環節的人員。會議最重要的目的是將你的信息以最快速度傳播出去，然而大家的知識背景、技術水平、思維結構差別很大，他們關心側重點也不同。

所以非常有效的一個方式便是講故事，對于每一個小功能模塊，都可以概括成，誰（用戶角色）在什么情況下為了達到什么目的，需要做什么（功能），成功了會怎么樣，失敗了又會怎么樣…這樣的溝通至少讓大家先理解了產品目標，保證大家在同一個頻道上對話。

用故事進行產品設計

產品設計是由粗到細的活兒，從搭建產品框架到具體某個頁面設計其實都是在“講故事”。以下是信息傳遞模型，這個模型其實與上面說的溝通模型大同小異，重點是加入了邏輯思維、故事思維和受眾思維，如果能將這三種思維在信息傳遞中利用起來，將會大大提高傳遞的效率。

比如寫作，就是為了傳遞作者的信息。利用這個模型，寫作的一般步驟可以歸納為：

1. 先用受眾思維，選用合適的表達方式和寫作素材；
2. 再借助邏輯思維和故事思維，組織信息，寫作成文。

同理，我們的產品設計也是傳遞信息的一種，故而可概括為：

1. 先用故事思維理解用戶需求；
2. 然后運用受眾思維和邏輯思維，設計合理框架結構和頁面交互。

上一篇文章提到過框架設計的注意點，而說故事的方式在框架設計上也很有用武之地。一般我們常用的方法是將某個角色的操作進行匯總歸類，然后進行模塊劃分。然而對于角色眾多，場景復雜的B端產品，這種方法設計出來的框架可能會過于“軟件”化，用戶體驗未必會很好。

如果能考慮加入場景故事線的維度，會使產品更加靈活和有人味兒。比如某個后臺設置功能只是為了一個特定場景使用，我就未必非要放在全局設置中，而是可以考慮做入這個故事中的某個環節。

至于頁面設計，在設計時，我們至少需要考慮以下幾點：

• 這個頁面要展示什么內容？
• 用戶進入這個頁面的場景有哪些？
• 每個場景的目的是什么？
• 針對不同的場景頁面需要有哪些變化？

舉個例子，這是某個理財APP的頁面，故事是這樣的，我在這個APP里投入了部分資金進行理財，恰好前兩天需要用錢，所以打算贖回大部分資金。對于我這種對網上理財還是有點不放心且理財金是我大部分家當，那贖回的過程中我是不是特別關注贖回進度。

可是這個APP在經過贖回確認后（資金還未到賬），就顯示為下面第的一個頁面（跟贖回前無異，只是總金額少了），此時我的第一本能反應有點驚慌了：金額怎么這么少了？贖回的錢呢？我明明沒有收到錢??？贖回失??？… 它的做法是需要通過點擊“交易記錄”到“贖回”列表中去查看明細。

這就是帶著故事做設計，這APP的設計是滿足了用戶基本需求，卻沒有把握住故事中主人公的真正心理狀態，如果在這個頁面有個贖回提示，是不是更好。而且它又不是家喻戶曉的產品，主要還是新用戶占絕大多數。

總結

大家都愛聽故事，就像一篇學術論文和一篇小說，想必大家都更喜歡看小說。所以現在才有越來越多的作者將專業文章寫得通俗易懂，各種舉例講故事。

以上只是說了兩大方面，其實在項目驗收，場景測試時，都可以“講故事”，如果連我的故事線都走不通，還有必要進行功能測試嗎？還有給客戶演示，別以為做幾張很炫酷的PPT，然后截幾張產品圖片就很OK了，其實這樣客戶往往不會買單的。還是要說故事，模擬場景，使用不同角色賬號登錄系統，說一個完美而順暢的故事，繼而打動用戶。

本文由 @?一念 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自unsplsh，基于CC0協議