用戶體驗地圖（experience map）作為一種常見工具能夠讓工作更加順暢，用戶體驗地圖就起到了一個很好的團隊協作作用，產品、設計、開發都能夠通熟易懂，便于梳理清楚產品的架構和使用流程。

作者|螞蟻金服UED

源自|設計夾

但是體驗地圖到底能解決什么問題，該怎么用呢？很多同學也許并不太了解。這次分享主要是將我們在各類渠道了解到的關于用戶體驗地圖的各類說法做了一個總結，并結合了我們在工作中的實際運用，給有興趣了解該方法的同學提供一點我們的見解和看法。

本文圖文內容，來源于螞蟻金服體驗技術部「芝士會」分享。

本文將分為 5 個部分：

怎么做

提效

價值

總結

相關材料

中后臺產品大多通過產品化工具來給用戶提效，隨著用戶的應用場景開始延伸到線上線下各個角落，設計師也開始思考如何從時間空間維度去關注完整的用戶體驗。

用戶發現你提供的產品真正的價值，就像這張封面背景圖一樣，往往要經過一段旅程，必定不是一馬平川。通過我們的專業知識、見解和洞察搞清楚用戶這段旅途當中坑在哪里、怎么填才能讓用戶走的更順。幫助用戶更容易獲取產品價值，幫助項目組獲得成功。

一. 怎么做？

用戶故事地圖雖然是一個耳熟能詳的體驗工具，但事實上當你接觸的時候才知道并不容易。其中需要注意的要點很多，能找到的模型也很多樣，導致做一個正確的方向變得復雜，結果可能會產出一個適得其反的用戶故事地圖，或者什么都沒有產出，那我們到底該怎么做呢。

我們在支持項目的過程中，初期會選擇采用「故事編寫工作坊」的形式來梳理產品的用戶故事地圖。一般是項目組成員共創的形式，參與人員包括：技術開發、產品經理、項目經理、設計師、用戶、產品老大。

重要流程分成四個步驟：產品定義——梳理骨干故事——拆分故事——溝通確認。

下面我簡要介紹下這四步分別需要做哪些事情。

第一步：產品定義

一般是在故事編寫工作坊準備階段，首先由PD提主導產出，主要有幾點內容：

產品的目標用戶

解決了哪些問題

用戶目標

產品目標

將這些內容記錄在黑板上，與大家討論達成共識，最終確定產品定義。簡單來說，需要明確「我們為什么要做這個？」以及「用戶為什么要用這個？」明確業務訴求和用戶訴求為之后的設計提供了指導，不僅可以在接下來討論的過程中不易迷失方向，還可以避免陷入設計細節的糾結。基于業務訴求和用戶訴求其實就是為了不忘初心，是為了明確設計的初衷。所以，在做交互設計之前，一定要問自己這兩個問題：「這能給我們帶來什么價值？、這能為用戶提供什么價值？」這一步可以讓項目組內所有人和用戶共同明確產品覆蓋的整個范圍。

第二步：梳理骨干故事

為了方便大家理解，我在這里舉一個大家生活都會發生的例子。故事的整個范圍：起點是起床——終點是到達公司。閉上眼睛，回想一下今天早上起床的過程。把這段故事分成這樣幾個階段，起床——洗漱——穿衣——出門——上班途中——到達公司。

在真實做項目過程中，大家在這一步可能會寫出不同顆粒度的故事，需要設計師把控故事的大小，這段故事可以再往下梳理一層顆粒度更小一點的故事。比如起床就可以再拆分為：鬧鈴響了——掙扎——關鬧鐘——下床。剩下的故事卡片都可以繼續這樣拆分歸類。

這樣我們骨干故事就有兩層：一級故事和二級故事，故事的發生從左至右是一個敘事流。

這里需要注意的是，在真實業務中，故事的流程不可能是一帆風順的，情況會變得復雜，我們可以借助流程圖的圖例線連接我們的故事卡片。

總結一下，我們在這步怎么做的。首先，我們在第一步確定產品整體范圍之內盡量的把故事講完整，比如我們這個例子，起床——洗漱——穿衣——出門——上班途中——到達公司。這樣我們項目組的所有人就可以對整個產品有個全局的印象。其次，我們需要注意是要講完整的故事，但是一定要廣度優先，而非深度，要做到一公里寬一厘米深。比如刷牙這個故事里面，找牙刷、擠牙膏這類故事在這個階段我們無須關注，不要過早的沉浸到細節中。在這步讓大家做到對產品只見森林不見樹木的狀態。

第三步：拆分故事

在這一步，我們需要在剛剛梳理的每一個二級故事下面做停留，去拆分二級故事獲取更多細節內容。如果二級故事是一個海平面的話，那二級故事以上就是海平面故事，那現在我們需要關注的是海平面以下更多不可見的故事。項目組會圍繞這個故事寫出很多細節來。我們可以按照以下幾個維度對細節進行歸類，分別是：故事細節、想法、痛點、機會、情緒。其中情緒可以通過固定的問題獲得，也可以通過用戶想法、用戶的痛點結合主觀判斷。

