產品管理流程中，使用者故事（User Story）常見的三種使用情境
去年寫了《如何撰寫產品需求與規格文件？給產品經理的問題、心法與實作小撇步！》後這篇文章歷久不衰，到現在還是每個月都有流量。我當時在文章開頭有提過「如何寫 User Story？要寫多細？誰寫？」這個問題，但在文章內沒有好好回答，因此一年過後，想要根據在不同產品團隊工作後的經驗，分享我的實際作法與想法。
前情提要：我待的產品團隊都以優化現有產品、服務現有使用者與客戶為主，比較沒有做全新產品的經驗，所以我的經驗可能只適用於特定情境 😐
【文章目錄】
- 什麼是使用者故事（User Story）
- User Story 的三種使用情境
- 其他關於 User Story 的常見問題▍什麼是使用者故事（User Story）？
使用者故事（User Story）是一種描述問題與需求的方式。如果長期有在看我們文章的讀者，可能會發現我們時不時就會強調「先討論問題/需求、再討論解法」的產品工作方式，而 User Story 在這之中就可以扮演一個很好的角色。
User Story 的形式通常為一句話：
- As a ______, I want to ______, so that ______.
- 身為 ______，我需要一個方法來 ______，因為 ______。
三個空格內分別要填寫的內容為：
- 使用者：誰（who），可以加上形容詞、情境詞來描述
- 需求：要什麼、做什麼（what），盡量用「動詞」的形式表達
- 背後的原因：為什麼（why），可能是想要看到的成果、想要得到的價值、對使者來說很重要的洞見，盡量用一句話表達
第一點使用者的部分，除了實際使用產品的人之外，有時候我們也會為我們自己寫 User Story — — 身為產品經理（或是公司內部的人）我希望可以看到什麼數據、或是在後台手動做什麼事。總之就是為那個使用者受詞解決問題、滿足需求。
第二點需求，想了解「用動詞描述需求」的優點，歡迎參考這篇文章：
User Story 的建立方式
既然叫做 User Story，建立的源頭當然是從 User 來，也就是使用者研究與使用者訪談中得到的資訊來討論與整理。
User Story 通常是在產品團隊已經有目標、想改善的指標/使用情境後，從使用者身上抓到的幾個重點要素，作為過渡到「實際解決方案」前的溝通工具。
▍User Story 的三種使用情境
建立 User Story 困難的地方在於，到底要寫得多細？怎樣才算是夠清楚？在不同情境下會因為目的不同而有不同的作法。
我知道在一些嚴謹的團隊中會用 Activity（活動）、User Task（使用者任務）與 User Story（使用者故事）來描述與分類不同層級的問題、需求或動作（參考文章），不過我自己沒有認真試過那樣的分法，因此盡量用我熟悉的名詞跟情境來分享。
使用情境１— 做中長期的優先級排序
[ 溝通對象 ] 利益關係人、產品團隊
[ 出現場合 ] 產品路線圖（Product Roadmap）、產品待辦清單（Product Backlog）
[ 細節程度 ] 方向大而模糊如果要處理的目標問題較大、還在非常初步的探索階段、還需要幾輪的探索或討論，則 User Story 的用途比較像是跟利益關係人與產品團隊建立共識、確認優先級並決定要先處理哪一個問題/需求。
在某些團隊中這個東西就叫做 Epic（史詩），只是有時候也會用 User Story 的形式來描述它。
當確認好方向與順序後，就可以持續針對那個問題/需求去做研究，並拆解成更小的 User Story 方便產品團隊開始發想解決方案。
使用情境２ — 過渡到「實際解決方案」前的溝通工具
[ 溝通對象 ] 設計師、產品團隊
[ 出現場合 ] 產品需求文件（PRD）
[ 細節程度 ] 中等這應該是我最常使用的情境了！
同一個問題或需求可能會有好幾種不同的解決方案，因此只要確保這時候的 User Story 足夠清晰到我們心中可以浮現出幾種不同的解決方案、又不會太細節到我們只能看到單一的功能樣貌就行。
每個人心裡的畫面可能會有所不同，但這就是發想的一個開始，讓大家可以開始構思畫面、背後的邏輯，用一句簡單的話，在心中埋下一棵種子。
主要發想解決方案的人通常會是設計師，不過產品經理、工程師或其他利益關係人也可能會適時參與討論。在討論階段，當有異議、或是設計太發散時，就可以適時回去看看這個產品設計是否有符合最一開始我們定義的 User Story 的情境、是否有機會解決使用者的問題。
使用情境３— Sprint Planning、產品或功能的最小品質控管、上線管理的單位
[ 溝通對象 ] Scrum Team、QA、利害關係人
[ 出現場合 ] 產品需求文件（PRD）、專案管理工具中的 Scrum/Kanban Board
[ 細節程度 ] 範圍小且細節當解決方案已經確認，功能細節夠清晰，在 Sprint Planning 時就可以選擇將功能切分成更小的 User Story。一方面是方便規劃跟估時、估點數，決定哪幾個 User Story 可以在下個 Sprint 中完成；另一方面也方便工程師開發、QA 驗收。
在產品開發團隊中，另一種作法則是不去延伸與切細 User Story 本身，而是針對每個 User Story 列出 Acceptance Criteria（驗收標準）或是 Deliverables（可交付的成果） 來作為最小顆粒單位，我其實是很同意這一點的。
對於開發資源較少、時間較趕、流程較彈性的團隊，也許 User Story 本身就足夠作為驗收單位，亦即可以幫助使用者達到某個目的與需求就算是完成；但如果產品團隊規模較完整、想要讓工作流程更精細與嚴謹，提供工程師與 QA 明確的規格（Spec）會更好。
針對上線管理的部分，其實跟 Sprint Planning 很像，主要是讓整個團隊知道接下來要上的版本包含哪些功能與改動，同時用「人話」告訴商業團隊、利益關係人們下個版本我們可以讓使用者或客戶達成哪些事情。
＊小總結
這樣看起來，User Story 不但有不同的顆粒大小，還會在產品設計與開發過程中演變成不同的樣貌與細節程度，好像有點太複雜了。
以我自己的工作經驗中，不同團隊會有不同的作法：
- 團隊一：只在 (1)(2) 中使用，等解決方案確認就直接寫詳細的規格書。
- 團隊二：只在 (2) 中使用，最早期排序時就直接直白地描述問題或需求、最後期等解決方案確認就直接寫詳細的規格書。
- 團隊三：介於 (2)(3) 之間，第一個版本的 User Story 是為了讓產品團隊能夠好好思考解法，但因為產業很成熟、解法很直白，所以常常可以直接延伸與轉譯成開發的功能細節與驗收標準。
- 團隊四：從頭到尾都沒有寫過 User Story，直接從問題、使用情境下手來討論解決方案，然後寫功能需求給工程師。
備註：這邊的不同團隊並不是指不同公司，而是有時候在同一間公司中，不同的產品團隊、或解決不同區塊的產品問題時，就會有不同的工作流程與寫文件的方式。
寫這篇文章的同時，我們也很好奇大家平常工作會在哪些情境中使用到呢？歡迎匿名填寫這份超簡短問卷來投票：《產品三眼怪讀者調查 - 你最常用的 User Story 使用情境？》完整的產品上線規劃流程可以參考這篇文章：
▍其他關於 User Story 的常見問題
Q1. User Story 是 PRD、Spec 嗎？
不是。他可以是 PRD 中的一部分，是討論產品解法時的一個過渡工具。在討論完解決方案與功能後，還是會需要寫下詳細的 Spec 給工程師來實作。
Q2. User Story 要寫多細？
不一定。呈上一個段落，根據不同的時間點、目的、溝通對象，會有不同的細節程度。只要團隊覺得好溝通、能夠建立共識，也就足夠。
在《使用者故事對照 User Story Mapping》一書「岩石分解」的章節中也有針對「規模」提出一種分類方式：
・從商業觀點來看，規模合適的使用者故事是 - 幫助企業達到某種商業成果的故事。 ・從使用者的觀點來看，規模合適的使用者故事是 - 滿足某個需求的故事。 ・從開發團隊的觀點來看，規模合適的使用者故事是 - 花幾天時間即可建造及測試的故事。
大故事包含許多小故事，小故事又包含更多更小的故事，取決於你在跟誰對話。在某些情境下，你可能必須將對話「收攏」到較高的層級。
Q3. User Story 由誰來產出？
不一定。有可能是產品經理、設計師、甚至是工程師，看團隊的分工方式。
我待的團隊中，通常看誰是發起專案的人就由誰來寫、主導討論。如果是產品經理從其他單位收到的需求、並發起這個專案，就由產品經理寫；如果是設計師在做使用者研究時發現的洞見，就由設計師來寫。
在一些團隊中，則會有一個 User Story Mapping 的會議或工作坊，拿出便利貼，讓整個產品團隊的人一起來發想與討論，甚至有人會在排序優先級的階段邀請客戶、使用者一起參與。
不過更多的時候是大家都好忙、都沒空好好思考，所以就有空、在乎這件事情的人來產出並引導團隊一起討論。
Q4. 每次有新的需求、或是做新功能時都一定要寫 User Story 嗎？
不一定。User Story 就只是一個工具、一種敘述事情的方法。
而像是系統層面的問題、只是要解一個 Bug、解法已經非常明確的情境下可能也不太適用。當然也是有人把機器當成使用者來寫 User Story — 《What my backend and API user stories look like》。
除此之外，近年來也有人在詬病 User Story 的拆解方式中需要太多假設，不夠符合產品團隊的需求。以下分享其他類似功能的工具做為參考資料。
設計思考 — Need Statement、POV
- [USER] needs to [USER’S NEED] because [SURPRISING INSIGHT].
- Stanford d.school Toolkit — Point-of-View Madlib
- Alpha Team Rookie’s Guide
Jobs To Be Done (JTBD) — Job Story
- When _____ , I want to _____ , so I can _____ .
▍結語
我是個超愛寫文件的人，但每次都要提醒自己，產品團隊的工作是交付有價值的產品，而寫文件、開會都只是為了做好產品而溝通價值與成果的過程。
所以要不要寫 User Story（或任何形式的文件）、怎麼寫、誰寫，只要能創造產品的影響力、讓團隊可以更快速地朝著一致的方向前進，就是一個有用的好工具。
如果你想從零到一了解使用者故事，推薦《使用者故事對照 User Story Mapping》這本書！
寫這篇文章的同時，我們也很好奇大家平常工作會在哪些情境中使用到呢？歡迎匿名填寫這份超簡短問卷來投票：《產品三眼怪讀者調查 - 你最常用的 User Story 使用情境？》
沒有相關經驗的人也可以填寫，並且敲碗想聽的文章主題或內容唷～～～謝謝你的閱讀！如果有任何回饋或有興趣的主題，歡迎留言給我們 📒
如果單純想給我一點鼓勵，請給我 1–10 個拍手；
如果覺得文章對你有點幫助，請給我 11-30 個拍手；
如果想看更多產品文件相關的分享，請盡情長按拍手（max 50）讓我們知道 👏🏻想要持續追蹤我們的最新文章，請記得追蹤「產品三眼怪實驗室」(◉◉◉)！
我們每週末都會認真更新文章唷！千萬別錯過了～