為什麼要做這個產品功能?使用者想要的到底是什麼?論 User story 的重要性

為什麼要做這個產品功能?使用者想要的到底是什麼?論 User story 的重要性

在介紹 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 的過程!雖然很多時候需要一問再問,很怕用戶不耐煩,但能問出用戶真正的擔憂或疑慮,並且想出對應的解決方式,整個過程還是蠻讓人享受的,也會覺得自己做的事情真的有點價值、能幫助用戶解決問題!

 

本文轉貼自:MH 原文連結

本站所有文章未經事先書面授權,請勿任意利用、引用、轉載。