在介紹 user story 之前，先簡單聊一下產品開發 / 迭代的過程。先前寫過一系列的〈如何改善產品？功能優化怎麼做？〉，其中的 step 1 & 2 分別是「收集意見」和「定義問題與目標」，但收集意見後，這些「意見」應該要長什麼樣子呢？定義問題與目標後，這些「問題」與「目標」又應該要怎麼展示呢？
也就是說，前文裡提到的「收集意見」和「定義問題與目標」都是「動作」與「過程」，那完成這些動作與過程後，PM 到底該怎麼展示具體的「成果」呢？
PRD（產品需求文件，Product Requirement Document）會是較常見的成果，裡面會包含要做這個產品 / 功能的背景脈絡、目標、產品 / 功能的架構與功能、操作流程等，PRD 裡面會有很多部分，而 user story 正是其中一個元素。
user story 就是「用直白易懂的語言，描述使用者（user）想要達到什麼目的」。
乍聽之下好像平凡無奇，甚至有可能會想說「每個產品 / 功能不就是這樣做出來的嗎？」、「user story 不是一個很理所當然的存在呢？有什麼好學的？」
是的，我也曾經是這樣以為的。但事情常常不是我想像的這麼簡單……
user story 為什麼重要
以自身經驗來說，user story 有這幾個重要性：
1. 幫助 PM 本身更探究需求的本質與出發點
2. 讓 PM 更確定每一個需求背後的目標
3. 幫助設計師更了解需求的脈絡「使用者到底碰到什麼痛點？」、「使用者到底想要解決什麼問題？」
或者換個角度來看，大家都知道上面這三件事情很重要 : PM 本來就該知道自己為何而做、要做出什麽產品，設計師也應該要了解需求背後的「真正需求」與真正要解決的問題。
但到底要怎麼做到這些事？user story 在此就扮演很重要的角色。
在這篇文章〈如何改善產品？功能優化怎麼做？step 2：定義問題與目標〉裡面有個例子，PM 收到老闆的抱怨，老闆說：「我覺得我們的 app 很難用耶，東西很難找啊」，接到這個意見後，就有很多可以延伸的問題，比如：
PM：「所謂的『難用』，是什麼意思呢？」
老闆：「就是…很難用啊！我要找東西都找不到！！」
PM：「是想要找什麼東西呢？」
老闆：「我們是在做影音平台，啊我之前看到這個貓的影片覺得很可愛，現在想找就找不到啊！」
PM：「那你現在是怎麼找到這個影片的？」
老闆：「也不算找到吧，我就是直接搜尋『貓』，然後滑了半天才找回來」
PM：「所以是想再找回來看一次嗎？」
老闆：「對啊，我就無聊想找來再看一下，但就找不到……」
PM：「是怎樣的找不到呢？因為剛剛不是有用搜尋嗎？」
老闆：「用搜尋是可以，但很浪費我時間啊，而且我前天看過這影片，不是應該會有個什麼看過的紀錄嗎？或者可能放在什麼地方啊！」
PM：「那老闆你原本是期待在哪個地方找到這個影片呢？」
老闆：「隨便什麼地方都可以，你們去設計啊，但一般不是會在觀看紀錄或什麼收藏影片區嗎？」
經過這番對話後，不同的 PM 可能會有不同的解決方式
A 做法：老闆有提到想要「觀看紀錄」或「收藏影片」嘛，那我們就來做這個功能吧
B 做法：老闆想要更快速找到他之前看過的影片，我們得來想想該怎麼達到這個期待
這裡倒不是說 A、B 誰對誰錯，畢竟產品開發還牽涉到很多因素，每個團隊與公司都有自己的風格，所以我也只敢保守地說，「一般情況下」B 會是比較保險且周全的做法。
A 做法：
優點和缺點其實一體兩面，優點是 PM 很快想出來對應的功能，所以通常也可以很快推動團隊將此功能付諸實現。如果 PM 真的很有 “product sense”，如此強勢主導之下，也不一定是壞事。
缺點就是這個功能不一定能解決用戶最原始的問題，或者可能有其他功能或方式可以更快甚至更適合地解決用戶問題，但因為 PM 剛開始就已經確立解法，團隊很可能也沒有機會討論其他可能性了。
B 做法：
優點是較能確保最後想出來的功能可以解決用戶最原始的問題，畢竟 PM 把用戶的原始目的列得很明確「想要快速找到之前看過的影片」，團隊（主要應該是設計師）就能去想出對應的交互流程與整套解決方式。
缺點則是整套過程較花時間，畢竟一個功能的出現，大致上需要經過拆解問題→思考解法→收斂→成型→定案。
不過這或許也不能說是缺點，因為如果採用 A 做法，且不幸地最後的功能沒有解決原始的問題的話，那反而更花時間。
要怎麼寫 user story
由於上面已說「『一般情況下』B 會是比較保險且周全的做法」，接下來就繼續介紹 B 做法。當 PM 想要列出「用戶的原始目的」與「用戶想要解決什麼問題」時，user story 就是一個很常見且實用的表述法。通常 user story 的「公式」會是這樣：
As a ___ (role), I want ___ (to take some actions), so that I can ___ (achieve some goals)
作為一個 ___（某個角色），我想要 ___（透過某個動作），所以我就可以 ___（達到某個目的）
繼續以上面的「老闆想要更快速找到他之前看過的影片」為例，對應的 user story 可能是這樣：
作為一個愛看影片的人，我想要更快速地找到我之前看過的影片，所以我就可以重新把它看一次
所以設計師或 PM 可以從這個敘述再去思考對應的做法，一個重點是「快速」讓用戶找到之前看過的影片，另一個重點則是快速讓用戶找到「之前看過」的影片。
user story 的延伸思考
1. User story 與大方向的吻合程度
user story 對於產品來說至關重要，因為它可以回答「這個需求為何重要」，但除此之外，PM 得再延伸思考的是：這個 user story 是否有符合原本產品的目標與願景？
繼續延伸上面的例子，用戶最終目標是「想重新把影片看一次」，但用戶達成此目標後，對產品有幫助嗎？這是公司做這個產品時，希望用戶去做的事嗎？
如果這個產品是 Youtube，那或許是個符合公司目標的 user story，因為粗略來說「用戶看影片」= 用戶會看到廣告 = 能為平台帶來營收。
但如果這個產品是 Netflix，而公司目標是在於留存率，且假設經過實驗證明，「用戶二刷影片的比例」跟「留存率」沒有正相關（也就是說，一看再看的用戶的續訂率也沒有比較高），那或許這個 user story 就不會是團隊想要主要解決的優先問題。
2. User story 是否為真正的 user story
這小標看起來有點玄妙，讓我娓娓道來（？）。不知道是因為 PM 工作做多了，還是本身有非常嚴重的「想解決問題」的傾向，很多時候在接到用戶反饋或抱怨時，我的第一個想法常常是「那我們就來做個 #$% 功能吧」，但經過各種慘痛教訓後（慘痛教訓雖然多樣化，但有個公式，就是「最後的功能並沒有解決原始問題」），學到的寶貴一課就是「追根究底」，我會努力壓抑自己「想直接跳過中間的發想過程、直接落到解法」的老毛病。
有時用戶也會犯類似的毛病，就是直接跟產品團隊許願說「我想要 #$% 功能」，這時 PM 的職責就是去問「為什麼」以及「不斷拆解」，而不是直接往下去想「怎麼做」。
舉例來說，我手上有個內部產品是公司的開發者團隊專用的 app store，也就是讓工程師可以把開發、測試中的 app 上傳到這個網站上，方便其他人測試或使用。大方向來說，這個 app store 的目的就是讓同事們可以有效率上傳並下載他們需要使用的 app。
某天接到一個用戶說：「我希望你們可以在我上傳 app 檔案時，新增一個 “description” 的欄位，讓我可以自由填寫內容。」如果根據這樣的敘述寫 user story，就會是：
作為一個 app 工程師，我想要一個 description 欄位，所以我就可以寫一些東西
但顯然這則 user story 還有些粗略，完全看不出個所以然對吧？所以會有很多延伸問題可以問，比如：
為什麼是 description 欄位？是想要在這個欄位寫什麼東西？而且「想要一個 description 欄位」並非動作，那只是用戶期望的結果，所以這邊也得再問更細才行。
回答這兩個問題後，user story 可以被優化為：
作為一個 app 工程師（某個角色），我想要在某個地方為我上傳的 app 加上一些 description（透過某個動作），所以我就可以註明一些 app 的資訊（達到某個目的）
但這還是有問題，用戶想要加什麼 description？想要註明什麼樣的資訊？
所以第三版的 user story 可能會是：
作為一個 app 工程師（某個角色），我想要在某個地方為我上傳的 app 加上一些檔案格式的資訊（透過某個動作），所以 QA 測試時就會知道哪個檔案是他要測的（達到某個目的）
但為什麼 QA 測試時會需要知道哪個檔案是他要測的？是要用什麼方式分辨？經過細問後，工程師終於給了更多資訊，所以我改了第四版的 user story：
作為一個 app 工程師（某個角色），我需要標註這個 app 是 ios 版還是 android 版，所以 QA 測試時就能很快找到他要測試的檔案類型（達到某個目的）
所以說到底，其實用戶並不一定是「想要一個 description 欄位」，一問再問之下，原來用戶需要的是「讓 QA 知道自己上傳的 app 是 ios 還是 android 作業系統」。
如果沒有好好地問「為什麼」、如果沒有好好地寫出一個追根究底的 user story，很可能團隊在收到第一個敘述「想要一個 description 欄位」後，就直接新增這個欄位了。但在歸納後，團隊的做法或許就會是「自動偵測用戶上傳的檔案格式，並給予對應的標籤，讓用戶更好識別」。
兩個做法固然都可以「讓工程師標註一些 app 的資訊」，但顯然前者並不方便，也跟大方向「有效率上傳並下載 app」不夠相符，畢竟用戶得自己填寫 description，且每個人填寫方式可能不一樣，前台展示出來就會很亂，其他用戶也無法很快地找出需要的資訊。
結語
舉了上述這些例子，雖然並非 100% 真實（礙於公司某些保密政策考量，不能完整重現），但場景類似，應仍有一些參考價值。我目前也只是一個 PM 職涯剛起步沒幾年的打工仔，原本以為 user story 就是「忠實轉述用戶的需求，讓設計師更能理解用戶在想什麼」就好，但真正寫起 user story 時，就發現還有好多隱藏的坑！
不過，目前自己仍是蠻享受於寫 user story 的過程！雖然很多時候需要一問再問，很怕用戶不耐煩，但能問出用戶真正的擔憂或疑慮，並且想出對應的解決方式，整個過程還是蠻讓人享受的，也會覺得自己做的事情真的有點價值、能幫助用戶解決問題！
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