在這個過程中，先讓大家在一定時間內按照自己的想法寫出來，每一條寫在一張卡片上，做到相互不干擾，然后每個人出聲說出自己的卡片內容，讓所有人了解并貼在墻上。

項目組人在寫想法的時候，相當于腦暴的過程，這時可以通過一些問題來刺激大家腦暴出更多的內容，比如：

用戶在這步具體做什么？

用戶還有其他選擇么？

用戶怎么做才能更爽？

出現問題如何處理？

其他用戶來到這里該如何處理？

回到我們的例子，我們洗澡的時候有正常的流程，但當沒有熱水時這個流程就會發生變化。同樣，在真實業務當中，這類情況將更普遍的發生，所以這一步我們將盡量多的關注到所有場景的故事。

做完這步，我們已經獲取到了足夠多的細節信息，整個項目組都會做到對產品又見森林又見樹木的狀態。

第四步：溝通確認

這里我們的故事已經變得很豐滿，甚至變得臃腫，所以溝通確認變得極為重要。我們在這步需要花費相對多的時間，大家對內容進行對標、充足討論，把公認的留下來，無用的剔除掉。同時可以區分要做的故事細節的優先級。

依次類推，當所有故事梳理完成之后，就完成了如下這樣一張完整的用戶故事地圖了。

總結一下。首先，我們需要對大家寫的所有卡片進行對標，排除無效故事。其次，因為我們一般項目時間不夠，開發資源緊張，不可能一口吃個胖子，所以把要做的事情達成共識排出優先級變得尤為重要。最后，并不是所有的故事卡片都需要在同一時間細化，在真實業務中有些模塊的故事是無法一開始就梳理清楚的，所以可以先寫個占位符，待合適的時機再做拆分。

我們通過這種一目了然、格式一致的故事地圖，讓項目組所有人都獲得足夠的信息，讓項目有一個明朗的開發流程。

回顧一下，我們通過這四步梳理出產品的故事地圖，這中間還有很多細節要點，會在今后再整理總結分享給大家，本次不做過多描述。

在真實業務落地的時候會發現，因為一般項目時間都非常緊張，這樣一個完整的流程會顯得比較重，耗費時間，所以我們一直在思考如何提效。

二. 提效

我們目前通過三種方式提效，分為事前——事中——事后。

1. 事前

我們制作了Excel故事地圖準備模板，可以在故事編寫工作坊開始前的一到兩天發給參會人員，讓所有人能夠相對結構化的對產品有一個整體的梳理和思考，這樣可以幫助在工作坊中提高產出數量和質量。

2. 事中

如果是需優化的產品，我們可以將設計稿demo或者線上產品截圖打印出來，這樣可以增強大家的代入感，提高產出質量。

3. 事后

我們制作了Axure的體驗地圖整理模板，方便快速整理電子版，將我們的討論內容高效傳播。

最后我想講一下，這個方法的價值，大家可以自行判斷什么業務背景下適合采用該方法。

三. 價值

1. 共識

以往我們設計師共識的方式有兩種：一種是文檔，翻開一看，那些格式化的語言就變成了世界上最好的催眠曲。讀尚且如此，寫的人會怎么樣？寫文檔的PD腦子里一定會回響一個問題：這東西寫了有人認真看么？

有文檔看還是好的，還有更多情況是PD直接拉上你找你聊，手繪幾個線框圖，就算交接需求了，這兩種方式都可以進行接下來的界面設計，但是你確定你收到的就是真實的需求么？而且這里的共識是點對點的，或者單點對多點的，信息傳遞也會帶來信息內容的損耗，甚至錯誤的信息。

這里提到的共識有什么不同？

用戶故事地圖過程中做到多角色、多視角，尤其是中后臺產品不只是單純的估計用戶需求。

項目里不同的參與者有不同的需求、PM想跟蹤進度、開發人員想實現、產品經理想功能、產品老大有更高的視角，而用戶想要一個可用的系統。在這些充滿沖突的視角中，想要做出一個人人都支持、皆大歡喜的決定，并且持續保持平衡是很困難的事情。整個項目組就像一個四驅車，一個角色的強勢就相當于一個輪子轉的過快，這對產品都是損失，導致車子的方向偏移。我們通過大家一起建立產品全景圖的方式，讓項目組所有人包括用戶站在八百里高空俯視產品，這種同一空間多點對多點的共識就自然的完成了，這種共識應該是空前的。

再舉一個例子，很多情況我們通過文檔溝通，會以為我們了解了，認為我以為的就是你以為的。

但是如果我們把各自的想法說出來、寫出來、畫出來，我們可能發現你以為其實不是我以為的。

故事地圖這種方法就是：通過討論把大家的想法對標，達成一致。

