在產品設計和互動過程中，使用者體驗是一個非常重要的部分。隨著產品的逐漸完善，主創團隊也需要透過各個維度來了解使用者需求，完善使用者的整體體驗。在這裡，我們經常用到的一個實踐是使用者故事地圖。

一、使用者故事地圖是什麼？

我們可以把使用者體驗整個產品的行為當作使用者的旅程。在整個旅程中，使用者是不能第一步就發現產品的所有價值的，需要經過各種活動及行為的觸發，來深入進行體驗，從而挖掘出產品的價值。

那使用者故事地圖就是一種安排使用者故事的方法，它將使用者旅程的基本步驟安排在水平軸（行）上，將使用者故事安排在相應的步驟（列）下面，在同一列中，使用者故事的優先順序由上至下依次降低。當使用者故事地圖完成時，我們可以在單一的邏輯檢視中看到使用者與產品互動的所有方式，從第一次互動到完成總體使用者目標。使用使用者故事地圖，可以透過更全域性的視角瞭解使用者故事如何融入整體使用者體驗。

二、我們要如何使用使用者故事地圖？

首先第一步，確定目標使用者

在確定目標使用者之前，我們還需要對齊一下產品的定義以及產品的目標。也就是說，我們需要在內部明確我們到底要做什麼、我們為什麼要這樣做以及使用者的價值。接下來我們就需要確定產品的目標使用者，比如噹噹的目標使用者是新書、暢銷書購買群體；而孔夫子舊書網的目標使用者則是古舊書、絕版書購買群體。

確定好目標使用者之後，我們就要來梳理目標使用者的使用者故事了。

第二步：確定使用者故事

在這一步中，我們需要確定的是主幹使用者故事。舉個例子，如果我要在週末去吃飯，可能會將這個活動拆分為起床-洗漱-換衣服-選擇餐廳-出門-到達餐廳。那在這個時候，我們可以將這些主幹使用者故事放在使用者故事地圖的最上一層。

接下來，我們需要將這些使用者故事進行更加細緻的拆分：洗漱我們可以拆分為洗臉、刷牙、護膚等。這些顆粒度更細的使用者故事可以放在主幹使用者故事的下面一層。不過在這裡我們要注意一點，我們不需要將使用者故事進行非常細緻的劃分，比如：將起床拆分為睜開眼睛、從床上坐起來等等，因為這種維度的拆分是已經落實到非常細節的執行中了的，如果只關注在這種顆粒度的話，會讓我們過早地深入探究“如何實現產品”中去，而忽視了高緯度的產品設計。

在拆分使用者故事的時候，我們需要去發散一下自己的思維：比如使用者在這個部分會去做什麼？怎樣才能提高使用者的體驗？使用者還有沒有其他的方法來完成這個步驟等等……

等大家發散了自己的思維之後，我們就會得到一個比較完善、有條理的使用者故事。

第三步：做好使用者故事的優先順序排列

既然我們的主幹使用者故事和更細化的使用者故事已經出來了，接下來就需要對這些拆分出來的使用者故事進行優先順序以及自上而下的排序，優先順序最高的使用者故事放在上面，並依次遞減。

第四步：溝通確認

使用者故事是需要和客戶/使用者以及團隊成員進行最終確認的，防止出現產品需求方面的偏差。確認完成之後，我們就需要排釋出計劃了，在協調好手中的時間、人力等各方面的資源後，將需要開發的使用者故事排為產品計劃，在接下來的時間內逐步交付。

對於專案團隊來說，使用者故事地圖能夠幫助團隊從使用者視角來考慮問題：

能夠幫助團隊更好地瞭解他們為什麼要構建軟體，以及軟體如何融入全域性。

除了一些罕見的例外，任何軟體產品都只是更廣泛的業務活動或客戶體驗的一部分，通常在與軟體互動之外開始和結束。軟體可能只是加速某些活動的某一部分，或者提供一種新的做事方式。規劃使用者旅程有助於團隊在更廣泛的背景下考慮使用者故事，發現遺漏或不必要的步驟，並創造新的產品創意。

避免線性思維。使用者故事地圖有助於優先順序劃分、故事拆分，併為釋出計劃提供重點。特別是，透過規劃一段旅程，然後在每個步驟中考慮故事，這樣故事地圖幫助團隊將使用者故事視為選項，而不是承諾。

將互動設計融入迭代交付。故事地圖提供了一個很好的框架，用於考慮使用者互動過程，並在此背景下繪製迭代版本和里程碑。這樣就更容易規劃互動設計工作，優先考慮與即將到來的里程碑相關的部分。

促進迭代交付。透過將相關故事分組在一起，利益相關者通常會看到，他們可以透過更簡單的可交付成果選擇來啟用某些操作，並將更復雜的故事推遲到以後的版本中。

總之，使用使用者故事地圖，就可以“既見樹木，又見森林”，考慮問題更全面，規劃交付更輕鬆，並引導以使用者的視角看待問題，提升軟體的價值，同時提升與使用者溝通的效率。

使用者故事地圖怎麼用？實踐才能出真知