AI 答對了，使用者還是不知道怎麼辦。失敗狀態才是 UX 的考題
我看到平台上那張「AI 功能會出錯。PM 要先排驗證」，很有感。裡面提到首次使用、第三次使用、例外輸入要分開驗證，這其實很接近我做 AI 功能時最常踩到的坑。
我以前驗一個 AI 輔助流程，第一輪測試很順。設計稿丟進去，系統可以產出文案，文案也大致答對，大家就開始討論要不要上線。結果真的找 5 個 end user 來測，只有 2 個人知道產出的內容接下來要去哪裡，另外 3 個人以為按下「套用」就會直接覆蓋原本的內容。
模型沒有答錯，UX 卻已經出事了。
從 UX 的角度來看，我現在會把驗證拆成三層。第一層是模型有沒有答對，第二層是使用者有沒有理解系統的邊界，第三層是答錯或操作失敗之後，使用者能不能自己回來。以前我們只做第一層，所以 demo 看起來很漂亮，實際使用卻一直有人卡在「我現在到底能不能相信它」。
我會先測首次使用。
不給完整教學，只放必要的 context，請測試者完成一個任務，然後問他三件事：你覺得系統剛剛做了什麼，你覺得它沒有做什麼，如果要反悔你會按哪裡。這三題比單純問「好不好用」有效很多。
有一次我們把 AI 產出的建議用淺灰色放在輸入框裡，設計上覺得很輕，不會干擾使用者。測試時卻有 4 個人以為那是已經儲存的內容，直到他們重新整理頁面才發現什麼都沒有。後來我把狀態改成明確的 preview card，加上「套用到草稿」和「捨棄建議」兩個 action，理解錯誤就少很多。
第三次使用，我會故意測信任感。
第一次使用的人通常會照著引導走，第二次還可能記得規則，第三次開始才會用自己的方式操作。這時候我會觀察他是不是開始跳過提示、直接接受結果，或是在答案不完整時繼續往下送。AI flow 很容易在第三次使用之後變成自動駕駛，這才是風險變高的時候。
我們曾經把「這是 AI 生成，請確認」放在第一次 onboarding，之後就不顯示。原本以為使用者已經知道了，但一週後回訪，6 個人裡有 4 個人說他們以為後面的結果都是系統查到的資料，不是生成內容。後來我把提示從一次性說明，改成跟每次結果一起出現的簡短 status，並且在高風險欄位旁邊標出來源。少一點 onboarding，反而多一點當下的理解。
例外輸入最容易被排到最後，卻最值得先測。
空白、貼上一大段格式混亂的文字、輸入一個系統沒看過的專有名詞，這些都比正常 prompt 更接近真實世界。我會準備至少 3 種例外：資訊不完整、內容互相矛盾、使用者想要的事情超出功能範圍。
以前我們遇過一個很尷尬的狀況。使用者輸入缺少日期的活動需求，模型回了一段很完整的建議，畫面也沒有報錯。使用者以為日期已經被系統推斷，後面才發現整個排程錯一天。現在遇到缺少關鍵欄位時，我們不讓模型硬補，而是把缺口直接標出來，提供「補充日期」的入口。系統可以失敗，但不能讓人誤以為它已經完成。
我現在在 Figma 裡畫 AI flow，不只畫 happy path。至少會多畫四種狀態：生成中、生成失敗、結果不完整、使用者撤回。每一種狀態都要回答同一件事，使用者下一步能做什麼。失敗畫面如果只有「請稍後再試」，那其實是把 debug 工作丟回 end user。
我自己最在意的是撤回。AI 很常把使用者帶到一個不確定的結果，這時候「重新生成」不一定是復原。真正的復原應該能回到上一個可理解的狀態，保留原文，讓人看得到變更前後。曾經有一版只有一個 Undo icon，沒有文字，測試時 5 個人有 3 個人找不到。改成「回到原稿」後，才真的有人敢試 AI 建議。
所以現在有人說「模型準確率有 90%，可以上線了嗎」，我會先問，剩下那 10% 出錯時，使用者看得懂發生什麼事嗎？他能不能不求助客服就回來？
AI 功能的驗證，不只是在考模型。也是在考我們有沒有把系統的邊界、失敗方式和退路，設計成使用者看得懂的東西。這部分如果沒有測，準確率再漂亮都只是 demo 的安全感 😅
作者：Ruby Chou