使用者故事地圖 User Story Mapping

什麼時候該用它？

當你有一大堆 User Story 但不知道怎麼安排成版本的時候。傳統的 backlog 是一維清單（排優先級），User Story Mapping 加上第二維度（使用者活動流程），讓你同時看到「廣度」和「深度」。

• MVP 定義：從一堆功能中切出「最小但完整」的第一版
• 版本規劃：決定 v1 / v2 / v3 各自包含什麼
• 團隊對齊：讓工程師和設計師「看到」使用者的完整旅程，而非只看到個別 ticket
• 大功能拆解：一個大 Epic 怎麼切成可以分批交付的 Story

框架結構

二維結構

橫軸（左到右）：使用者活動流程

按照使用者完成任務的時間順序排列。例如電商購物：瀏覽商品 → 查看詳情 → 加入購物車 → 結帳 → 收貨 → 售後

縱軸（上到下）：實現深度

每個活動下方，從上到下按重要性排列功能：

• 頂部：最基本的實現（Walking Skeleton）
• 中間：完整的實現
• 底部：進階和差異化功能

切版本的方法

在地圖上畫水平線，線上方的所有功能 = 一個版本。

瀏覽    查看    加購    結帳    收貨
─────────────────────────────────── v1（MVP）
商品列表  商品照片  加購按鈕  基本結帳  出貨通知
─────────────────────────────────── v2
分類篩選  評價區   願望清單  多元支付  退貨申請
─────────────────────────────────── v3
推薦系統  AR試穿   比較功能  分期付款  滿意度調查

關鍵原則

• 先走完一遍再加深 — v1 應該覆蓋整個流程的最基本版本，而非把某一步做到極致
• 每個版本都是「可用的產品」 — 不是半成品，是功能少但完整的體驗
• 使用者看得到的才算 — 技術架構、後端重構不放在地圖上

來源與歷史

• 2005：Jeff Patton 在部落格文章中首次描述了這個方法
• 2008：在多場 Agile Conference 演講中推廣，引起敏捷社群關注
• 2014：出版《User Story Mapping》一書，系統化整套方法論
• 至今：成為敏捷團隊版本規劃的標配工具，Miro 和 FigJam 都有專用模板

真實案例：線上教育平台的 MVP 切版

一個台灣線上教育新創要做「企業內訓平台」，初始需求超過 80 個 User Story。

User Story Map 的橫軸： 管理者建課 → 指派學員 → 學員上課 → 做測驗 → 看成績 → 發證書

切版結果：

結果：v1 在 6 週內上線，拿到 3 家企業客戶的付費合約。客戶的回饋直接影響了 v2 的優先級（原本排在 v3 的「批次指派」被提前到 v2，因為客戶說一個一個指派 500 個學員太痛苦了）。

使用步驟

Step 1：定義使用者角色和目標

選一個核心使用者角色，定義他要完成的主要目標。一次做一個角色。

Step 2：列出活動流程（橫軸）

從左到右，按時間順序列出使用者完成目標的所有活動。用便利貼寫在白板頂部。

Step 3：展開每個活動的 Story（縱軸）

每個活動下方，列出實現該活動的具體 User Story，從最基本到最進階。

Step 4：畫版本分界線

從上到下畫水平線切版本。問自己：「線上方的功能組合起來，使用者能完成整個流程嗎？」如果能 → 這就是 MVP。

Step 5：驗證和迭代

把 Story Map 拿給使用者或 Stakeholder 看，確認流程沒有遺漏、MVP 的定義合理。

這樣做 vs 避免這些

這樣做

• 用實體便利貼或 Miro — 需要能移動和重新排列
• 讓工程師一起參與 — 他們能即時回饋技術可行性和工作量
• 先畫 Walking Skeleton — 確保 v1 走完整個流程，而非只做一半
• 跟 User Journey Map 搭配 — Journey Map 找痛點，Story Map 規劃解法

避免這些

• 不要把技術任務放上去 — 這是使用者視角的地圖，不是工程任務板
• 不要試圖把所有 Story 都放進 v1 — MVP 的意義就是「最小」
• 不要一個人畫 — Story Mapping 是團隊活動，獨自做會有盲點
• 不要畫完就不更新 — 每個 Sprint 結束後回來看地圖，標記已完成的部分