透過數據分析與質化研究找出產品的問題點

Jasper Shia
Gogolook 設計團隊的學習筆記
6 min readMay 8, 2018

當產品表現不如預期時,PM與設計師如何利用數據分析的資料找到問題點,並搭配質化研究找到問題可能的原因?

去年底 Whoscall 在巴西推出了新功能「Hero」,推出後我們發現此功能成功完成設定的用戶數偏低,因此PM與設計師一起透過數據分析搭配易用性測試與用戶訪談,試圖找出問題的根源,改善此功能的設定完成率。

什麼是 Hero ?

Whoscall Hero

先簡單介紹一下 Hero 這個功能,Hero 是以「保護家中長輩避免被詐騙」為目的而推出的 Whoscall 新功能,當家中長輩誤接詐騙電話時,其他的家庭成員就會立即收到通知。

這次主要測試的內容是「保護者」與「被保護者」雙方建立連結的流程。「保護者」透過 Whoscall 將對方設定為要保護的對象,當對方同意之後,就能夠將兩方連結在一起,當「被保護者」接起詐騙電話時,「保護者」就會立刻收到通知。

啊不是裝 Whoscall 了,怎麼還會接詐騙電話?

其實用戶的行為通常並不一定會完全照著我們想像的走,有些用戶即使看到疑似詐騙電話的提醒,還是會接起電話。所以 Hero 對用戶來說是第二道防護,當用戶不小心陷入詐騙集團的話術時,透過家人的提醒對他們來說是最有可能跳出詐騙情境的方式之一。

從數據分析出發

PM 觀察用戶使用 Hero 的數據後發現,在進入 Hero 功能頁面的用戶中,大約有 27% 的用戶送出了邀請,但在這之中只有約 7% 的人成功建立了連結。

從數據先找到了一些蛛絲馬跡

除了觀察流程中每個關鍵頁面的點擊率之外,我們仔細觀察成功建立連結的用戶在數據上更細微的行為,這些成功連結的用戶中,有部分的用戶在送出邀請與接受邀請之間的時間間隔很短暫,因此我們假設這些用戶使用的情境很可能是「保護者發出邀請後,直接拿對方的手機來按下接受」。這的確也符合我們預期的目標族群,「保護者」可能是對於手機較熟悉的族群,他們直接拿了「被保護者」的電話來按下確認。

那麼,其他人在送出邀請之後到底發生了什麼事?

當發出邀請的用戶送出邀請之後,只能等待對方接受邀請,這是在系統之外發生的事情,從數據上我們只能知道有問題,但無法確切知道到底發生了什麼事,因此我們在台灣與巴西進行了易用性測試與簡單的訪談,試圖找出可能的問題。

在台灣進行易用性測試

為了節省研究的時間與成本,雖然這個產品是在巴西推出,但我們認為用戶在介面操作上的問題應該沒有太大的差別,因此我們選擇在台灣進行介面的易用性測試。

根據我們假設的使用情境,我們將測試的對象分為兩種類型,一種為「保護者」,我們假設這類型的用戶可能是對於數位產品較熟悉,年紀大約25–50歲之間,並且與家人關係較為密切的用戶。而另一種用戶則是「被保護者」,這類型的用戶可能年紀較長,對數位產品操作上較不熟悉的用戶。

針對兩種不同類型的測試對象,我們規劃不同的任務讓用戶進行測試。第一類型「保護者」,我們請他們試著針對指定的電話號碼送出邀請,測試結果我們發現這類型的用戶並沒有太多操作上的問題,這與我們之前獲得的數據基本上也是符合的。

而另一類型的「被保護者」用戶,我們請這些「被保護著」試著從收到邀請簡訊開始,先安裝 Whoscall後再接受對方的邀請。

測試實驗結果也是如預期…「超 多 問 題 」,要不熟悉數位產品的用戶完成這一連串的設定簡直就是一場災難,對這些用戶而言,要瞭解這個功能、自己安裝Whoscall、註冊登入並成功找到邀請按下確認簡直是不太可能獨力完成的任務。

透過 Whatsapp 遠端訪談巴西真實的用戶

除了台灣的易用性測試之外,我們也透過 Whatapp 訪談真正使用 Whoscall Hero 的巴西用戶,也有一些不錯的發現,其實「保護者」在送出邀請後,通常會透過自己熟悉的管道(電話、Whatsapp、當面說明),幫助對方暸解此功能,並請對方接受邀請。

這與我們原本預想的方式不太一樣,我們原本擔心「被保護者」無法了解這個功能,所以透過一些方式試圖在流程中說明這個功能,但其實大部分的「保護者」已經幫我們做完了這件事,或許盡量縮短接受的流程才是更適合的方式。

總結

從這次 Hero 的研究結果來看,不難發現為什麼成功建立連結的人數會那麼少,在建立連結的過程中有許多門檻造成建立連結困難。尤其是「被保護者」又是較不熟悉數位產品的用戶,他們必須從完全不了解 Whoscall ,到安裝 Whoscall ,並同時要理解 Whoscall 本身的功能與 Hero 的功能,對這些用戶而言是太困難的任務。

對我來說,量化的用戶數據就像搭飛機的時候在高空中看到的點點燈火,質化訪談則是實際降落到這些亮著燈光的家中看看到底發生了什麼事。就像這次的經驗,PM從數據分析中先找到可能的問題點,設計師在訪談之前就能夠針對這些問題點規劃相關的問題,在訪談的時候也能更深入的探討那些問題點,我認為在改善設計的流程來說是很不錯的方式,在研究完成後與開發的團隊成員分享研究的結果也能讓團隊成員有更明確的改善方向。

至於最後改了什麼呢?…等我改好再跟大家分享囉!

感謝你觀看這個分享,如果有任何想法也歡迎在底下留言!覺得這篇文章有用的話,可以拍手一下或拍很多下(你知道medium最多可以拍 50 下嗎 )

延伸閱讀

--

--