讀後感：產品管理流程中，使用者故事（User Story）常見的三種使用情境

1. 為什麼選這篇文章分享?

2. 作者為什麼要寫這篇文章?

3. 內容重點

4. 心得

為什麼分享這篇文章？

• 產品經理、UI/UX設計師常用的方法論：使用者故事 User Story
• 對使用者故事有個基本概念

作者想表達甚麼？

• 何謂使用者故事 User Story？
• User Story常見的三種使用情境
• User Story 常見問題

重點內容

什麼是使用者故事（User Story）？

• 是一種描述問題與需求的方式
• 「先討論問題/需求、再討論解法」的產品工作方式
• User Story 的建立方式

1. 建立的源頭從 User 來
2. 使用者研究與使用者訪談中得到的資訊來討論與整理。
3. 通常是在產品團隊已經有目標、想改善的指標/使用情境後

從使用者身上抓到的幾個重點要素，作為過渡到「實際解決方案」前的溝通工具。

• User Story 的形式通常為一句話：

1. As a ______, I want to ______, so that ______.

身為 ______，我需要一個方法來 ______，因為 ______。

• 使用者（who）

1. 可以加上形容詞、情境詞來描述
2. 除了實際使用產品的人之外
3. 有時候我們也會為我們自己寫 User Story —
4. 身為產品經理（或是公司內部的人）
5. 希望可以看到什麼數據、或是在後台手動做什麼事
6. 總之就是為那個使用者受詞解決問題、滿足需求。

• 需求（what）

1. 要什麼、做什麼
2. 盡量用「動詞」的形式表達

• 背後的原因（why）

1. 為什麼可能是想要看到的成果、想要得到的價值、對使者來說很重要的洞見
2. 盡量用一句話表達

User Story 的三種使用情境

• 建立 User Story 困難的地方在於
• 到底要寫得多細？怎樣才算是夠清楚？
• 在不同情境下會因為目的不同而有不同的作法。

使用情境１— 做中長期的優先級排序

• [ 溝通對象 ] 利益關係人、產品團隊
• [ 出現場合 ] 產品路線圖（Product Roadmap）、產品待辦清單（Product Backlog）
• [ 細節程度 ] 方向大而模糊
• 如果要處理的目標問題較大、還在非常初步的探索階段、還需要幾輪的探索或討論

1. User Story 的用途比較像是跟利益關係人與產品團隊建立共識
2. 確認優先級並決定要先處理哪一個問題/需求。
3. 當確認好方向與順序後，就可以持續針對那個問題/需求去做研究
4. 並拆解成更小的 User Story 方便產品團隊開始發想解決方案。

使用情境２ — 過渡到「實際解決方案」前的溝通工具

• 同一個問題或需求可能會有好幾種不同的解決方案
• [ 溝通對象 ] 設計師、產品團隊
• [ 出現場合 ] 產品需求文件（PRD）
• [ 細節程度 ] 中等
• 確保這時候的 User Story

1. 足夠清晰到心中可以浮現出幾種不同的解決方案
2. 不會太細節到我們只能看到單一的功能樣貌。

• 發想的一個開始，讓大家可以開始構思畫面、背後的邏輯，用一句簡單的話，在心中埋下一棵種子。

每個人心裡的畫面可能會有所不同

• 主要發想解決方案的人通常會是設計師

1. 產品經理、工程師或其他利益關係人也可能會適時參與討論
2. 在討論階段，當有異議、或是設計太發散時，可適時檢視產品設計是否有符合最一開始定義的 User Story 的情境、是否有機會解決使用者的問題。

使用情境３— Sprint Planning、產品或功能的最小品質控管、上線管理的單位

• [ 溝通對象 ] Scrum Team、QA、利害關係人
• [ 出現場合 ] 產品需求文件（PRD）、專案管理工具中的 Scrum/Kanban Board
• [ 細節程度 ] 範圍小且細節
• 當解決方案已經確認，功能細節夠清晰
• 在 Sprint Planning 時：可以選擇將功能切分成更小的 User Story。

1. 方便規劃跟估時、估點數，決定哪幾個 User Story 可以在下個 Sprint 中完成
2. 方便工程師開發、QA 驗收。

• 另一種作法則：不去延伸與切細 User Story 本身

