為什麼要做產品設計？
為了解決TA（Target Audience，目標族群）的需求問題。
為什麼要做User Story？
是為了能運用簡單俐落的工具，與客戶進行更有效及快速的溝通。
而在做產品設計的前期規劃時，最常碰到的問題便是「該如何定義」，而要寫得多細、誰來撰寫也是團隊中經常面對的日常。
什麼是User Story
User Story（使用者故事）是在軟體開發和產品設計常用的工具之一，且是敏捷開發裡最小的單位。
通常是一段簡單的敘述，以客戶、使用者的角度去撰寫，產出有價值的功能，大致上其實可以說是客戶的需求。
而角色身分會影響使用者故事，假設今天要設計一支剪刀：
給小朋友使用的剪刀，和一般成人的剪刀會相同嗎？
拿來剪布的剪刀，和剪食物的剪刀差別在哪裡？
剪頭髮的剪刀，為何還要分大小呢？
或者，如果只是要拆開包裝，為什麼要用剪刀而不是其他工具？
Photo by Margaret Jaszowska on Unsplash
所以在開發產品前，先以 User Story定義出客戶的模樣，需要考量使用者的身分、動機、限制，藉此做出更合乎使用者需求的設計。
另外需注意的是，避免太過詳細的功能敘述，例如「產品使用C#開發」或「需加上websocket即時雙向協定」等，因為User Story是僅僅描述對使用者有價值的功能，在此階段規劃技術規格是不合適的。可以思考的反而是這些技術對於商業會產出的價值是什麼，再重新使用User Story的規範寫出來。
User Story 的形式
通常為一句話：
As a ______<Actor>, I want to ______<Action>, so that ______<After effect/Outcome>.
身為 ______<角色>，我需要一個 ______<行為>，這樣就可以 ______<原因>。
使用者Who：
用戶角色代表一種用戶類型（而不是單個用戶），需求會從用戶角色的角度來出發
可以加上形容詞或情境詞來描述。
需求What：
要做什麼，盡量可以使用動詞表達。
原因Why：
想要得到的成果或價值，也可能是對使用者來說很重要的洞見，並盡量以一句話來表達。
User Story的使用情境
- 使用情境１— 做中長期的優先級排序
- 使用情境２ — 過渡到「實際解決方案」前的溝通工具
- 使用情境３— Sprint Planning、產品或功能的最小品質控管、上線管理的單位
User Story範例
| ＃ | 案例 | 題目描述 |
|---|---|---|
| 1 | 登入頁面的改善 | 身為使用者，我需要更簡潔地登入會員的流程 |
| 2 | 購物車清單的改進 | 身為消費者，我需要明確顯示購物車商品增減數量、移除的功能，以便我更好操作購物介面 |
| 3 | 後臺管理 | 身為管理者，我需要上傳新菜單的功能，這樣我就可以自行更新菜單 |