UX｜還在做無效設計嗎？假說、驗證與迭代：跳脫無效設計的惡性循環
12 月難得的好天氣，陽光透過落地窗灑入會議室，每一個角落都隱隱反射著金黃色溫暖的光芒。正在規劃 2022 Q1 目標的我們，收到了這樣的提案：
「目前 Kono 用戶使用 app 的頻率以周為單位，部分則是雙週或月為單位。如果我們做一些編輯精選，一週發兩次，就能刺激用戶使用頻率提升，進而提高用戶留存率。」
短短兩句話，卻充滿了各種疑點。
1. 為什麼要提升用戶的使用頻率？
我們是電子雜誌平台，雜誌出刊頻率多半為周刊、雙周刊、月刊、季刊等，其中以周刊、月刊最多。如此看來，用戶使用 app 的頻率以周為單位，是符合雜誌更新週期的，這不是很自然而且理想的頻率嗎？
2. 為什麼做編輯精選就能提升使用頻率？
數據告訴我們，使用者開啟 Kono app 之後，70% 以上都是直接從雜誌期別進入文章，15% 左右從下載列表開始閱讀，剩餘的 15% 閱讀量則是分佈在搜尋、首頁推薦、熱門專區、通知等。由此可知 85% 以上的用戶在開啟 app 的當下就已經有明確的閱讀目標，那麼我們有什麼理由去假設用戶會因為編輯精選而大幅改變使用行為？
3. 提升使用頻率就能提高用戶留存率嗎？
每一個產品都有最適合產品特性及用戶需求的自然頻率，使用頻率增加了，未必是一件好事。
試想 Kono 的用戶使用頻率開始高於雜誌更新頻率的話，可能會發生什麼事？一開始，數據表現會非常好看，或許用戶閱讀量會提升，app 停留時間也會拉長。但是時間久了，雜誌更新速度跟不上用戶閱讀速度，用戶也許會感覺到內容越來越少，進而萌生出離開這個平台的念頭。
4. 留存率是當下最需要被解決的問題嗎？
有趣的是 Kono 的留存率其實很高，撇除一些諸如雜誌停刊、台灣地區停止發行等獨立事件後，我們的留存率是相當高而且穩定的。所以如果最終目的是透過提升使用頻率來提高用戶留存率的話，實際上能達到的效果可能也很有限。
太多團隊都在做無效的設計
像這樣的對話在我們公司隨時隨地都在進行，想像一下如果這個提案沒有經過這樣的討論，會發生什麼事？最大的可能性，是我們又多了一個無效的功能。既沒有提升使用頻率，也沒有造成什麼負面效果。
「無效」是什麼意思？就是有也好，沒有也無妨；對產品無益，卻也沒什麼壞處，存在感趨近於零。說要砍掉嗎？似乎有點可惜，好像前面都在做白工。不砍掉呢？往後要不斷維護這項功能，久而久之也是一項隱形的成本。
盛大推出、隆重上線，卻沒有對產品價值造成任何影響，就像是在洛基影集裡面自覺幹了一件大事，卻沒有被時間管理局帶走一樣。可怕的是，太多的產品團隊都已經陷入無效設計的泥沼而不自知。
而無效的設計會出現，最常見的原因有兩個：
一、憑感覺開需求
這樣的情境有沒有很熟悉？公司說要讓用戶多在平台上互動，於是開發了留言、按讚功能。後來因為使用率低落，便有人提出做一個「互動牆」，讓使用者回顧自己留言、按讚的互動紀錄，增加用戶黏著度。
最後繞了一大圈發現其實大部分使用者根本沒有按讚留言的需求，於是決定把功能拿掉，卻引發少數有按讚留言的用戶回報問題，詢問為什麼自己的紀錄都不見了，提出希望將功能加回來。最後公司決定留著按讚、留言和互動牆的功能，但是不繼續開發或優化，於是平台上又多了一個對多數人沒有任何用處的功能。
如果這個團隊先坐下來好好討論一下，就會發現「按讚、留言的功能會增加用戶互動率」這個假設很可能根本就大大地有問題，這是第一個錯誤。互動率沒有上升以後，又試圖用黏著度來包裝一樣的東西，這是第二個錯誤。因為少數使用者的反應而錯過了快刀斬亂麻的時機，從此多了一個需要長期維護，卻沒有實質效益的功能，這是第三個錯誤。
為什麼想要增加互動率？增加互動率有什麼優點或缺點？有哪些方法可以增加互動率？按讚、留言是最適合的方式嗎？如果開發出來以後使用率低，要繼續優化還是直接刪除？釐清這些問題需要時間，而很多公司不喜歡花時間做看似沒有產出的事情。
二、先射箭再畫靶
另一種常見的情境，是產品團隊腦力激盪以後想了一個新的功能，大家聽著也覺得挺有意思的，於是如火如荼地進入開發並順利上線。上線以後，大家興奮地調出數據，卻意外地發現新功能的使用人數少、使用頻率低，而且看起來也沒有讓註冊或付費的會員比例增加。
正當大家開始懷疑是不是這個功能沒有大家想像中那麼好的時候，突然有人說了一句：「看！使用過新功能的人，平均每次使用 app 的時間有變長！」於是團隊便得出結論，新功能可以增加 app 平均使用時間，對使用者的互動品質有正面影響，因此該專案判定為成功。
照這樣的方式來看，幾乎不會有失敗的專案，推出的新功能成功率都超高，但是長期來看整個產品卻沒有任何實質進展。如果團隊有好好審視這個專案，就會發現他們根本沒有訂好產品策略、設定明確的指標與成功條件，以致於功能上線以後他們也沒有客觀的方法可以判斷專案到底成功了沒？大家的付出到底有沒有獲得回報？
產品設計除了找一些新奇有趣的新想法之外，還有一個很重要的環節，是驗證這個想法的成功與失敗。為什麼要做這個新功能？這個功能解決了什麼問題？如果成功解決問題，產品數據應該會出現什麼樣的變化？這個變化所帶來的效益，能夠平衡開發這個功能所付出的成本嗎？
許多設計師、PM，甚至是整個團隊、公司，都缺乏驗證成敗的經驗與敏感度，於是便導致了專案上線後才積極尋找成功跡象的狀況出現。
跳脫無效設計的惡性循環
一、釐清問題假說的定義與合理性
千金難買早知道，但有些事情不是馬後炮，而是早就該知道。每一個提案背後都有一個假說，當拿到需求的時候，第一件事就是要對這個假說提出挑戰與質疑。比方說有人告訴你：
我們有超過 70% 的使用者單次使用 app 的時間都少於 5 分鐘，如果能增加更多有趣的內容，提升單次使用時間，就能增加使用者對 app 的黏著度，進而提高留存率。
無論你贊不贊成這個提案，都不妨先問問這些問題：
- 這個假說考量到問題的全貌了嗎？有沒有更多數據可以參考？
我們目前知道 70% 的使用者單次使用 app 的時間都少於 5 分鐘，但是我們知道這些使用者平均一天使用 app 的頻率為幾次嗎？那些使用時間大於 5 分鐘的人，使用頻率和少於 5 分鐘的人一樣高嗎？使用時間、使用頻率與留存率之間又有什麼樣的相關性？
有了這些更全面性的數據，我們就能提出下一個問題：這個目標真的合理嗎？ - 這個假說訂定的目標合理嗎？
單次使用時間較長的使用者，長期下來的留存率真的有明顯地高於單次使用時間較短的用戶嗎？如果我們能將所有使用者的單次使用時間、平均使用頻率及留存率進行比較，我們有可能會發現其實少量多餐的使用者留存率反而是最高的；或者我們也可能會推導出留存率最高的單次使用時間其實是 3 分鐘以上，而不是原訂的 5 分鐘。 - 這個假說的定義清楚嗎？團隊對於目標有共識嗎？
如果提升單次使用時間至 5 分鐘以上真的能提高留存率，那麼假說中的「增加更多有趣的內容」究竟是什麼意思？是更貼近時事趨勢的議題呢，還是增加個人化的推薦內容？是要增加內容的數量，還是提升內容的品質？這些定義清楚了以後，我們才能夠進到下一步，為這個假說設定成功指標。
在專案開始前釐清假說的定義與合理性，不只能減少無效設計的產生，還能讓預備解決的問題更加聚焦。
在仔細討論過問題之後，一開始的提案可能會變成這樣：
使用數據顯示平均單次使用時間超過 3分鐘的用戶有明顯較高的留存率，但是我們有超過 50% 的用戶平均單次使用時間都少於 3分鐘。我們推測，增加個人化的推薦內容有機會能夠大幅度提升平均單次使用時間，進而提高留存率。
如此一來，這次的目標就會聚焦在能夠提升使用時間的個人化推薦內容上。我們不需要再討論是否要開發一個即時新聞欄位，或是要不要做精選文章導讀。我們可以將心力放在如何找出使用者喜好、如何找到更合適的推薦頻率，以及什麼樣的推薦策略會有最大的效果。
二、設定成功指標
假設我們決定要執行的專案是「透過提供更個人化的推薦內容，提升用戶平均單次使用時間」，那麼接下來就要定義這個專案達到什麼條件算成功。
成功指標會在專案開始之前就定義清楚，並與管理階層取得共識。取得共識後，就像是簽了一份合約一樣，不能再任意改變。
如果共識的目標是要讓「平均單次使用時間超過 3 分鐘的用戶比例上升 10%」，那麼之後管理階層就不能突然改成使用時間超過 5 分鐘，或是要求文章的點擊率同時也要上升。
而如果成功指標是「A/B 測試中，新版的平均單次使用時間較長，且存在顯著差異」，那麼在專案驗收的時候，也不能臨時改口說：「新版雖然沒有變長但是至少沒有變短，所以也不算失敗啦！」
由於當成功指標改變時，專案的規劃、設計方法、開發方式都會隨之產生變化。這是非常消耗開發成本的，因此不任意改變成功指標是非常重要的！如果要改變成功指標，就必須要有很重要的原因，例如市場策略的改變、新的數據發現，或是其他重大的策略性變化。
註：如何設定合理的成功指標，以及常見的指標有哪些，本文先不提，下次會再找機會和大家分享。
三、針對後續迭代建立團隊共識
定義完成功指標以後，便可以決定後續會怎麼處置這個專案。如果開發團隊對於後續的迭代已經有共識，就可以預留彈性、迅速調整。
比方說我近期有一個專案是在 app 上做了兩個不同的閱讀模式，目的是要測試兩種模式的使用量以及閱讀表現。由於我們已經決定好測試結束後只會保留表現最好的那一種閱讀模式，因此當同事或老闆反應希望在其中一種閱讀模式裡面加上一些很複雜的功能時，我就能很確定地告訴對方：「測試結束後只有一種閱讀模式會留下來，如果現在做這麼複雜的功能，結果最後這個模式被砍掉了，會讓工程師們做白工。」
同時，也因為已經預先決定好最後只會保留一種閱讀模式，因此工程師就能先考慮到這個條件，並選擇最能夠保留這項彈性的開發方式。
以「透過增加個人化的推薦內容提升平均單次使用時間」這個專案來說，如果成功了，後續我們會做什麼？也許我們在 iOS 上測試成功，接下來就會將新的推薦機制陸續推到 Android 以及 web 上。或者我們也可以繼續調整推薦的參數，測試是否能夠得到更高的結果。
如果失敗了，下一步會直接回復到舊版的推薦機制嗎？還是會再調整新版推薦機制的參數呢？假如我們推論新版推薦機制有可能失敗的最主要原因是因為我們除了閱讀記錄以外，沒有其他的閱讀資料可以做更精確的推薦，那我們也可能會將失敗後的下一步訂定為「設計一個能夠獲取更多用戶偏好資料的方法並進行第二次測試」。
事先共識下一步走向，能讓開發者考量到長期的專案變化，也能讓整個團隊——從管理階層到產品團隊成員——的頻率更加一致。
如果公司能夠做到每一項專案開始前都好好釐清問題假設、設定客觀的成功指標，並對於後續迭代建立團隊共識，就能夠避免許多無效設計的產生。但是這個流程需要很多角色包含設計師、PM、工程師等，一起努力才能夠達成。更重要的是公司的管理階層必須也要有這樣的觀念，才可以避免出爾反爾的情形出現。
希望這篇文章對大家有幫助，如果有任何問題也歡迎留言詢問！那麼我們下次見～ 👋
↓↓ 如果喜歡這篇文章，請幫我掌聲鼓勵鼓勵～也歡迎追蹤，我會不定時發布新文章！👏👏👏
