使用者故事 User Story

用使用者角度描述他想完成什麼，以及為什麼。

先用一句話理解

用使用者角度描述他想完成什麼，以及為什麼。

打個比方

不是說『做按鈕』，而是說『店員要快速查訂單，才能回覆客戶』。

什麼時候會遇到

把產品需求拆成工程任務前。

再往深一點看

User story 的格式通常是「身為 [角色]，我想要 [行為]，以便 [目的]」，這個結構強迫你在寫需求時保留使用者的視角，而不是直接跳到技術解法。它在 PRD 和工程任務之間扮演橋梁：PRD 說明整個功能的背景和目標，user story 把這個目標拆成一個個有意義的小單位，再由每個 user story 附上 acceptance criteria 讓工程師知道實作邊界。一個寫得好的 user story 讓你在開始寫程式之前就能問：「如果只做這一件事，使用者能不能從中得到真實的價值？」

舉個例子

你在 Linear 上建立一張 ticket：「身為訂閱用戶，我想要在帳號設定頁看到目前的訂閱方案與到期日，以便決定要不要升級。」接著附上驗收標準：頁面要顯示方案名稱、金額、下次扣款日，以及「管理訂閱」連結，工程師從這張 ticket 就能清楚知道要做什麼，不需要再問一輪。

常見誤解

- 只寫工程工作（「新增搜尋 API」、「建訂單資料表」），沒有寫是誰要用、要做什麼、為什麼——工程師就算做完了，也不知道有沒有解決對的問題。
- 一個 user story 塞太多功能，變成「身為店員，我要能搜尋訂單、修改訂單、匯出報表，以便管理日常業務」——這是三個 story，拆不開就很難估時程、也很難定驗收標準。
- 沒有搭配 acceptance criteria，只有一句 user story，工程師做的和客戶想的完全不同，驗收時才發現。