cover_whoscall android.png

2018 ~ 2019

Built For Trust
 
Whoscall 長年致力於陌生號碼辨識體驗與技術,我們希望透過科技和設計得力量,
為社會和世界帶充滿新任的溝通網絡。
 
Challenge
  • 2018 ~ 2019:重新對焦 Whoscall Android 核心價值,與建立定期用戶研究機制,根據研究結果逐步提升用戶滿意度(NPS)。

  • 影響團隊信任研究成果,與協助團隊將研究結果成為優化產品的依據,並且指導其他設計師進行研究。

  • 主導多場社內工作坊,並且指導其他設計師舉辦工作坊。

  • 建立 Whoscall 插畫視覺風格。

Outcome
Whoscall Android
 

✔  NPS +15%

✔  定期用戶量化研究(並且作為設計師研究 Lead & 產出研究 SOP)

✔  針對研究執行相對應的優化

✔  Whoscall 視覺風格制定與規劃

✔  主持工作坊

Role

Whoscall Android Lead Product Designer, Researcher, Workshop host

AARRR - Revenue

在 Whoscall Android 團隊是負責 Growth Hacker 中的末端 Revenue,在這個步驟除了與公司獲益息息相關以外,其實更重要的是顧好產品品質,確認市場對產品的看法。

 

層層下來後 Revenue 才有可能會提高,所以我們做的不單單只是提高 IAP 訂閱率,更多的是顧好產品的健康指數與各種類型的優化。

AARRR.png
Quantitative Regular User Research

從 2018 年底開始,逐步規劃 Whoscall Android 定期使用者量化研究計畫,希望從過去於 Google Play 或是 CS 系統被動追蹤用戶意見,調整為主動每一季度做一次量化用戶研究。

 

我們使用 NPS 作為主要確認產品健康度的指標,如果當期有新的優化功能,

也會作為確認用戶優化滿意度的工具,除了基本的 Typeform 系統問卷結果觀測外,我規劃了交叉分析問卷的方式,讓問卷可以更活用,了解更細膩的用戶行為。

透過這樣的機制,歷經一年,在下方逐一介紹的系列優化後,

NPS 從原本的 19.8% 一路進步到 34.7%。

 
research 01.png

為了能夠更精確地了解用戶的行為,除了發放問卷外,我也主導了將 Typeform 系統綁定 UUID 的規劃,希望在綁定用戶 UUID 後,可以透過數據追蹤用戶滿意度的走向(SQL),以及更多用戶行為的細節,以幫助產品團隊優化 Whoscall Android 的體驗與技術。

以上用戶研究的交叉分析方法,以及綁定 UUID 的方式,皆有製作成 SOP 的流程文件,以便其他 PMs & Designers 學習以及套用

research sop.png
Regular User Research Impact
Call Dialog Search Slow

研究中最多用戶抱怨的就是辨識來電結果的彈窗太慢,這個實際上是一個台灣電話來電降速的問題(VoLTE),每一家電信都有這個問題,為了解決這個問題,我們優化了彈窗的介面,

以及更新辨識資料庫的頻率,讓用戶在感受上有加快的效果。

1. Improve Call Dialog User Interface

在彈窗介面上,我們做了 AB testing 用了三個實踐的組別放量去比較,

看哪一種方案用戶等待來電辨識的時間,最接近 Whoscall 系統辨識的平均時長。

  1. 實驗組一,我們使用了 Loading 動畫在視覺上讓用戶體感上過的比較快。

  2. 實驗組二,我們使用了交替不同的文案,告知用戶系統正在辨識哪個步驟。

  3. 實驗組三,我們結合了一和二兩組的效果。

​最後結論是實驗組一用戶停留在 Call Dialog 的時間最久,也就是說,用戶願意等待系統辨識的時間最長,由此可證明,視覺感受可以減緩用戶 Search slow 的體驗,在此之後 Search slow 用戶研究時抱怨比例下降了 8%

 
search slow.png
2. Redesign Offline DB Update Page

​從數據中我們發現,辨識速度降低的另一個原因是,

用戶並沒有定期更新辨識的資料庫,而這個號碼資料庫每週都會更新。

 

也就是說當其最新辨識的號碼資料包,可以幫助用戶直接離線辨識,而不透過網路,這樣

  • 一來,可以加速。

  • 二來,可以繞過台灣電信技術的限制,達到辨識率加快的體驗。

  • 三來,還可以增加更新時廣告的露出。

  • 四來還可以引導用戶設定自動更新成為訂閱用戶。

在這次 Redesign 要解決的問題有四項:

  1. 低更新號碼資料庫造成的 Search slow 的問題

  2. Offline DB 更新頁面原本資訊不明確

  3. 離線辨識名詞難以理解

  4. 缺乏引導訂閱 IAP

​而本次的做法:我們會重新包裝過去難以讓人理解的「離線辨識」這個名詞,同時透過用戶在更新 OfflineDB 的 User Journey 尋找可以更細節的不更新原因,比如像是:

  • 用戶在首次 onboarding 後並不知道需要定期更新資料庫。

  • 唯一知道要更新的管道是推播通知。

  • 離線辨識跟來電辨識沒有做資料連結的教育

  • ...etc

​下圖為用戶更新 Offline DB 時的 User Journey

user journey.png
rapid usability test.png

​上圖為迭代型易用性測試 Rapid Usability Test

​(Vik 寫的 Rapid Usability Test Medium 文章

 
process.png

左側為原版的 Offline DB 更新頁面,右側為重新包裝後的 Offline DB 更新頁面,經過迭代式易用性測試了 4-6 個版本後,我們將產品定調為安全防護。

 

此頁面除了更新以外,下方也引導用戶可以成為訂閱版用戶,並且預設了未來簡訊推出簡訊管家時,往下增加簡訊系列的安全防護卡片。

all protection ui.png
SMS Discovery Workshop

帶領團隊探索 SMS 對於 Whoscall 的價值,與增加 SMS 對於 B 端和 C 體驗與市場需求,

此工作營包含計畫、主持人、結案與轉化至產品,並且寫成相關的 SOP 希望可以協助其他 host 更快速地執行工作坊,也發表了 Medium 文章。

 
workshop.png

本次 Workshop 透過兩次發散兩次收斂的 Google Sprint 精神作為主要流程,

而發散使用的方法論分別是:

  • Impact Mapping

  • Fake Door

 

選擇 Impact Mapping 主要是因問希望大家在發想時思考脈絡是連貫的,同時也是有邏輯的,而 Impact Mapping 囊括核心問題、角色、影響與功能。

而選擇 Fake Door 作為發散第二階段則是為了不讓 Workshop 淪為一場單純的活動,希望真的有實際能夠進 Sprint 的 Task,所以在這個 Fake Door 要求成員所製作的會是實際可以執行測試的方案。

impact mapping.png
fakedoor.png
image.png

在 Workshop 結束後除了電子化所有便利貼以外,我與 Stakeholder 再次進行了方案的確認,

透過 Value Proposition 和 Lean Canvas 兩個方法論,幫助我們找到可以優先執行的方案。

download.png
final.png
Building Design Team Illustrator Guideline

作為主要定義 Whoscall 插畫風格設計師,帶領團隊逐步建立插畫資料庫,凡舉插畫風格細節定義、色彩重新定義與新增、插畫結構構成、整體人物插畫指南等等。

g1.png
g2.png
g3.png