我們常聊的用戶故事

我有酒，你有故事嗎？我們可以彼此說說故事，但這故事不是你的也不是我的，而是受眾群體的。學習做過產(chǎn)品，跟一群大腦強悍程序員溝通，難免磕磕絆絆?，F(xiàn)在學習做培訓版塊，記得J告訴我 用故事來溝通和交流，省了不少事，也少惹了很多麻煩。

他是產(chǎn)品經(jīng)理當然有很強的溝通能力，和有場景思維，要有同理心，要有“零秒變小白”的能力。當然這些都是很好的思維習慣，但說多了容易形成某種幻覺，以為自己就是這么干的，最后麻木了不以為意。所以要時常問自己，是不是真的站在了受眾群體的角度，是否真正理解了最真實他們舍去場景。其實這種場景思維不只局限于事件本身上，將這種方式應用在每個環(huán)節(jié)的角色上，會大大降低溝通成本?？墒姑總€角色都更加了解自己參與的產(chǎn)品，更有成就感和責任感。

用故事進行溝通

同理心說得容易，其實做起來相當困難，大家不自覺地就會從自我出發(fā)，以為其他人都跟自己一樣，你認為的就是別人認為的。以下是溝通過程模型圖，先簡單介紹下，發(fā)送方在溝通過程中處于信息傳遞的主動地位，是溝通的起點。發(fā)送方將需要傳達的信息進行編碼，編碼后的表現(xiàn)形式可以多種多樣，比如語言、文字、圖形、動作或表情等等。通過不同的媒介（面對面、電話、電郵、互聯(lián)網(wǎng)聊天等）與接受者進行交流。在傳遞過程中會對信息產(chǎn)生干擾的一切因素都可稱作噪音，噪音越大，信息傳遞障礙越大，效率也越低。接受者處于溝通過程中的被動地位，對接受到信息需要進行解碼，轉化成需要的信息。

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

誰要用這個功能？

使用這個功能的目的是什么？

什么時候會用？

...

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

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

創(chuàng)建場景列表，在與需求方溝通的時候，隨手記錄場景需求

將場景需求拆解成場景步驟，列出每個步驟對應的角色

對每個場景步驟繼續(xù)拆解成功能，得到功能列表

然而大家的知識背景、技術水平、思維結構差別很大，他們關心側重點也不同。所以非常有效的一個方式便是講故事，對于每一個小功能模塊，都可以概括成，誰（用戶角色）在什么情況下為了達到什么目的，需要做什么（功能），成功了會怎么樣，失敗了又會怎么樣...這樣的溝通至少讓大家先理解了產(chǎn)品目標，保證大家在同一個頻道上對話。

用故事進行事件描述

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

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

1）先用受眾思維，選用合適的表達方式和寫作素材；

2）再借助邏輯思維和故事思維，組織信息，寫作成文。

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

1）先用故事思維理解用戶需求；

2）然后運用受眾思維和邏輯思維，設計合理框架結構和事件的交互。

總結

大家都愛聽故事，就像一篇學術論文和一篇小說，想必大家都更喜歡看小說。所以現(xiàn)在才有越來越多的作者將專業(yè)文章寫得通俗易懂，各種舉例講故事。以上只是說了兩大方面，其實在項目驗收，場景測試時，都可以“講故事”，如果連我的故事線都走不通，還有必要進行功能測試嗎？還有給客戶演示，別以為做幾張很炫酷的PPT，然后截幾張產(chǎn)品圖片就很OK了，其實這樣客戶往往不會買單的。還是要說故事，模擬場景，使用不同角色賬號登錄系統(tǒng)，說一個完美而順暢的故事，繼而打動受眾群體。