1. 為什麼選這篇文章分享?
2. 作者為什麼要寫這篇文章?
3. 內容重點
4. 心得
從使用者身上抓到的幾個重點要素,作為過渡到「實際解決方案」前的溝通工具。
身為 ______,我需要一個方法來 ______,因為 ______。
每個人心裡的畫面可能會有所不同
針對每個 User Story 列出 Acceptance Criteria(驗收標準)或是 Deliverables(可交付的成果) 作為最小顆粒單位
對於開發資源較少、時間較趕、流程較彈性的團隊
如果產品團隊規模較完整
等解決方案確認就直接寫詳細的規格書。
直接從問題、使用情境下手來討論解決方案,然後寫功能需求給工程師。
取決於你在跟誰對話:根據不同的時間點、目的、溝通對象,會有不同的細節程度
如果是產品經理從其他單位收到的需求、並發起這個專案,就由產品經理寫;
如果是設計師在做使用者研究時發現的洞見,就由設計師來寫;
在乎這件事情的人來產出並引導團隊一起討論;
有些團隊會有一個 User Story Mapping 的會議或工作坊:
拆解方式中需要太多假設,不夠符合產品團隊的需求。
「從使用者的行為找出關鍵點」的概念:都使用「故事線」當主幹