如何撰寫用戶故事（附例子及驗收準則）

用戶故事是從用戶角度對某項功能的簡短描述：「作為[某類用戶]，我想[目標]，以便[原因]。」在它之下，你要寫下驗收準則，即幾項具體的條件，必須全部成立，該故事才算完成。每個故事都應細小到能一次過建造和測試，而且準則的寫法要讓任何人都能核實。

用戶故事是由敏捷軟件團隊推廣開來的，但當你獨自用 AI 應用程式生成器建造時，它同樣有用。一個好的故事，就是一個好的提示。

格式

用戶故事由三個部分組成：

作為**[誰]，我想[什麼]，以便[為何]**。

• 誰是某一類具體的用戶：首次到訪的訪客、付費會員、診所接待員、管理員。而不是「用戶」。
• 什麼是他們想做的事，用他們自己的話說。而不是畫面如何運作。
• 為何是他們所重視的結果。這是人們最容易略過的部分，卻能防止你建造出錯誤的東西。

例子：

作為健身室會員，我想用手機取消課堂預約，以便候補名單上的人可以取代我的位置，而且我不會被收取缺席費。

「為何」告訴你一些「什麼」沒有說明的事：它必須能在手機上運作，而且候補名單和缺席費規則也牽涉其中。

驗收準則

故事說明的是想要什麼，驗收準則則說明何時算完成。它們應該具體到讓兩個人都能同意每一條是否通過。

撰寫驗收準則的常用方式是假如／當／則（Given / When / Then）：

• 假如存在某個起始情況
• 當用戶做某件事
• 則出現這個結果

以上述健身室預約故事為例：

1. 假如我的預約在 12 小時以後，當我點擊取消並確認，則該預約被移除，我會看到「預約已取消」。
2. 假如我取消了預約，而該課堂有候補名單，當取消儲存後，則候補名單上的第一位會獲得該名額，並收到電郵。
3. 假如預約在 12 小時之內，當我點擊取消，則我在確認前會看到將收取逾時取消費用。
4. 假如我使用的是手機寬度的螢幕，則取消按鈕無須左右捲動即可看見。

純粹的核對清單也可以，只要每一項都能測試。「取消很方便」是無法測試的；「從預約列表取消最多只需兩次點擊」則可以。

逐步操作：撰寫一個好故事

第一步：從真實的用戶和真實的問題出發

選定一類用戶，以及他們今天遇到的一個難題。如果你曾經訪問客戶，就使用他們的說法。「我總是忘記取消，結果被收費」比「加入取消功能」是更好的起點。

第二步：寫出一行的故事

填入範本。如果你寫不出有說服力的「以便」，請先問這項功能是否真的有需要。

第三步：加入三至六條驗收準則

先涵蓋主要的成功情況，再涵蓋重要的變化：不同角色、空白狀態、限制、錯誤。如果你寫了超過六條，這個故事很可能太大了。

第四步：註明範圍以外的內容

一行字就能省去許多來回討論：「範圍以外：付費課堂的退款；管理員代會員取消。」它能防止故事在建造過程中不斷膨脹。

第五步：對照 INVEST 檢查

INVEST 是衡量好故事的常用核對清單。一個好故事應該是：

你不必為每個故事逐一評分。當某個故事感覺不對，而你想知道原因時，它最有用。

好與壞的例子

如何拆分過大的故事

過大的故事往往是項目停滯的原因。常見的拆分方法包括：

• **按用戶角色。**會員取消自己的預約；員工則可以取消任何人的預約。
• **按流程中的步驟。**瀏覽課堂；預約課堂；收取提醒。
• **先處理簡單個案。**先取消免費課堂；收費和退款留待之後的故事處理。
• **按數據變化。**先支援一個地點，之後再支援多個地點。
• **先順利路徑，後錯誤情況。**先令它正常運作，然後再加入課堂已滿、通行證過期等情況的處理。

每個拆分後的部分，仍然應該是用戶能夠使用並察覺到的東西。

把用戶故事用作提示

附有驗收準則的用戶故事，非常接近為 AI 應用程式生成器而設的好提示。它為 AI 提供了誰、什麼、為何，以及完成的定義。每條訊息發送一個故事：

作為健身室會員，我想用手機取消課堂預約，以便候補名單上的人可以取代我的位置。 驗收準則：

1. 「我的預約」中每個預約都有取消功能，並有確認步驟。
2. 在課堂開始前超過 12 小時取消，只會移除該預約。
3. 不足 12 小時時，確認前顯示「將收取 5 元逾時取消費用」，並將該費用記錄在預約上。
4. 如果課堂有候補名單，第一位候補者會獲得該名額，並收到電郵。
5. 在手機寬度的螢幕上正常運作。 範圍以外：退款、員工代會員取消。 請先建造此功能，然後在預覽中逐條檢查準則，並告訴我哪些已通過。

你也可以要求 AI 根據粗略的構思草擬故事，然後自行編輯：

以下是我的應用程式構思：[兩到三句話]。請為第一版撰寫用戶故事，按用戶類型分組，每個故事附有 3 至 5 條假如／當／則形式的驗收準則。請標示哪些是推出所必需的，哪些可以延後。

務必閱讀並編輯結果。AI 不了解你的用戶，你才了解。

驗收準則同時可作為你的測試計劃。故事建造完成後，你應親自逐條走查每項準則。我們關於推出前測試你的應用程式的指南，正是以此為基礎。

用戶故事與其他文件的關係

• 產品需求文件描述整個產品：問題、用戶、範圍。用戶故事則是其中的詳細組成部分。參閱如何用 AI 撰寫 PRD。
• 錯誤報告描述的是已建造的某個故事中出現的問題。參閱如何撰寫良好的錯誤報告。
• MVP 是能交付核心價值的最小用戶故事集合。參閱什麼是 MVP。

常見錯誤

• **「作為用戶……」**過於含糊。請寫出實際的用戶類型。
• **略去「以便」。**沒有原因，就無法做出合理的取捨。
• 寫出解決方案，而不是需要。「我想要一個下拉式選單」在還未有人思考之前，就已經鎖定了設計。
• 無法測試的準則。「簡單」、「快速」和「直觀」都只是願望，不是準則。
• 實際上是史詩的故事。「管理我的帳戶」其實是十個故事。
• **預先寫好所有故事。**詳細撰寫接下來的幾個故事；其餘的則保留為一行的摘要，直到需要時才展開。

Mythex 中的用戶故事

在 Mythex 中，計劃模式很適合把構思轉化為故事：代理會在編輯任何內容之前先討論方案。故事準備好之後，切換至建造模式並貼上，每條訊息一個故事。每次完成後，你可以使用 /test 在預覽中逐步點擊，檢查流程；如果某次回覆的方向有誤，也可以使用回復至此點把它撤銷。參閱文件中的有效的提示，以及我們關於為 AI 應用程式生成器撰寫提示的指南。

用戶故事核對清單

• 寫明具體的用戶類型
• 描述的是需要，而不是設計
• 包含真實的「以便」原因
• 有三至六條可以測試的驗收準則
• 至少涵蓋一項邊緣情況或錯誤
• 說明範圍以外的內容
• 細小到能一次過建造和測試
• 建造後逐條核實準則

常見問題