在產品快速迭代的時代，使用者故事（User Story）成為了「產品開發過程」不可或缺的一部分。

就算沒看過，應該多少也都有聽過這個詞，甚至你可能在日常開發中常常碰到，只是你不知道那個叫做使用者故事而已。

它們幫助團隊理解使用者的需求，並確保產品能夠真正解決到使用者的「痛點」。

接下來將探討如何撰寫有效好讀的使用者故事，並提供一些實際的故事範例，且針對 Side Project 的情境會多加著墨做介紹。

怎麼寫故事？

撰寫使用者故事的方法並不複雜，只需要遵循一些「基本原則」 — 清晰表達 某某人 想要做到 XXX 。

使用者故事通常以一個簡單的格式呈現，包含了三個主要元素：角色、需求和理由。

以此「通用格式」溝通，有助於團隊間的大家清晰地理解使用者的需求，接下來就來介紹到底如何寫個故事吧！

User Story

經典的的使用者故事「模板」如下：

作為一個 [角色]，我想要 [需求]，以便 [理由]。

比方說

作為一個 [社交媒體使用者]，
我想要 [快速找到我的熟人朋友]，
以便 [節省查找時間並快速開啟聊天對話]。

像以上這樣的故事，清楚地表達了「使用者想要做到」的事，且傳達了背後的動機。能幫助我們開發團隊聚焦在使用者的需求層面上，而不是僅僅關注功能的實現。（甚至可以說使用者故事中，完全沒有提到「功能實現細節」）

為 Side Project 寫故事

Side Project 由於資源有限，我們必須更加精確地了解目標使用者的需求，就算今天是製作讓自己開心的 App 也是一樣。業餘時間終究相當有限，因為寫故事比開發功能要快多了，而透過使用者故事的撰寫，接著做條列整理，可以先挑「重要」的來做。

上次已經介紹了這次 Side Project 想做的事，據此先整理了 5 個「想達成」的需求：

• 基本記帳操作可以單手獨立完成
• 可以簡單編輯 / 刪除每一筆記帳
• 希望可以共享記帳本
• 可以有記帳成就系統（遊戲化）
• 希望可以能夠分析支出和收入，並提供財務建議

以上這 5 項需求都想實現，不過因為開發時間不夠，只好出絕招了！

這個絕招正是「刪去大法」，最後只挑選 3 個最重要的「核心需求」，試著套用以上規則，寫成使用者故事看看吧。

• 作為一個 [重度記帳軟體的使用者]，我想要 [單手完成記帳操作]，以便 [節省記帳時間且避免忘了記帳]。
• 作為一個 [重度記帳軟體的使用者]，我想要 [快速編輯 / 刪除記帳]，以便 [節省記帳修改時間]。
• 作為一個 [重度記帳軟體的使用者]，我想要 [共享記帳紀錄]，以便 [跟家人一起查看目前為止的收支表來規劃財務]。

說個「好」故事

知道怎麼寫使用者故事了，但說到底，怎樣才算是個好故事？

我們可以參考以下幾點來寫出比較好的使用者故事：

• 真實性：確保故事基於真實的使用者需求，而不是假設或推測。通常會藉由使用者訪談、問卷或是真實數據的彙整，來產生使用者故事。
• 可測量性：故事應該能夠被量化，以便在開發後能夠評估其是否成功。
• 簡潔性：避免過於複雜的故事，簡單明瞭的故事更容易被團隊理解和實施。太複雜的「大故事」應該要拆分成小故事。

以上提供的使用者故事範例，都盡量參考了以上的「好故事準則」，若有不當或是寫得不好，還請不吝指出 👍

結語

礙於篇幅與專業關係，這邊就不提及真實開發的情況下，使用者故事究竟從何而來？而要如何收集資料才會足夠「真實」？這背後涉及比較專業的產品領域相關的知識，有興趣的讀者可以自己再深入研究囉。

這次使用者故事就簡單介紹到這邊，在 Side Project 中透過清晰的需求格式和持續的迭代，讓我們的每一分每一秒都花得有價值，透過使用者故事讓專案更有可能成功！

REF

• https://uxcam.com/blog/user-stories-product-management/