書名：《使用者故事對照 User story mapping 》
作者：Jeff Patton, Peter Economy
譯者：楊仁和
出版社：O’reily/ 碁峯圖書資訊
先說結論：我覺得對UX設計、軟體產品開發專案管理相關工作的人，是一本很好的入門。
這本書的內容並不困難，困難的或許是如何將其落實在實際產品的開發階段中，對於產品企劃或是將市場需求帶入開發階段的PM/ PO應該都會遇到書中所言的幾個問題。如果你也遇到了下面幾個問題，那麼這本書會是個指引：
1. 你是專案經理/ 產品企劃，但是總不知道如何整理需求，需求又多又亂，而且不知道如何有效地呈現給開發團隊進行討論？
2. 你不是專案經理/ 產品企劃，但是每次他們跟你溝通時都沒有效率，讓你無法理解產品整體的全貌，你希望可以改善這件事情？
3. 身為UX新手設計師，想要更了解產品的使用者以及他們會如何使用你的產品，並將其整理成有效的使用者故事？
透過整理這本書的內容，在本文中會介紹以下幾項概念：
1. 何謂使用者故事？它在產品開發階段中扮演的角色為何？
2. 使用者故事應該如何被整理，有效地發揮作用？
3. 使用者故事的練習
我預計於下篇的筆記中提及更多關於完整使用者故事圖像、系統性的使用者故事、如何切割大型需求與實際在產品開發的應用等概念。
首先，「使用者故事」指的是一個使用者會如何使用某產品的各種情境。在產品開發中，整理使用者故事以更瞭解客戶的需求以及產品的優劣勢，進以安排開發時程產出成品。
常見的錯誤使用者故事通常會如此呈現：
「我們產品的使用者應該是25歲左右，喜歡逛街的女性，所以我們應該增加女性購物專區。」
如果至少有一點產品開發的基礎，那麼正確的使用者故事應該會改寫為：
「身為一個25歲，喜歡在週末時間逛街的30k以下小資女，我想要一個專屬於女生可以快速瀏覽平價服飾的區塊，這樣我可以更快速的找到我想要買的衣服。」
使用者的故事樣板便生成了，往往我們會將它寫在一張卡片（便利貼）上。
▪ as a [type of user], I want to [do something] so that I can [get some benefit]
最簡單的使用者故事處理方式：
- 先寫下任何關於產品所浮現的想法，記錄在便利貼上，再解釋它是什麼
- 將重要的便利貼放在較高的位置
- 問題定位於想要達成什麼結果，而不是輸出什麼
- 描述你的客戶與使用者，加上一兩個相關的句子
- 記錄下人們會使用這個產品來從事的活動類型
- 將上述卡片整理成故事流的順序
（舉例而言：誰先建立了清單，所以誰會收到清單後有下一個行動） - 開始分割大型的行動，將其分解成細節步驟（誰會在這階段做什麼、出錯的話會怎樣？）
一個產品會有非常巨量的使用者故事，可以想見的產品不只一個使用者，而一個使用者對於產品功能的期望也不會只有一個。重要的是迷失於細節之前，先想辦法將思考的寬度加寬。然而這並不代表我們應該理所當然接受所有的使用者需求，因而優先排序（Prioritize）變得格外重要。
在書中，開發產品的核心需求稱為分解岩石。
我們必須找到產品的核心價值，核心價值指的是聚焦在你希望系統之外發生什麼，以便決定要在系統之內安排什麼。並透過討論，將所有的使用者故事卡片依照重要性的順序排列，因而應可以整理出對應出目標成果的所有的便利貼，基於時間流與重要順序得到「產品釋出版本規劃」。
若要讓計畫準時完成，必須如上述所言將產品的骨架塑造出來：透過使用者故事卡片排出最核心而功能簡易的故事流。產品的功能應該是以漸增策略慢慢發展（這也對應到Lean Startup之所以強調MVP（最小可行產品）的原因）這本書舉了一個我個人非常喜歡的例子：達文西在畫蒙娜麗莎時絕對不是先畫左上角、畫完後到左下角，再者到右上角的順序，而是先打底稿、確定背景後加上人物五官，背景上色到最後細節調整。
因而作者建議將使用者卡片以下面方式進行整理 — Backlog佈局
- 開局：技術上具有挑戰性或風險的事情，重要的核心功能
- 中局：填補並完成功能，增加可以支援使用者選擇的材料，實做一些商業規則，測試產品效能
- 終局：精煉釋出版本，讓它看起來有吸引力且也能有效率地發揮效用
以上，至少快速的整理了「什麼是使用者故事」「使用者故事該如何撰寫」以及「針對產品，我們該如何分解大型使用者故事」三個概念。接著為了讓上述概念能更容易地被理解，我想用Spotify的例子來解釋。
如果現在要設計一款如Spotify一樣的線上音樂串流軟體，那麼使用者故事卡片可能會是：
身為一個搖滾樂愛好者（使用者），
我想要有搖滾樂歌單與世界搖滾樂曲目排名，
如此我才可以馬上就找到我最喜歡的音樂曲目。
如上的使用者故事卡片可以generalize為：
身為一個特定音樂類型的愛好者（使用者），
我想要有特定音樂類型的歌單與特定音樂類型的排行榜，
如此我才可以馬上就找到我最喜歡的音樂曲目。
當然，除了使用者之外，一個產品要涵括的面向很多。舉例而言：
身為一個Product owner，
我想要有能夠追蹤特定用戶聽了哪些歌曲的記錄，
如此我才能夠利用Data science去推薦他其他相同類型的歌曲。身為一個音樂平台的管理編輯（Admin），
我想要有一個快速選取歌曲上架成歌單的後台，
如此我才能夠更有效率的把歌單完成後推播至平台首頁。
我們可以把上面三個使用者故事卡片，依照故事流的方式整理出來：
我們需要先有歌曲與清單，才能夠讓使用者可以找到自己喜歡的歌曲來聆聽，當使用者累積了足量的歌曲紀錄時，這些紀錄才能夠被有效的利用資料分析完成推薦機制的技術。
當然雖然說這三個需求都很重要，我們依然要找到這個產品本身的核心優勢，在這個例子裡可以反問是什麼讓Spotify變得特別，而可以與KKbox或是其他音樂串流軟體競爭呢？
大多數的用戶應該都會回答「Spotify的智慧歌單」讓人可以不用特別尋找，便能探索自己喜歡類型的歌曲。若是如此，則擁有「特定音樂類型的歌單與排行榜」就變成是這個產品必須要優先研發的功能之一。（如果有看過Business Model Generation的話，應該可以理解Canvas上的「優勢」定義）
不過，以產品開發的角度來看「我想要有特定音樂類型的歌單與特定音樂類型的排行榜，
如此我才可以馬上就找到我最喜歡的音樂曲目。」並不是一個非常明確的使用者故事，而可以被再分割。
1. 特定音樂類型的歌單，是自動因為使用者的行為而產生的嗎？
1.1 音樂庫是如何被分類的呢？歌單會是由當中隨機抽選歌曲產生嗎？
2. 特定音樂類型的排行榜，是怎樣被排名出來的呢？聆聽的次數嗎？
2.1 是引用哪一個音樂的排行榜呢？
2.2 是使用平台自己的聆聽次數計算機制嗎？
因此可以把使用者卡片寫得更詳細一點。
身為一個特定音樂類型的愛好者（使用者），
我想要有配合我過去聽的歌曲而產生的類型歌單，
如此我才可以馬上就找到我最喜歡的音樂曲目。身為一個特定音樂類型的愛好者（使用者），
我想要有某音樂類型的隨機推薦歌單，
讓我可以依照我的心情聆聽不同種類的音樂。身為一個特定音樂類型的愛好者（使用者），
我想要不限音樂類型而是區域劃分的排行榜，
讓我可以知道世界與我選擇的地區流行什麼樣的歌曲。身為一個特定音樂類型的愛好者（使用者），
我想要有特定音樂類型的排行榜，
讓我可以知道喜歡聽這個類型的其他使用者都在聽什麼。
如果依據作者在書中的Backlog整理的話，我們可以按照研發功能的困難度以及優先性把上面四項整理如下：
1. 開局：（重要的核心功能）
如上所言，「配合我過去聽的歌曲而產生的類型歌單」才是Spotify勝出的關鍵，且此功能會用到較多的開發人力做研發，因而應該優先處理。
2. 中局：（填補並完成功能）
目前是根據我聽過的歌曲來作為推薦，但是如何讓我快速地探索我喜歡的類型，至少必須有音樂庫讓我可以隨搜隨聽。因而建立不同類型的歌曲音樂庫，便成為了基本滿足需求的功能「某音樂類型的隨機推薦歌單」與「特定音樂類型的排行榜」
3. 終局：（精煉功能且更使其更有吸引力）
大部分的使用者會在意其他人在聽什麼音樂，因而若能透過地區限制與簡單的計數，將聆聽次數比較高的歌曲放入排行榜，取前20名，則完成「不限音樂類型而是區域劃分的排行榜」
當然這只是概念的解釋，因而實際上就開發而言會有差異。
例如，我個人經驗應是音樂庫應該先被建立完成，不管是用連結Youtube的方式或真的將音樂上傳至雲端伺服器中，音樂排行榜與特定類型歌單就開發而言應不是困難的項目，透過將資料分類與放上標籤，由系統自動選出20名即可完成，最困難也最需要被加強開發的功能英式推薦機制，需要強大的資料分析能力。
這篇筆記應該可以讓入門的人更了解使用者故事在產品開發的定義與角色，我認為它也不是一個難懂的專有技術名詞。但認識很容易，有很多人卻會不小心誤解他的概念。因而在下篇，我將提及更多關於使用者故事會碰到的問題、系統性的使用者故事、如何切割大型需求與實際在產品開發的應用等概念。
-續-
閱讀資料：
- http://uoid.drhhtang.net/Home
- http://blog.xdite.net/posts/2014/05/29/from-idea-to-product-user-story
- https://ruddyblog.wordpress.com/tag/%E4%BD%BF%E7%94%A8%E8%80%85%E6%95%85%E4%BA%8B%E5%B0%8D%E7%85%A7/
- http://gds.hpx.tw/service-manual/agile/writing-user-stories/
* 有任何問題，歡迎在留言區直接回饋讓我知道，文章是個人的筆記與心得整理，可能有誤。歡迎討論。
