[AIUX] Ch1–1 當用戶需求遇到 AI
這系列文章為 AlfredCamera 工程和設計團隊閱讀 Google People + AI 內容綱要和討論筆記，期望透過平常設計 AI 產品的設計師和工程師的補充，讓文件中的知識更容易被各種背景的人員吸收應用。由於在討論中也發現 AI 產品設計的中文資料較少，因此整理分享期望能幫助到其他團隊。原文摘要在文中以白底區塊為主，團隊的討論會以灰底區塊呈現，方便大家閱讀。如果有任何建議歡迎留言討論，或來信 hello@alfred.camera 😊
這章節要了解
- AI 適合解決哪種用戶問題
- 除了自動化處理任務，AI 能如何強化人做事的能力
- 如何確保用正確的反饋讓 AI 往正確的方向優化
通常在設計用戶中心的產品時，我們都會定義用戶需求、體驗、我們可以解決的問題等，本章節從三個方面幫助大家了解如何定義 AI 能解決的用戶問題，以及如何衡量體驗成效：
- 找到用戶需求和 AI 技術優點重疊之處
- 評估自動化問題還是強化類問題（automation v.s augmentation）
- 設計以及評估回饋函數（reward function)
一、找到用戶需求和 AI 技術優點重疊之處
藉由訪談、數據、觀察等方式找出用戶需求，是所有用戶中心產品設計的第一步，了解用戶需要被解決的問題才能將產品從技術中心轉換成用戶中心。相關的探索方法很多，可參考 IDEO 工具包，裡面提供許多常用的設計方法簡介。
以跑步 app 為例，用戶需求可能為：
- 用戶想得到更多樣的跑步體驗，以至於不會太無聊而放棄跑步
- 用戶想追蹤跑步記錄，以確保六個月後可以達成 10K 目標
- 用戶想要認識其他程度相當的跑者，互相激勵以持續跑步習慣
接下來是決定要解決哪個問題，在決定前建議先讀 Google AI Principle 以及 Responsible AI Practices。確定自己有考量到各種不同類型的用戶，以確定不會漏掉主要意見（avoid missing out on major market opportunities）以及避免忘記某些用戶（unintentionally exclude specific user groups）。
📝 AI 產品設計與過往數位產品的差異在開發 AI 前，可以先思考一下使用者會在什麼樣的情境下需要使用、如何使用、使用後應該要有怎樣的體驗。但因為大部分的AI技術太新、太少見，也不知道如何應用在產品上，也不知道技術的極限在哪裡，大家比較難以去想像會有什麼樣的問題存在。也因為這樣，AI 與探索使用需求的部分應該是要同時進行，兩邊皆需要取得一個平衡點，並藉由新的 AI 原型不斷的去測試和探索。
1.1 畫出完成一項任務的現行流程
了解用戶現在如何完成目標，可以幫助我們檢視流程中自動化或可強化的部分。如果已經有運行中的 AI 產品，試著用擬真的原型測試了解用戶對於自動化的反應（Wizard of OZ test），並透過觀察用戶對結果的反應驗證假設。
📝 綠野仙蹤法（Wizard of OZ test）是什麼？綠野仙蹤法廣泛應用於心理學、人因工程等實驗場景，強調以實驗人員的人為操作，提供受測者以假亂真的 AI 體驗，以協助產品團隊在投入開發之前就能先判斷 AI 體驗對受測者帶來的影響。常見的案例為用真人回應模擬聊天機器人，讓受測者以為自己真的在跟電腦聊天。科大迅飛事件算是真實的反例XD 用一樣的手法模擬 AI 現場翻譯，並直接放上媒體記者會被拆穿，就比較像在測試投資人的興趣，而不是真的在做用戶研究了。📝 這種方法跟設計思考中推薦用紙模型或是 design sprint 中推薦以假亂真的可用性測試原型差異在哪呢？原型測試相關的方法很多，但核心概念在有限的資源（時間、工作量、開銷等）內取得對進一步資源投入最關鍵的使用者資訊。以擬真度作為一個量尺，偏向低擬真的原型製作成本低、能快速產出大量測試方案、容易因為受測者認知模型差異影響結果，偏向高擬真的原則製作成本較高、對受測者的反應更有信心。在正式進行原型測試時，都需要針對關鍵測試的目標，來決定原型擬真度應該達到什麼等級，能在最少資源投入下取得關鍵結果。AI 產品由於產品特性，才會特別提到 Wizard of OZ 這個以「真人假冒電腦」的方法。
1.2 決定 AI 在哪些問題解決可以創造獨特的價值
有時候簡單的 heuristic review 就可以找出簡單的解決方案，所以務實的評估 AI 適合解決的問題是非常重要的，以下是列出的建議：
AI 可能表現比較好的場景為：
- 推薦客製化內容給不同用戶
📝 實際案例有個很好的案例是阿里巴巴的魯班系統，在雙十一期間繪製 1.7 億張的廣告 banner，實現了業界所謂的「千人千面」（對不同用戶提供不同內容）。
- 對未來事件的預測，例如機票價格評估
- 客製化用戶體驗，例如個人智能家居
- 人性化語言理解（Natural language understanding）
📝 意旨語意分析原文看起來很抽象，實際上就是語意分析應用。例如：紅極一時的微軟聊天機器人和 Grammarly 的文字語氣判斷。這類型的應用特色是設計使用者的反饋篩選，要非常注意 AI 的學習表現，不然「學壞」的速度非常快也因為文字的感染力會造成相對嚴重的傷害。
- 辨識，例如一般的相簿辨識「人」、「車」、「某個東西」。
- 監測會隨時間變化的偶發事件（Detection of low occurrence events that change over time）
📝 實際案例常見用在金融系統的詐騙偵測，由於兼具隱私、發生頻率不高等特性，很適合透過 AI 根據提款的頻率、提領金額等因素判斷出可疑的金融操作。例如一名用戶一直以來信用卡交易金額為數百元，有一天突然刷了五六十萬，信用卡公司一定會打電話聯絡，把這樣的任務交給 AI ，能監測更多人類很難察覺的因素。案例分享一：某領頭銀行會把用戶填寫信用卡資料的行為模式進行評分，從分數裡面發現異常值，但目前異常值的部分還是要以人工去判斷是否真的有異常。案例分享二：某國際知名數位支付工具非常重視防止伴隨海量用戶出現的大量詐騙和盜用，會利用 AI 透過許多人類無法進行的監督因子，例如輸入密碼的方式和速度來判斷該交易是否為用戶本人進行。案例分享三：Google 推出的 reCAPTCHA 服務，幫助網站去屏蔽機器人，但以往都要干擾人去填寫問題或勾選圖片，但是 v3 宣稱用機器學習，直接透過此前用戶的瀏覽方式，就可以知道他是不是機器人。
案例分享四：知名監控服務阿福管家（自己說）的 Server Team 也有用過 AWS 的一項監控服務，因為我們機器的流量高低峰其實時間一長有個固定的 pattern，運用 AI 去找出這個 pattern，發現流量突然過低或過高就會跳出警告。
- 特定領域的機器人
- 動態內容（但要確定動態內容比起固定內容有益）
AI 不一定能發揮的場景為：
- 當場景需要保持可預測性。有時候可預測的體驗是比較好的，例如取消按鈕一直在同一個位置，動態變化位置反而可能造成用戶困擾。
- 提供靜態或有限制的訊息，例如信用卡輸入欄位。
- 減少高成本的錯誤。如果出錯的代價很高，且超過微幅成長帶來的好處。
- 當專案追求完全透明的過程。例如客戶想清楚了解代碼中所有事情，AI 可能無法提供解釋。
📝 無法解釋？AI 是一個黑箱子嗎？其實要看對於「解釋清楚」的定義是什麼，AI 模型很類似大腦的神經網路系統，可以試圖了解這套系統怎麼運作，但相關知識太深太過複雜，其實很難讓一般人快速理解，此時有解釋跟沒解釋好像差不多... 在這種情況下，工程領域有兩派觀點，一種是直接說不要問(x)不能解釋(o)，一種是試圖去講人話(x)解釋(o)。像是我們的公司的人臉辨識，可以從訓練資料去解釋 AI 學到了什麼，也可以從神經元節點去解釋學習的邏輯，但這個已經超過一般人類能理解的範圍，幾乎是關於神經科學的部分了。光是這份文件在講的基礎 AI 觀念就已經非常多知識，很難想像怎麼在現在跟用戶或是客戶講述實務操作。或許大家從這份文件的基本知識慢慢建構起基本概念後，會有助於對於這個新領域的理解吧。
- 針對提高速度和降低成本進行開發，如果快速進入市場是優先目標，那 AI 可能無法給予幫助。
- 自動化高價值任務。如果用戶明確指出不想自動化某些任務，那最好不要干擾用戶。
📝 補充：當環境會隨時間和結果快速進行變化，也不適合使用 AI 預測。團隊認為這個場景也不適合使用 AI，但比較不屬於文件中列的 6 點，在這邊進行說明：有些會隨時間和使用者互動在短時間內大幅變化的場景，例如投資預測，也不適合使用人工智慧提供解決方案。金融環境本身的特性會因為投資者的行為進行大幅變化，會導致 AI 的預測結果（報了某支股票）引發的使用者行為（投資者依照預測大量進場）立刻改變了環境（原本沒有人買 A 股，變成大家都買 A 股），由於環境改變了，原本的預測也在短時間內失效。因此有這種特性的場景，都比較不適合使用 AI 提供解法。「當過去跟未來的情況已經非常不一樣，你就沒辦法用過去的資料去train未來。」
二、完全自動化 v.s 機器輔助（automation v.s augmentation）
第一節中我們確定了適合用 AI 解決的用戶問題，接著要決定哪種解法比較適合，首先要區分的一個大方向就是：用 AI 協助用戶完全自動化進行任務或是以機器輔助部分任務。
📝 翻譯與原文差異原文的 automation 和 augmentation 直譯為「自動」和「增強」，團隊讀完整章後，認為這兩者定義偏向 AI 協助使用者完成全部或是部分的任務，因此翻譯為完全自動化（automation）和機器輔助（augmentation），但為了避免轉譯造成的誤解，以下盡量以原文撰寫。歡迎有更貼切、更好理解的中文說法可以留言告訴我們。
什麼適合 automation?
automation 通常適用於追求以下目標的場景：
- 增加效率
- 增加人身安全
📝 人身安全（human safety）聽起來很抽象，但其實滿常聽到相關應用，例如自動駕駛（避免酒駕、人為車禍)、救護、危險探測等工作。但這個部分也常牽涉到比較多的道德、哲學討論，從科學的角度來看，應該要讓機器代替人類進行這些任務會比較有效率、對整體有利，但實務上人類還是比較難接受讓機器完全控制車子，甚至在危急時刻（例如要撞上人了）決定要採取什麼行動。如何讓使用者接受 AI 就牽涉到如何以 UX 的角度去跟用戶「解釋」讓大家的感受是正面的，畢竟用戶的感知會影響到大家想不想用或接不接受這樣的AI 產品。- 減少討厭的任務量
📝 又是道德問題的確重複又瑣碎的任務讓機器完全自動化是最棒的作法，但這些任務既然在過去都使用大量人力解決，需要謹慎考慮替換成機器人後，也會放大人類的一些缺點。例如亞馬遜曾使用 AI 面試，放大了性別歧視，導致男性的錄取率明顯高於女性，也讓大家質疑這樣的工作是否適合以 AI 進行。這樣的問題在人工面試的時候就有了，並不是真的是 AI 的問題，這是因為AI的資料都是由人去訓練出來的，AI 在道德上有什麼錯誤其實很可能都是人本身就有這些錯誤。但由於人對於機器特別嚴格，因此在產品設計時要特別注意不要讓產品放大了不好的一些面向。這個討論在第二章有更多的詳細說明。另一個案例「為了地球利益，建議你拿刀刺心臟」！亞馬遜AI助理勸主人自殺也是一個負面的案例，或許在檢討機器之餘，我們也要檢討一下自己...
- 開創不自動化就無法開始的任務
automation 通常是用 AI 的強項彌補人類工作上的弱勢，例如整理相簿。如果你的體驗流程包含以下特點，可以考慮往 automation 的方向產生解決方案：
- 當人們缺乏完成任務的知識或能力
- 當流程中的任務大多為無聊、重複、尷尬甚至危險
什麼適合 augment?
- 增加用戶在執行任務中的正面情緒
- 提供比自動化更高層次的用戶控制（user control）
📝 User Control在這份文件中會滿常看到 user control，聽起來是個模糊的概念，在 UX 上其實是個常見的設計原則之一。Control is giving your users the control to do what they want or the option to undo something if it all goes to pot. If a user deletes something by mistake and you give an ’undo’ option, you’re giving the user control. 簡單來說就是給用戶反悔的權利。
- 營造更大的責任感和滿足感
- 幫用戶成果規模化
- 增加創造力
augmentation 的機會不一定跟 automation 是完全獨立的，但它們通常更複雜、強化天生的人類特質、強調個人價值。
- 人們享受任務過程
- 當個人對任務成果的責任為必要且重要
- 高風險
- 難以描述的特定偏好，例如室內裝潢
三、設計以及評估回饋函數（reward function)
任何 AI 模型都以回饋函數（reward function/objective function/loss function）為依據，這是一組讓 AI 模型預測對和錯的公式，模型會不斷優化這個操作並完成最終體驗。設計過程應該是跨團隊協作，一起思考可能的結果並綜合結論。這樣的過程有助於提前看到坑，避免踩雷。
模型訓練的目標，算是一種模型訓練到後面的考試機制，利用獎勵函數/目標函數/損失函數來判斷模型有沒有接近想要的樣子。若考試沒過就要再訓練，訓練到考試通過了才停止。
3.1 衡量 positive 和 negative
binary classifiers 是一種用來預測標的物是否屬於某個類別的模型，他的預測有4 種可能的結果：
- True positive: 模型正確預測了一個正面結果，例如建議跑者適合的路線
- True negative: 模型正確預測了一個負面結果，例如沒有建議跑者不喜歡的路線
- False positive: 模型錯誤預測了一個正面結果，例如建議跑者不喜歡的路線
- False negative: 模型錯誤預測了一個負面結果，例如沒有建議跑者喜歡的路線
衡量 false positive 和 false negative 會是定義體驗的關鍵決定因素，兩者同樣權重是理想狀態，但現實生活中，錯誤預測對用戶造成的影響不可能是相等的。例如一個誤響的警報以及火災中沒有響起的警報相比，同樣是錯誤預測，後者明顯更嚴重。但換句話說，偶爾推薦錯誤歌單給用戶並不會造成太大影響。透過信心程度指標，可以減輕錯誤預測帶來的負面影響。
3.2 考量精確度和召回率
精確度和回收成本是定義錯誤類型的兩個維度。
精確度(precision) = true positive/(true positive + false positive)
當精確度越高，我們對模型輸出正確預測的信心度就越高，但要小心這個指標可能排除一些事件，導致 false negative 增加。
例如一個講求精確度的跑步 app 可能不會推薦每一條用戶「可能」會喜歡的路線，但它能有高度信心推薦的路線用戶會喜歡，整體來說推薦的路線數量會偏少。
📝 應用案例其他適合的場景例如：製作飛機螺絲，需要謹慎判斷合格的螺絲，不合格就應該重做。此時就應該在判讀上追求精確度。另外像是阿福管家的人臉辨識，寧願多紀錄偶發的錯誤偵測，也不希望追求精確而不小心遺漏了陌生人的錄影（欸當然理想上兩種都不要發生啦...但相較之下還是有輕重之分），因此安全系統通常也會以追求精確度為主要衡量指標。
召回率 (recall)= true positive/(true positive + false negative)
當召回率越高，我們對模型推薦所有相關預測的信心度就越高，但可能會納入一些事件，導致 false positive 增加。
例如一個講求召回率的跑步 app 可能傾向推薦所有用戶可能會喜歡的路線，即使部分推薦可能不會受到喜愛，系統會產生較多推薦。
我們需要確保用戶在這兩者間達成平衡，有時用戶希望可以看到一些精確度較低的結果，以確定系統有考量所有可能結果。有時候給出精確度較低的結果，會造成用戶信任減少。應該根據用戶的期望以及完成任務的心情，綜合決定適合的目標。
📝 應用案例例如檢查癌症，誤判有癌症雖然也很嚇人，但通常會再做多次檢查進行確認，但有癌症卻沒有檢查出來卻是一件很嚴重的事。因此在醫療判讀系統會以追求召回率為主。又如廣告商可能透過 AI 預測產品的潛在客戶並投放廣告，也會傾向多投放給有可能買的受眾，也不要因為追求精確而放過潛在付費客戶。
📝 我什麼都要！試試看 F1 score (F1 Measure)如果覺得精準度和召回率一樣重要(或是不特別在意某方面的時候），就要用 F1 score 把這兩個指標取一個平衡。這種指標適用於有標準答案的場景，例如辨識圖片是否有人（有明確的 yes/no），沒有標準答案的場景例如推薦模型就比較不適合進行 F1 measure。📝 設定指標之後，會優化到什麼程度才算是可以了？以阿福管家的 Person Detection 為例，會看一個特定數值，若這個數字降不下來了，且維持在一個水平，代表已經到達了這個模型優化的極限，就會把它停止。想要再繼續更優化也可以，但會需要找出能造成較大突破的優化方向（要讀論文的意思）。另一個面向也可以設定一個我們想要達到的正確率，例如我們人物預測的準確度若能辨識到60% 的人就可以符合用戶需求，那模型就可以優化到這個標準就停止。這部分在第二章會進一步討論怎麼將資料連結至用戶體驗指標。以UX的角度來說，確保兩者之間的平衡在用戶可接受的範圍是核心重點，有時候用戶希望能看到精確度相對低，但涵蓋的範圍較廣的資料。有時候要追求精確度，否則會導致用戶覺得不準而信任度降低。
3.3 評估 reward function 的結果
提到成功的系統，往往會連結到簡單、固定範圍、立即見效，但當你用這種方式評估 reward function 可能會造成負面結果，要注意以下幾點：
評估對用戶的包容性
確保種族、性別、背景等不同的用戶都有被納入考量，推薦兩個工具協助大家檢查 AI 的數據是否存在偏差 Facets and the What-If Tool ，詳細的指導綱要請參考 Responsible AI Practices。
監控一段時間
需要考慮 reward function 所優化的行為在不同用戶時期的意義，畢竟第一天使用的用戶和第一千天使用的用戶的最佳體驗應該是很不一樣的。
想像潛在的坑
要注意 Second-order effects，想像一下我們的 reward function 優化到極致後，這個系統對於用戶的家人、朋友甚至整個社會的影響是什麼？舉例來說，優化搜索結果體驗是好的，但如果優化如何吸引用戶整天的注意力可能不太好。
3.4 為負面結果負責
在高風險的產業中應用 AI 時，負面結果的監測越來越重要，即使做了練習也不一定會預先想到可能的影響，這是一件需要定期安排時間來檢查指標、不良影響的重要工作項目。
將負面結果與用戶體驗連結起來也是個好作法，以下為一些標準的範例：
- 如果用戶對智能播放的平均拒絕率超過 20% ，應該檢查 ML模型
- 如果超過60%的安裝用戶從未使用，則應該檢查行銷策略
- 如果用戶經常打開 app 但僅停留 25% 的使用時間，則可能重新設定我們的通知頻率 completing runs
隨著產品成熟度越高，需不斷確認用戶反饋以知道產品是對未被考慮的用戶造成影響，如果有這種情形發生，請與這些用戶詳細了解情況，持續用這樣的方式調整產品。也推薦使用社群軟體或 Google Alerts 進行產品監控。
📝 取得有意義的反饋是 AIUX 的重點之一從這章節中我們知道「機器透過反饋學習的結果」在 AI 產品中是產品會不會變好的關鍵，因此如何取得反饋會是其他數位產品比較少接觸的部分。困難點在於取得用戶反饋成為用戶體驗的一部份，若取得手法不佳，導致 AI 不準確，會讓用戶流失進而更難取得有效的反饋，產品會陷入一個負面循環。因此 AI 產品設計在前期就先規劃好如何採集反饋非常重要。UX 進行設計時，要進一步了解模型想要取得什麼，以及透過什麼流程能取得對模型最有意義的資料，抓到一個最佳的平衡點。例如 Google photo 會跳出一個彈窗，詢問用戶某兩張臉是否為同一個人，用戶只要回答 Yes/No，非常簡單。但同樣的設計如果套用至阿福管家的人臉辨識，以明確的「好」跟「不好」的圖示讓用戶對人臉辨識結果進行標注，用戶可能不知道你要問的是人臉判斷準不準，還是這個功能體驗好不好，導致回收的資料其實對模型的幫助不大。📝 關於 AI 模型的準確度AI 模型準不準有太多因素，甚至連「準」或「不準」都要定義清楚。以人臉辨識為例，用戶的相機放在哪個角度？通常與人距離多遠？都會牽涉到模型的準確率。一味追求精確也需要投入大量資源，但也不一定對用戶有意義。若是人臉辨識需要標記用戶，就會需要考慮到資料量怎麼來，要怎麼要求用戶給這個資料？若你真的去要求用戶，會不會造成反感？因此單純討論「準不準」太粗略，後續第二章會更有架構的介紹怎麼在這種模糊性中整理出評估標準。所以，訓練AI模型會根據每個場景不同而有不一樣的需求，開發新的 AI 模型之前，應該要先定義用戶的需求是什麼，或者同步去進行測試，想辦法讓使用者需求和 AI 技術達到一個很好的平衡點，而不是一味地追求越準越好，這樣才能真正落實 User-centered，而不是自嗨的 AI-centered。
本文編者名單 主筆：Weiyun Hsu
編輯：Weiyun Hsu
討論：AIUX 讀書會成員 Cheyu, Frank, Jacky, Ron, 宜婷, Weiyun
