如何用數據輔助產品設計？ — “Designing with Data” 讀書摘要 (下篇) 實驗設計與執行
這是下篇的心得，如果你還沒看過上篇的話，可以先閱讀：
上篇介紹了本書的前三章，談論了將數據帶入設計的重要性以及如何選定合適的指標。接著下篇，我們來談談實驗設計的實務。
寫這篇拖了很久的時間，一來是距離看完書已經很久，有許多書中提到的細節已經快要忘記，花了一些時間重新複習XD 實驗的細節很多，在寫的過程中也發現有一些概念已經搞不清是書中提到還是個人實作後的學習，總之是已經融合了不少自己的經驗和詮釋，如果有錯誤的地方還請不吝指正或一起討論 m(_ _)m
實驗的基本概念
小時候上自然科學課應該都有做過實驗，在軟體服務上做實驗其實也是一樣的概念。當使用者在產品中進行某個旅程時，將使用者進行隨機的分組，讓使用者進入不同的體驗（可能是看到的文案不一樣、按鈕的大小不一樣、演算法的邏輯不一樣…），根據使用者的行為，我們可以觀察到相對應的現象，例如點擊率、付費金額、分享給朋友的次數…等等指標的變化，藉由比較控制組和實驗組之間指標的差異是否顯著來評估不同的操縱變因是否能達到預期的效果。
市面上有許多 SaaS 服務提供產品實驗的工具，從基本的隨機分組、成效分析到進階的跨平台實驗、視覺化編輯器…等等都能依需求來選擇。若預算足夠，付費的服務像是 Optimizely (跨平台) 和 Apptimize (Mobile App) 是不錯的選擇。如果是比較初期的產品，免費的 Google Optimize (Web) 和 Google Firebase (Mobile App) 也是入門的好選擇。
為什麼要做實驗？
做實驗需要付出許多額外的成本，例如需要有不同版本的設計、程式架構會比較亂、需要額外的開發時間、需要精準的數據追蹤…等等。每天和時間賽跑的產品團隊，為什麼需要投入資源在各個產品環節上做實驗呢？大概有以下常見的原因/好處：
(1) 團隊成員對於產品設計方向沒有共識，以實驗探索可行/最佳方向
行銷部門說 A 功能最能吸引新用戶、老闆說這個市場就是缺少 B 這個殺手級功能、設計師說 C 最符合使用者使用習慣、工程團隊說 D 最好開發和維護。這樣的情況不管在什麼規模的公司、什麼產業的產品應該都屢見不鮮，大家從各自觀點出發，爭論永遠沒有結果。那為什麼不實際丟到市場上測試看看使用者的反應如何呢？
(2)準確的衡量各種改變帶來的效果，調配後續的資源投入
有些新功能或是功能的改善，預期帶來的效果看似非常直觀，當團隊成員都一致認為「做一定比不做來得好」的情況下，還需不需要做實驗呢？建議如果資源允許，還是進行實驗。原因是這樣才能準確的衡量改變之後實際的效果，就算知道一定比較好，到底是能增加 5% 的轉換率還是 50% 的轉換率呢？ 了解實際的效果，能讓我們知道哪些功能值得繼續發展，哪些其實可能不值得投入資源。
(3) 最重要的是：了解「因果關係」，而不是用趨勢來「猜」
產品服務會有不同部門一起進行營運，設想一下如下圖情況：公關團隊和主流媒體合作發佈了幾篇介紹產品的新聞、產品團隊將努力開發了兩個月的新版付費流程的推上線、競爭對手推出了一個破盤的優惠方案、系統當機導致服務斷線了半天無法連線，這些會直接或間接影響營收的事件，通通發生在短短一週內。此時，身為一個產品經理的你，該如何判讀新版的付費流程，究竟有沒有比舊版的流程來的好以及好上多少呢？
上述例子可能看似誇張了一點，但實際在營運一個產品服務時，一定會有許多類似這樣，影響一個指標的多種事件同時發生的情況，若是沒有設計科學化的實驗來把每個影響因素分開分析，要能精準評估一次產品優化帶來的效益，幾乎是不可能的事。
實驗的三個階段
階段1：定義 (Definition)
首先，再次強調上篇中提到的重要觀念：為了學習而設計，而不要為了發布而設計 (designing to learn rather than designing to ship)。這樣一來，就算你的設計本身失敗了，你在過程中卻還是能得到學習。做實驗最重要的就是要得到學習，學習什麼樣的設計有效、什麼樣的設計沒有效。為了最大化學習的效果，做實驗的第一步就是要先定義清楚為什麼要進行這次實驗 (why) 以及想要實驗的內容是什麼 (what)。
一個產品/服務一定有它想要達到的目標 (goal)，不論是公司營運的目標或是產品本身價值的目標。而一個大目標之下又可以對應到許多不同的問題或是機會點 (problem/opportunity area)，例如：在「增加月活躍用戶數」的這個大目標下，可能包含了「提高新用戶註冊率」、「降低既有用戶流失率」、「透過異業合作導入流量」、「優化廣告投放效益」…等等問題/機會點。每個設計、每次實驗，都應該緊貼著產品的大目標和問題/機會點進行，才不會失焦。
在這個階段可以問自己幾個問題：
- 你的公司/產品，最重要的目標是什麼？你準備進行的實驗/設計和這些目標相符嗎？
- 從現有的數據中有沒有什麼線索能夠提供靈感？
- 決定要驗證什麼假設之前，你已經盡可能把所有可能性都探索過了嗎？有沒有其他更值得驗證的假設？
- 做這個實驗能讓你對你的產品和使用者有更多的了解嗎？
在這個階段的最後會產出假設 (hypothesis)，一個好的假設包含我們根據對使用者或市場的洞察而「預測」可能可以達成某些效果 (outcomes/effects) 的改變。可以使用以下的句型來表達：
我們預測 [做…功能 / 創造…體驗] 給 [使用族群]，可以造成 [這些效果] ，因為 [邏輯 / 洞察]。 如果我們能觀察到 [對指標的影響]，就能證明這個假設是正確的。
例如：
(照片分享平台 — 例如 Instagram）
我們預測 [提供使用者增加濾鏡和貼圖在照片上的功能] 給 [所有使用者]，可以 [讓更多使用者使用]，因為 [這讓他們的照片變好看，而且讓使用這個產品更有樂趣]。如果我們能觀察到 [使用者的使用時間變長]，就能證明這個假設是正確的。(專業社交平台 — 例如 LinkedIn)
我們預測 [增加個人檔案完成度進度條] 給 [尚未完成個人檔案的使用者]，可以 [讓更多使用者完成檔案]，因為 [這讓他們感覺他們必須完成這個任務]。如果我們能觀察到 [使用者的完成率提升]，就能證明這個假設是正確的。
在一個假設中，「邏輯 / 洞察」是最重要的組件。它可能來自團隊對使用者行為或市場趨勢的洞察。進行設計或實驗前，應該都要想清楚：「做這個改變，背後的邏輯是什麼？」若無法描述清楚，就要再審慎思考是否真的要花費資源做這個設計或實驗。要求自己和團隊成員都使用這樣的句型來構建假設，除了可以讓大家有共同的語言來溝通以外，也能避免單靠直覺的做事方式或是所謂 BCD (boss-centered design) 的情況發生。
階段2：執行 (Execution)
在執行階段中，要根據定義階段產出的假設來產生相對應的測試方案 (Test Cell)。同樣的假設，可以產生許多種不同的設計，可能是流程的順序、樣式的變化等不同的細節。測試的變數不一定都是視覺的，像是推薦系統的演算法、程式的回應速度…等等，也可以是實驗的測試標的。
比起直接推出新設計，進行實驗的好處是可以大膽的嘗試各種不同的設計。在實驗中嘗試越多種不同的設計，能夠得到越廣、越深的學習。還在探索階段的功能，可以先嘗試差異大的設計，找到最高的山頭 — 也就是找尋全域最大值 (Global maxima) 後，再來進行細節的最佳化 — 找尋區域最大值 (Local maxima)。
當 Netflix 要開發在 PlayStation 上的服務時，由於操控方式完全不同，原本在網站和手機上的體驗必定不能直接移植。於是，在很前期他們就嘗試了許多種迥異的設計，配合多次質化和量化的測試，找出了哪種設計最適合在大螢幕上使用搖桿操作，之後才是再進一步專注細節的優化、細細打磨出最好的體驗。
在真的投入資源嘗試不同設計之前，還有一件重要的事情值得在這個階段想想：「在執行這個實驗之前，還可以先做什麼測試？」，也就是書中所謂的 “Experiment 0”。這可以避免在想法還不成熟的時候就過度投入資源到細節的設計。
對於已經存在的功能，一個簡單的方法是：「試試如果把整個功能移除，會發生什麼事？」SkyScanner 的團隊就做過這樣的嘗試，他們試著將「最便宜機票指示器」(cheapest flights ticker) 的功能從首頁移除，結果發現這對他們關注的指標一點影響都沒有，他們就果斷的從產品中移除這個功能，將資源投入到其他更有發展空間的功能上。而對於還不存在的、想嘗試的新功能，則可以使用像是 假門測試 (fake door test) 的方法，以低成本的方式來快速得到學習。
不管是嚴謹的 A/B testing、簡單的假門測試、做 Landing Page 或是進行問卷調查、訪談…等等方法，目的都是要從使用者身上得到學習。依照產品功能在什麼階段、團隊在什麼資源條件的情況下選擇適合的方法來互相搭配，才能最有效率的獲得學習。
階段3：分析 (Analysis)
有了假設、設定完指標也設計了數種測試方案之後，最後一個階段就是要讓實驗進到真實的使用場域中，收集數據、分析各種設計帶來的效果。
在分析的階段，最重要的就是確保你有得到最初想要的學習。收集到數據後，需要進行嚴謹的統計分析來驗證各組使用者之間的表現是否有差異。如何檢驗組別之間的差異是否顯著？如何估算實驗需要進行多久 / 需要多少樣本數？這從網路上可以找到許多資源可以學習（例如：ConversionXL 的文章、Analytics Toolkit 的文章 ），也有許多工具可以使用（例如：AB Testguide 提供的顯著性計算機、Optimizely 提供的樣本數計算機），這邊就先不往下深談。
質化分法 + 量化方法 = 更有效率的學習
其實本書中指的數據，不只是量化的數據，透過訪談、問卷或其他使用者研究方法得到的質化數據也是很重要的。量化研究能讓我們清楚地發現哪裡有問題、有什麼問題，質化研究則能更有效地幫助我們找到問題的發生原因。兩者搭配得當，就能高效率的從使用者身上得到學習。
書中舉了一個 Spotify 如何交叉使用質化和量化方法的案例：
2016 年，已經推出數年的 Spotify，手機 app 上的功能已經多到讓使用者使用起來感到挫折，需要好好重新整理一次所有的導覽功能，這一次改版，他們一共進行了四個階段：
- 第一次易用性測試 (usability test)：
他們要求受測者完成一些核心的動作，例如：「找到一首適合跳舞的歌曲來播放」。結果，他們發現居然只有 30% 的使用者能夠完成。另外，當時設計領域正對於把功能收合在左邊的漢堡選單 (hamburger menu) 有許多負面的聲浪，許多設計師認為這種設計不能把功能選項攤開在使用者能一眼就看到的地方，會造成使用者較少使用這些功能。 - 第一次量化實驗 (A/B testing) — 探索方向：
基於以上對使用者以及市場趨勢的洞察，他們設計了兩組不同的導覽進行量化實驗，探索可行的改進方向。第一種設計沿用原本的漢堡選單，但重新整理了一次功能架構，讓導覽選項更有邏輯而且更貼近 Spotify 提供的核心價值。第二種則是把漢堡選單的設計改成直接攤開在 app 下方的導覽列，讓使用者一目瞭然。結果這次的實驗中，兩種設計對使用者的回訪率都沒有顯著的提升。但是，他們發現把功能攤開的導覽列設計，能讓使用者多探索 app 的各種功能，雖然沒有提升最重要的回訪率 (primary metric)，但對於一些次要指標 (secondary metric) 卻有顯著的提升，因此他們選擇使用這個設計繼續往下優化。 - 第二次易用性測試 — 配合原型測試 (usability test with prototypes)：
在直接跳入下一次的 A/B testing 之前，他們先製作了多個 prototype 進行易用性測試。測試導覽列的位置、各種圖標 (icon)、圖標上有無文字、放置的功能和數量…等等細節。比起直接開發功能上線進行實驗，這種方法讓他們更低成本、更快速的得到學習。 - 第二次量化實驗 — 優化細節：
有了前面幾次量化和質化測試得到的資訊，他們決定使用固定在下方的導覽列，並設計了兩種不同的功能選項，進行第二次的 A/B testing。這次的設計，就成功了提升了使用者的回訪率。
確保數據無誤
若實驗結果不如預期，怎麼確認是不是數據收集出了問題？書中有以下建議：
- 排除時間因素/季節性影響 → 實驗至少進行一個完整的 Business cycle
一個服務在週間和週末可能有不同的客群使用（例如：上班族可能週末比較有時間玩遊戲或是購物），若只有在週間收集數據，可能會有偏誤。依照產品/服務性質，一個 Business cycle 可能是一天、一週，甚至更長。 - 數據是否收集得完整？分組是否夠隨機？ → 可以使用 A/A testing 驗證
A/A testing 顧名思義就是一樣將使用者進行隨機分組，但給予完全相同的體驗，觀察他們在指標上的表現是否有不同。可以藉此驗證數據收集和隨機分組的系統是否有異常。 - 還是懷疑數據異常？ → 再進行一次一樣的實驗
如果已經排除了以上的問題，實驗結果依然和團隊預期的有很大差異，此時可以考慮再進行一次一樣的實驗。就算是業界普遍採用的標準：95% 的信心水準，實驗 20 次也有出錯 1 次的機會。如果連續進行兩次一樣的實驗，就可以把出錯的機率降到 1/400。
要不要發布實驗結果？
最後，實驗結束後，要不要將設計推上線 (rollout) 呢？這個問題應該要在定義的階段就先規劃好，這邊歸納成以下兩種狀況探討：
- 實驗結果正面
新設計有效的提升了關鍵指標，若是沒有降低其他重要指標的表現，可以考慮將新設計發布給所有使用者。需要注意的是，若是很大程度的改版，發布前要思考一下需不需要有更多的溝通和公關操作 (PR) 讓使用者能更順利的轉移到新版本的使用。也需要檢視目前的系統架構、客戶服務，是否能支持新版本所需。
有些探索性的實驗，可能在規劃時就不打算要發布，只是為了要學習。這種情況下，一開始設計來測試的體驗可能不完整，就算實驗結果很好，也需要經過適當的修正、補齊，或是針對細節再進行實驗後再考慮發布。 - 實驗結果不顯著或負面
實驗結果不顯著或甚至造成負面影響時，通常不會進行發布，因為這個新設計對團隊所關注的重要指標並沒有幫助，卻可能會造成使用者額外的學習成本來習慣新介面的使用。除非是有長遠的策略考量，例如要與競爭者搶市場份額、要進入新市場、準備募資或上市而需要創造短期營收…等等，這種情況就需要另外的評估方式。
碰到實驗結果不顯著或負面的情況，若已經排除數據異常造成的情況，可再多檢視次要指標 (secondary metrics) 的變化或是將使用者再分群，尋找是否在某些情境下或是對某些使用者（例如特定國家、性別、年齡、使用平台…等等）特別有效果。獲得學習之後，修正假設或嘗試不同的設計，再進行實驗。
總結 ＆ 實務經驗
- 進行嚴謹的實驗可以讓我們準確衡量每次改變帶來的效果，幫助資源調配。
- 在探索完畢所有可能性之前，不要太早投入發展某個特定的解法。
- 質化、量化方法互相搭配，學習效率更高。
- 在產品上做改變成本很高，不只需要設計、開發、測試的時間和金錢，對使用者來說，要改變既有的行為並重新學習，也是很高的成本。
- 好的實驗計畫和設計過程一樣是必須一直迭代的 (iterative)，不斷的學習，再用學習到的知識來持續優化、改善設計。
6. 利用書中提供的實驗架構藍圖 (experimentation framework) 的方式來管理實驗，可以讓各個實驗的目的更明確，實驗和設計的迭代過程也能清楚呈現。
再次感謝你看到了這邊，終於是寫完了😓。閱讀此文以後想要更深入了解的朋友，非常建議你去好好研讀這本書。博客來和天瓏書局 都有代訂的服務，不排斥閱讀電子書的話，在 Amazon 上購買 Kindle 版本或是在本書出版社 O’REILLY 自己搭建的平台 Safari Online 上閱讀都很方便（Safari Online 有提供新註冊會員 10 天免費的試用，如果你看書神速，也許可以不花錢就看完XD）。
有任何想法也歡迎你在底下留言，一起討論學習成長！
