大家在做產品管理的時候，一定很熟悉「用戶故事」這個東西。它簡單明瞭，像是「作為一個用戶，我想要做某件事，這樣我就能得到什麼好處」，聽起來很直覺，大家都會用。可是，問題是，這種傳統用戶故事其實有點不夠用，甚至會讓產品開發變得模糊不清。

今天我想跟你聊聊，為什麼我們應該停止只用傳統用戶故事，改成用兩種類型的用戶故事，這樣才能讓產品做得更好、更有價值。

傳統用戶故事的問題在哪？

先講講傳統用戶故事長什麼樣子：

「作為一個 <用戶類型>，我想要 <做某件事>，這樣我就能 <得到好處>。」

這種寫法看起來很簡單，也很容易理解，大家都喜歡用它來描述需求。但問題是，這樣的故事經常把「用戶想要什麼」和「系統要怎麼做」混在一起，沒有清楚分開。

舉個例子：

「作為用戶，我想查看交易歷史，這樣我可以追蹤我的花費。」

這句話裡面，確實說出了用戶想要的東西，但它同時也隱含了系統要提供「查看交易歷史」這個功能。這樣一來，團隊在做優先排序或設計時，可能會搞不清楚到底是要解決用戶的哪個痛點，還是只是在做系統功能。

這就是為什麼光靠傳統用戶故事，常常會讓產品開發變得模糊，甚至浪費時間在不重要的功能上。

產品需要兩種類型的用戶故事

為了解決這個問題，我們其實需要把用戶故事分成兩大類：

1. 用戶價值導向的故事（Customer-Focused Stories）

這類故事的重點是「用戶真正想要什麼？為什麼他們想要？」它幫助團隊了解用戶的動機和目標，而不是只看表面功能。

像這樣：

「作為第一次使用App的用戶，我想要有簡單明瞭的付款流程，這樣我就不會因為複雜而放棄購買。」

這種故事讓大家聚焦在用戶的需求和感受，能幫助設計師和產品經理思考怎麼做才能讓用戶體驗更好。

2. 系統功能導向的故事（System-Focused Stories）

這類故事則是從技術和系統的角度出發，描述系統必須完成的具體任務，確保技術團隊知道要怎麼實現用戶價值。

例如：

「系統需要提供交易歷史查詢功能，並且支援日期篩選，讓用戶能快速找到特定交易紀錄。」

這種故事讓開發團隊知道細節，能夠把用戶需求拆解成可執行的技術任務。

這樣分開有什麼好處？

為什麼要這樣做？原因很簡單：

• 讓目標更清楚：用戶價值故事告訴我們「為什麼要做這件事」，系統功能故事告訴我們「怎麼做這件事」。這樣一來，團隊不會混淆，大家都知道自己的重點在哪。
• 促進溝通更順暢：產品經理、設計師和開發者各自專注自己的部分，彼此溝通時也更有依據，不會因為用詞不清搞得大家霧裡看花。
• 提升產品品質：當我們知道用戶真正的需求，並且系統能夠精準地實現功能，產品自然會更符合用戶期待，使用體驗也會更好。
• 優先順序更合理：有了清楚的用戶價值故事，團隊能根據用戶痛點來決定先做什麼，避免花時間在沒那麼重要的功能上。

怎麼開始做？

如果你現在還在用傳統用戶故事，不妨試試下面幾個步驟：

1. 重新審視現有用戶故事：看看哪些是純粹描述用戶需求，哪些是系統功能，試著分開寫。
2. 和團隊溝通這個概念：讓大家知道為什麼要分兩種故事，讓產品經理、設計師和開發者都能理解這樣做的好處。
3. 在產品規劃時同時建立兩種故事：先寫用戶價值故事，明確用戶的目標，再拆解成系統功能故事，確保技術能支持。
4. 持續優化：隨著產品進展，不斷調整用戶故事，保持清晰和有價值。

產品更有戲

說到底，傳統用戶故事雖然簡單，但太過模糊，容易讓產品開發失焦。透過分成「用戶價值導向」和「系統功能導向」兩種用戶故事，我們能更清楚地知道「為什麼做」和「怎麼做」，讓產品更符合用戶期待，也讓團隊合作更有效率。

所以，別再只用傳統用戶故事了，試著用這兩種類型的故事來幫助你的產品，會讓你發現開發過程更順暢，產品也更有競爭力。