牆上掛著滿滿的待辦事項，大家你一言我一句地為團隊產品貢獻自己的想法與點子！
上述是當我們談起設計思維，甚至是敏捷時，頭腦中會浮現的景象。然而，當待辦事項在不同成員齊力產生出不同抽象程度的工作項目時，試問我們要如何有效地從中找出最重要的事情，並且準時地交付給客戶？
User Story Mapping 是管理使用者故事的一種有效技巧，不僅能夠協助團隊逐步地構建產品的待辦項目，也能夠用來整理已經開始迷航的待辦項目黑洞。它具體有以下好處：
- 以使用者為出發點，透過使用者旅程逐步具體化使用者故事;
- 確保所有參與者圍繞在同一個產品目標與主題上;
- 具有全局觀的排序，產生可執行的釋出計畫;
- 簡單易懂的可視化待辦事項結構;
- 引起討論，促進協作。
環境與工具
- 便於走動與張貼的環境，可以善用團隊常用的戰情室；
- 白報紙數張(如果不夠大可以接在一起)或白板一個；
- 建議人數 <= 8 人/組；
- 白板筆 x 三種顏色 ；
- 便利貼一包 x 三種顏色；
- 計時器；
- 安全可開放討論的氛圍。
流程
步驟一：由召集者或者是產品管理者，說明此次的目標，並且確保所有參與者了解 (~ 10 分鐘)：
a. 此次目標的受眾與他們的樣貌
b. 此次目標的重要性與其商務上的價值
c. 具體的產品目標背景描述
步驟二：基於使用者視角，由領域專家或團隊發想完成目標的關鍵活動
此時僅討論關鍵的活動，並不需要仔細思考使用者的每一個可能發生的步驟，以 計畫旅行住宿 為例，關鍵活動可能為：
a. 搜尋住宿旅館
b. 預定住宿
c. 付費刷卡
d. 收到行前通知
步驟三：進一步描述並且詳舉關鍵活動所需的步驟
此時需要為每一個關鍵活動考慮基於產品背景所需的步驟，接續前例，以 _預定住宿_為例，使用者步驟可能為：
a. 使用者註冊
b. 使用者收到確認
c. 使用者登入
d. 填入訂房必須資訊
e. 預覽訂單
f. 送出預定
步驟四：為每個步驟構建需要的使用者故事
於每個步驟下方條列(如文章封面圖)出所需要的使用者故事。使用者故事可以採用 身為 WHO，我需要 WHAT，以便達成 WHY 這樣的簡單句型即可。
使用者故事的重點在於有效地將該需求的 WHY、WHO、WHAT 具體且清楚地描述出來，以便建立團隊的基礎認知(如果真有些需要立即注意的事項，也可載於其中，但切莫各種立即)。
- 此時有些功能也能夠透過一些簡單的UI來描述
步驟五：基於重要性，為每個步驟下的使用者故事進行排序
步驟六：建立釋出計畫
一些注意事項
整個使用者故事地圖，由左至右代表者使用者旅程的起點到終點; 由上至下代表著旅程描述的抽象度與使用者故事的重要性，越來越低;
抽象度每降一層，建議尋求足以代表使用者的專家的反饋;
盡量保持構建使用者故事地圖參與者的背景多樣性，建議但不僅限於以下角色加入： a. 產品擁有者 (Product owner);
b. 開發團隊;
c. 該產品領域專家;
d. UI/UX;
e. 測試人員;
f. 利害關係者;在排序使用者故事時，應該避免樣樣重要的情況，可以透過比方 MosCow 的方式來進行排序;
參與構建的人員不建議大於 8 人。
關於使用者故事的分支故事與例外，可以在完成由左至右的使用者故事發想後，再進一步針對每一個垂直方向的議題，進行補充。在日後開發過程中，也可以透過市場回饋與實際狀況，進行添加。只有一件事要記得的是，更動待辦事項務必按照團隊所議題的方式進行即可。
一些關於使用者故事的資訊與備註，也能透過後續的電子系統，或者當進一步降解故事成為可執行任務時載明即可。保持使用者故事地圖乾淨且易於針對焦點產生討論是相當重要的一件事。
後記
使用者故事地圖一開始便將所有的利害關係人聚集在一起，透過討論與協作逐步地完成各抽象度安排。這樣的作法有別於以往產品的功能規劃模式 — 不同的抽象度由不同團隊完成，或者是不同面向由不同團隊完成。這樣大大地降低了後續整合與想法磨合的衝擊，也減少了穀倉式討論的時間浪費。讓團隊的每個人對焦於同件事，並且有一致的認知。這對於凝聚團隊，並且提升效率有顯著的幫忙。此外，充分且多面向的討論，加深團隊每個人對於使用者的了解，從而能夠構建對使用者更有價值的產品。