Google「以人為中心的機器學習」的七個產品設計原則
原文出處：Human-Centered Machine Learning
透過機器學習的技術，我們可以找出資料間的關係與隱藏的模式，他也逐漸被應用在日常生活的產品之中，從 Netflix 的推薦影片，Sporify 的推薦歌單，或是 Airbnb 的房源搜尋結果排序，房源推薦，訊息分類，一直到自駕車，皆可看到機器學習應用的身影。
然而，就像 iPhone 與 App 剛出來時我們要重新思考人和行動裝置間的互動一樣，目前，人類和機器學習應用的互動也尚未有一套完整的準則。這篇文章中，Google 的設計師 Jess Holbrook 和 Josh Lovejoy (目前已離開 Google 加入微軟) 提出了 “Human-Centered Machine Learning” (以人為中心的機器學習) 的設計原則，並以 Google 的產品來作為範例，我也試著加入一些我看到的成功或失敗的產品案例。
由實際要解決的問題出發，而非看機器學習技術可以解決什麼問題
由於機器學習的熱潮，許多公司都急著也要踏入這股熱潮中，將產品也導入機器學習的技術，卻沒有實際想清楚要解決的問題。最近期的例子應該是 2016 年左右的聊天機器人，由於當時如 Facebook，Google，LINE，騰訊等各大科技公司相繼投入，帶動了許多新創公司在這些平台上開發應用。當然其中也有成功案例如 TaxiGo 等服務借助通訊軟體便利的特性，持續經營中，但大部分的聊天機器人或智慧助理服務，最終都黯淡收場。
所以，最終還是回到產品設計最原始的起點：我們要解決的是什麼問題。如果這個問題不是使用者在乎的話，最終很有可能設計出來的是一個功能強大，但卻沒有解決任何問題的產品。
所以，許多困難的工作還是要做，機器學習不會回答妳用戶遇到的問題是什麼，仍舊需要我們不斷地透過各種方式挖掘，思考，以及驗證。
儘管發覺了問題，但機器學習真的是比較好的解法嗎？
機器學習的技術應是解決問題的手段之一，但不一定是最好的解法。產品開發時的一大挑戰是確定哪些體驗是需要，而哪些部分是不需要使用機器學習的。比如圖一中 Gmail 在使用者忘記插入附件時跳出提醒就是一個很好的例子，他應該沒有使用任何機器學習的技術，只是當偵測到 email 內容有附件相關的字詞，但是當使用者在要送出信件時卻沒有夾帶任何附件，系統會自動跳出提醒。如果使用機器學習，應該可以抓取出更多的可能隱含的資訊，在更多地方跳出通知，但所需要投入的資源可能與產生的邊際效益不成比例。
設計功能時，問自己這三個問題：
- 描述如果由一位人類專家而不是由機器來做的話，他會怎麼做？
- 如果這是由人類專家來做，當他們做對了，或做錯了，用戶要如何提供回饋讓他們下次做得更好？
- 如果這是由人類專家來做，用戶會希望他們有哪些假設？或是有什麼他們應該事先知道的事項？
然後我們將產品的點子，放入下面這個 2x2 的矩陣中，並讓團隊成員根據每個點子投票：
透過這樣的練習，我們可以在初步就區分開來，哪些問題是用機器來解決，可以提供比較大的 impact 的，而哪些不是。最好在討論的階段也有資料科學家或工程團隊的參與，這樣可以在早期的時候，對於技術上的極限就可以有初步的評估。
就算機器學習真的是比較好的解法，也先用工人智慧測試使用者的接受度
因為許多機器學習的應用涉及到推薦或個人化，產品功能的原型設計會是一大挑戰。這邊作者提供兩個方法：
一是在做用戶研究時，讓使用者帶著自己的資料過來，比如說她的照片，音樂播放清單，她們最近收到的電影推薦等等，使用這些資料做測試。比如說你可以試著推薦給她們錯誤的產品，看她們如何反應，並詢問她們當收到錯誤的推薦時，她們假設系統是下和運作的，為什麼會讓她們收到這些結果。這樣的方式會比只是口述會是用與他們無關的內容來做研究和測試來的好。
另一個方式是用工人智慧的方式來做測試。測試者和產品互動，就像一個已經上線的產品一樣，但實際上背後還是由人來與測試者做互動，比如說回覆訊息，推薦商品等等，如同下圖三所示：
如果出錯了，會不會一秒惹怒使用者？
機器學習的系統一定都會有推薦錯誤的時候，對於產品設計者，重點是了解在什麼情況下會預測錯誤，以及事先評估這些錯誤會如何影響使用者體驗。作者使用了機器學習中常用的 Consusion Matrix，評估使用者在這四個象限中的反應，並認真思考準確率和召回率間的界限該如何設置。
舉例來說，如果在 Google Photo 中搜尋 “遊樂場”，可能會像下圖一樣出現不是遊樂場的照片。這是因為在考量用戶體驗時，這個應用的召回率會比準確率來得重要，不只回傳遊樂場的照片，還有其他類似的照片。
使用者有機會針對錯誤提供反饋，並讓產品不斷演進
最有價值的機器學習系統會隨著時間的推進，與使用者的心智模型一同進化。而機器學習的系統是針對既有的訓練資料集來訓練模型，沒辦法基於尚未輸入進來的資料做預測。因此，我們需要在產品週期中提前規劃人機交互的研究。隨著用戶和使用情境不斷增加，我們需要預留充足的時間，透過定量分析準確率和錯誤率來評估機器學習系統的效能，並在用戶使用這些系統時與她們坐在一起，以了解他們的心智模式如何隨著每一次的成功或失敗而發生變化。
此外，我們也需要考慮如何能在整個產品生命週期中獲得用戶的真實反饋，以改善機器學習系統。機器學習系統的表現，區別在於所設計的交互模式是否可以方便提供用戶反饋以及是否能夠快速顯示反饋的好處。
避免讓機器往錯誤的方向學
許多機器學習的應用仍舊是監督式學習的方式，意即標籤資料的品質與數量會大幅決定模型訓練的好壞。當要預測的目標相對主觀時，挑戰就來了，比如說要推薦一篇文章是否使用者會感興趣，或是 email 回覆的內容是否恰當。訓練模型需要時間，好的標籤資料通常難以簡單取得，所以最好在一開始的時候就做一連串合理的假設，這些假設通常採取的格式會是：
對於處於 _____情況中的 _____ 使用者，我們假設他們更喜歡 _____，而不是 _____。
如果用音樂推薦的功能來舉例，可能會是：對於第一次使用曲目推薦服務的使用者，我們假設他們更期待看到他們之前聽過的歌，而不是對他們來說全新的曲目。
然後，盡快將這些假設套用到產品的原型中，以取得用戶的反饋。並與在某個領域的專家合作，如此一來，可以確定哪些假設看起來更加的「真實」。然而，在開始大規模收集數據和進行標記之前，需要使用由專家從真實用戶數據中挑選的範例進行第二輪的驗證，用戶應該測試一個像真的一樣的原型，並知道自己正和一個人工智慧的產品在互動。
透過這樣的驗證，可以產生大量的範例組合，這將為我們提供一個數據收集路線圖，一套用來訓練模型的標籤集，以及一個用來設計如何規模化的完整框架。
產品設計，應是設計師和工程團隊，資料科學家共同創造的過程
與一般產品設計的流程相比，機器學習是一個更具創造力和表現能力的過程。訓練模型的過程通常很緩慢，可視覺化的工具也還不是很出色，工程師在調整演算法的時候，經常需要靠自己的想像力。這部分，或許設計師與產品經理應該一同介入，提供用戶反饋或是產品原型，以幫助他們可以更深入地理解產品原則和體驗的目標。
以上是 Google PAIR (People + AI Research) 的設計師 Jess Holbrook 和 Josh Lovejoy 所發表的七個設計原則。我認為 Airbnb 在結合產品設計與機器學習部分也做得很出色，以下是幾個值得參考的範例：
