實習公司最近在做產品規範，提出了採用用戶故事地圖的模式管理開發產品，從中瞭解了一些，簡單談談我對用戶故事地圖的理解
一、用戶故事地圖簡介
用戶故事這個詞源於敏捷，什麼是產品設計中的用戶故事？
就是以用戶能自我代入的方式，設計產品，用產品講述用戶的故事。你上網去查，肯定會得到的解釋大多解釋都是：
“描述對用戶有價值的功能，好的用戶故事應該包括角色、功能和商業價值三個要素。用戶故事通常的格式爲：作爲一個<角色>，我想要<功能>，以便於<商業價值>。”
這樣的描述對嗎？對！但是太狹隘了。
用戶故事首先應該是一個種思維，即故事思維，是運用故事的元素進行思考和設計，以求解決某種問題，達到特定效果的思維。在用戶故事設計中，核心是要通過故事來傳遞信息，引起共鳴，解決問題。
故事地圖是一門在需求拆分過程中保持全景圖的技術 ——《用戶故事地圖》
二、用戶故事地圖結構
Epic史詩，theme故事籃子，userstory故事
例如一個郵件系統的例子：
三、故事地圖步驟
1. 召集到3-5名對產品非常熟悉的人員參與。3-5人聽上去像是個魔法數字，實際上是的。因爲更少的人意味着你無法獲得足夠的建議，而更多人則會因爲討論和協調降低會議效率。
2. 使用靜默頭腦風暴模式，讓每個人在便籤紙上寫下自己認爲重要的“所要做的事情”也就是 用戶任務（user task）。每個人都用同樣顏色的便籤來書寫自己的用戶任務描述，這個階段不要互相討論。一旦大家都基本完成了準備，讓每個人輪流大聲讀出自己的內容，並把便籤紙全部放置在桌面上，這時如果出現重複的內容就可以省略掉：
- 根據你的產品規模，這個過程可能需要3-10分鐘的時間；你可以觀察大家的行爲來判斷是否需要停止。
- 基本上每張便籤都會以一個動詞開頭，如：發送郵件、創建聯繫人、添加用戶等。
- 這些便籤組成了一級用戶故事，Jeff Patton稱爲用戶任務（user tasks），它們組成了用戶故事地圖上的 “行走的骨骼” （the walking skeleton）部分。
- 這時可以提示參與者：我們只用了很少的時間就完成了需求的收集過程，而且有些內容你可能沒有想到，而其他人幫你想到了。
3. 然後，讓大家將桌面上所有的便籤進行分組，將類似的任務分爲一組，其他的的類似
- 這個過程最好也讓大家採用靜默模式進行，因爲這樣做會更快。如果發現重複的內容，就略過
- 基本上分組會很容易完成
- 這時同樣觀察每個人的行爲，判斷大家是否已經做完，基本上這個過程需要2-5分鐘
4. 選擇另外一個顏色的便籤，對每個組進行命名，並貼在每組便籤的上部
5. 對這些分好組的便籤進行排序，一般按照用戶完成操作的順序，從左到右擺放
- 如果大家無法決定順序，那麼順序可能沒有那麼重要（明顯）。
- 這一組便籤，Jeff Patton稱爲 用戶活動 （User Activities）
- 這時你的地圖應該類似於
6. 現在，按照 “行走的骨骼” 用戶行爲 這行開始講述用戶故事，確保你沒有遺漏任何用戶行爲和用戶任務。這時一般由組織者進行講述，其他人提出意見，甚至可以讓最終用戶來參與討論。
7. 這時，我們已經完成了用戶故事地圖的基本框架；可以在每個用戶任務下面添加更加細節的 用戶故事（User Stories）了。這時仍然建議使用靜默頭腦風暴的模式來進行第一輪用戶故事的產生，同時藉助如Persona和Scenario等方式協助完成這個過程。一旦你完成了用戶故事的創建，就可以開始劃定你的 發佈計劃（Releases）了
- 一般我習慣在第一個發佈中只選擇每個用戶任務的2-3個用戶故事。這對於幫助大家排定優先級和範圍將很有幫助。
- 基本上我們不必使用用戶故事的標準句法（As a …）來書寫這些故事，因爲每張便籤都處於我們的地圖的特定位置，大家很容易識別其所處的場景和角色。
8. 最後，針對第一個發佈的所有用戶故事進行分解，確保我們的第一個發佈越小越好，基本上你需要保證在1-2個迭代後就可以發佈你產品的第一個版本(MVP)
MVP是指可以產生預期成果的最小產品發佈
MVP:最小可行方案是指可以產生預期成果的最小發布方案
————《用戶故事地圖》
四、用戶故事價值與作用
1.既見樹木又見森林
2.記錄
3.團隊之間的高效溝通