最后理想狀態達到我以為的就是你以為的。

2. 同理心

我們在真實支持中后臺產品時，設計有一個很大問題就是無同理心，面對業務里很多專有名詞會很無力，甚至同一項目組不同模塊的人都相互不理解對方的專有名詞。

那故事地圖是如何解決這個問題的。

這里舉了一個例子，如圖所示，我們所有人都可以快速知道用戶想要什么，為什么要這個。通過這種簡潔明了、場景還原的方式讓大家都更容易理解，每個故事我們都做到站在用戶的頻道，說人話。

3. 參與性設計

與參與性設計對立的是經驗性設計。新產品的設計，都是設計者通過觀察未來用戶以及發揮產品的各種效用各種情形。經驗性設計高度依賴前期的用戶調研，包括用戶訪談和用戶觀察，但是用戶不會成為產品設計的真正參與者，后面的階段基本是靠設計師經驗，幾乎沒有用戶身影。

用戶故事地圖是一個吸引用戶參與設計他們所需產品的便捷手段。我們原型設計階段的所有內容來源于用戶故事地圖，因為故事地圖是用戶全程參與的，所以在我們整個設計過程中都有用戶的身影。

用戶故事易讀、易懂，我們邊聊故事的同時進行頁面框架繪制，因此能激發用戶的積極性，成為產品設計的參與者。同時，隨著用戶漸漸掌握如何口頭表達故事來描繪他們的需求，項目組成員與用戶間的關系變得更加親密主動，這種良性的循環使所有人員都獲益良多。

4. 記錄

我們以往記錄的方式無非有幾種：文檔記錄、筆記記錄或者記錄在聊天記錄里面。這種方式大多是單點對單點或多點的，而且記錄內容有限。

用戶故事地圖的記錄方式有什么不同？

為了方便大家理解，這里我再舉一個例子。大家看到下面這張照片，那這張照片傳達給大家的信息是什么？大多數人得到的信息可能是你們玩的很開心，沙灘的風景真美等等這些表面的信息。但是這張照片對于在照片里的人傳達的信息就多得多，比如我看到這張照片我會想起我們為了來這個沙灘開了一個小時車，脫了鞋走進來，萬老板沒過來去休息了，我們找了當地導游給我們拍照片等等很多發生在那個時間段的很多細節信息。

那對于照片里的人來說，這張照片不僅僅是照片。同樣的道理，故事地圖的每張卡片，記錄的也絕不只是卡片上的內容，它記錄了大家圍繞這張卡片討論的那個時間段所有的信息，記錄的信息量是更加龐大的。

我們回頭再去看這些卡片的時候，和看照片一樣，它會快速喚起我對那段時間的回憶。

四. 總結

我們梳理了用戶故事地圖的這四個價值，分別是共識、同理心、參與性設計、記錄。

加上我們整理的故事地圖四個步驟：產品定義——梳理骨干故事——拆分故事——溝通確認

想通過這個方法去維持范圍層的穩定，讓我們能更好的做原型設計。

我想強調一點，在復雜產品中，不要試圖在項目開始就做一套保羅萬象的決策。相反，故事是一直伴隨著產品生產周期的，我們要把各個決策分散到項目過程中。為此我們要確保一個獲取信息的過程方法，這就是一個良性的用戶故事地圖。

這里再做一個比喻，良性用戶故事地圖像一個捕魚的過程。

首先，不同大小的網用來捕獲不同大小的故事，第一遍我們可以用大網眼的漁網撈一遍故事池，以此得到所有大故事。通過大故事，形成對產品的整體感覺，接下來用網眼稍微小一些的漁網得到中等大小的故事，暫時還不用顧及那些小需求。最后才是最小的需求。

其次，捕魚表達了另外一層含義，故事會像捕魚一樣，隨著時間的推移會成長，會有新出生的魚，也可能會死亡。有些需求在某一階段不重要，但會像魚一樣成長，隨著產品階段的不同變的越來越重要，有些需求我們曾經認為很重要，但是會隨著產品階段不同逐漸變的重要性會降低，有時甚至降低到我們任務這些需求已經無效。

最后，正如捕魚一樣，不可能捕捉到這個區域所有的魚，我們也不可能捕捉到所有的需求，另外，在捕魚的時候也可能撈到一些廢棄物和殘骸，就是不是故事的故事。

從上面的比喻可以看出來，項目前期是不可能正確的捕捉并寫出所有的需求所有故事的，用戶故事地圖這個方法也不可能在單一階段捕獲出所有的用戶故事。用戶故事不是二維的產物，應該是三維的，需加上時間這個維度，隨著時間的推移以及產品不同階段加入產品新的用戶故事。捕捉故事的漁網網眼也會一直變化。

通過用戶故事這個方法，不止能幫助我們知道有哪些坑，怎么填，更重要的是哪些坑先填、哪些后填？怎么填更好？這種仁者見仁的判斷需要我們在使用中去總結經驗。

END