針對每個 User Story 列出 Acceptance Criteria（驗收標準）或是 Deliverables（可交付的成果） 作為最小顆粒單位

對於開發資源較少、時間較趕、流程較彈性的團隊

1. User Story 本身就足夠作為驗收單位
2. 亦即可以幫助使用者達到某個目的與需求就算是完成

如果產品團隊規模較完整

1. 想要讓工作流程更精細與嚴謹，提供工程師與 QA 明確的規格（Spec）會更好。

• 上線管理的部分（與Sprint Planning 很像）

1. 主要是讓整個團隊知道接下來要上的版本包含哪些功能與改動
2. 同時用「人話」告訴商業團隊、利益關係人們下個版本我們可以讓使用者或客戶達成哪些事情。

不同團隊會有不同的作法

• 只在 (1)(2) 中使用

等解決方案確認就直接寫詳細的規格書。

• 只在 (2) 中使用

1. 最早期排序時就直接直白地描述問題或需求
2. 最後期等解決方案確認就直接寫詳細的規格書

• 介於 (2)(3) 之間

1. 第一個版本的 User Story 是為了讓產品團隊能夠好好思考解法
2. 因為產業成熟、解法直白，常常可以直接延伸與轉譯成開發的功能細節與驗收標準。

• 從頭到尾都沒有寫過 User Story

直接從問題、使用情境下手來討論解決方案，然後寫功能需求給工程師。

User Story 常見問題

• User Story 是 PRD、Spec 嗎？No

1. 他可以是 PRD 中的一部分，是討論產品解法時的一個過渡工具
2. 在討論完解決方案與功能後，還是會需要寫下詳細的 Spec 給工程師來實作。

• User Story 要寫多細？

取決於你在跟誰對話：根據不同的時間點、目的、溝通對象，會有不同的細節程度

1. 大故事包含許多小故事，小故事又包含更多更小的故事
2. 在某些情境下，你可能必須將對話「收攏」到較高的層級。

• 只要團隊覺得好溝通、能夠建立共識就夠
• 在《使用者故事對照 User Story Mapping》章節「岩石分解」，針對「規模」提出分類方式：

1. 商業觀點：幫助企業達到某種商業成果的故事
2. 使用者觀點：滿足某個需求的故事。
3. 開發團隊觀點：花幾天時間即可建造及測試的故事

• User Story 由誰來產出？不一定

1. 看團隊的分工方式，有可能是產品經理、設計師、甚至是工程師
2. 看誰是發起專案的人就由誰來寫、主導討論

如果是產品經理從其他單位收到的需求、並發起這個專案，就由產品經理寫；

如果是設計師在做使用者研究時發現的洞見，就由設計師來寫；

在乎這件事情的人來產出並引導團隊一起討論；

有些團隊會有一個 User Story Mapping 的會議或工作坊：

1. 拿出便利貼，讓整個產品團隊的人一起來發想與討論
2. 甚至有人會在排序優先級的階段邀請客戶、使用者一起參與。

• 每次有新的需求、或是做新功能時都一定要寫 User Story 嗎？不一定

1. User Story 就只是一個工具、一種敘述事情的方法
2. 像是系統層面的問題、只是要解一個 Bug、解法已經非常明確的情境下可能也不太適用。

• 近年來也有人在詬病 User Story

拆解方式中需要太多假設，不夠符合產品團隊的需求。

個人心得

• Use story跟User Journey Map差別

「從使用者的行為找出關鍵點」的概念：都使用「故事線」當主幹

• Use story

1. 目的在從使用者的操作行為裡找到各種功能、並排出優先順序
2. 可以探討使用者想要什麼功能、重要的先開發、達成團隊共識
3. 沒辦法確定這樣做下去後使用者是否滿意

• User Journey Map

1. 關心使用者在各階段互動的情感並想辦法改良、提升滿意度
2. 只會告訴你使用者因為什麼原因所以覺得不高興
3. 無法提供讓使用者高興的解法

• Use story用途多多

1. 產品路線圖（Product Roadmap）
2. 產品待辦清單（Product Backlog）
3. 產品需求文件（PRD）
4. 專案管理工具中的 Scrum/Kanban Board

• Use story的廣度與深度可根據想解決的問題調整

1. 大專案由許多小專案組成，小專案可以根據細節再分成更多節點
2. 主線任務分出支線，支線還會有小旁枝