Whoscall Android

2018 ~ 2019

Built For Trust

Whoscall 長年致力於陌生號碼辨識體驗與技術，我們希望透過科技和設計得力量，

為社會和世界帶充滿新任的溝通網絡。

Challenge

2018 ~ 2019：重新對焦 Whoscall Android 核心價值，與建立定期用戶研究機制，根據研究結果逐步提升用戶滿意度（NPS）。
影響團隊信任研究成果，與協助團隊將研究結果成為優化產品的依據，並且指導其他設計師進行研究。
主導多場社內工作坊，並且指導其他設計師舉辦工作坊。
建立 Whoscall 插畫視覺風格。

Outcome

✔ NPS +15%

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

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

✔ Whoscall 視覺風格制定與規劃

✔ 主持工作坊

Role

Whoscall Android Lead Product Designer, Researcher, Workshop host

AARRR - Revenue

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

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

Quantitative Regular User Research

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

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

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

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

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

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

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

Regular User Research Impact

Call Dialog Search Slow

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

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

1. Improve Call Dialog User Interface

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

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

實驗組一，我們使用了 Loading 動畫在視覺上讓用戶體感上過的比較快。
實驗組二，我們使用了交替不同的文案，告知用戶系統正在辨識哪個步驟。
實驗組三，我們結合了一和二兩組的效果。

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

2. Redesign Offline DB Update Page

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

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

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

一來，可以加速。
二來，可以繞過台灣電信技術的限制，達到辨識率加快的體驗。
三來，還可以增加更新時廣告的露出。
四來還可以引導用戶設定自動更新成為訂閱用戶。

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

低更新號碼資料庫造成的 Search slow 的問題
Offline DB 更新頁面原本資訊不明確
離線辨識名詞難以理解
缺乏引導訂閱 IAP

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

用戶在首次 onboarding 後並不知道需要定期更新資料庫。
唯一知道要更新的管道是推播通知。
離線辨識跟來電辨識沒有做資料連結的教育
...etc

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

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

（Vik 寫的 Rapid Usability Test Medium 文章）

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

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

SMS Discovery Workshop

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

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

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

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

Impact Mapping
Fake Door

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

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

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

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

Building Design Team Illustrator Guideline

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