我最近一直在做AI產(chǎn)品類的可用性評估有個感受特別明顯傳統(tǒng)那套針對網(wǎng)頁、App打磨體驗的方法論放到AI產(chǎn)品上經(jīng)常失靈。以前我們測一個表單、測一個電商下單流程用戶跑不通就是跑不通問題定位一清二楚?，F(xiàn)在換成一個帶大模型能力的產(chǎn)品功能用戶往往會先夸一句“它挺聰明”但再問兩句就發(fā)現(xiàn)他其實根本不知道這個AI能做什么、該以什么方式配合它更別提在出錯之后怎么自救。這篇文章不準備講空泛的理論而是把我自己的評估思路、一次完整的案例復盤以及實際操作中沉淀下來的最佳實踐都攤開說清楚。內(nèi)容主要適用于正處在“從有人用到用得好”階段的AI產(chǎn)品設(shè)計團隊、用戶體驗研究員和產(chǎn)品經(jīng)理。如果你團隊里正在做智能助手、智能推薦、AI創(chuàng)作這類功能并且被“怎么衡量它好不好用”這件事卡住了那這篇文章大概率能給你一些直接的參考。1. 傳統(tǒng)可用性評估方法在AI產(chǎn)品上的尷尬為什么“確定性思維”會失靈先說一個比較反直覺的觀察我們在傳統(tǒng)軟件上積累的可用性評估經(jīng)驗越是成熟搬到AI產(chǎn)品上越容易“瞎忙”。不是方法本身錯了而是我們默認的一個前提根本不成立——傳統(tǒng)評估假設(shè)產(chǎn)品行為是確定的、邊界是清晰的、成功是有唯一標準的。可AI產(chǎn)品恰恰在這三點上全部不滿足。1.1 傳統(tǒng)評估體系的基石預定義任務(wù)與確定性結(jié)果傳統(tǒng)的可用性測試核心是“任務(wù)驅(qū)動”。選幾個典型用戶給他們幾條明確的任務(wù)路徑比如“完成賬單支付”“篩選出符合條件的高潛客戶”然后觀察用戶什么時候迷路、哪里點錯、哪里停頓太久。分析師手里有一張明確的完成路徑圖用戶偏離路徑就能被標記為“可用性問題”。完成率、任務(wù)時長、錯誤率這三個指標一出來功能好不好用基本就有定論了。這套邏輯在AI產(chǎn)品上會遇到一個非常直接的問題AI產(chǎn)品的正確行為不是一條路徑而是一個分布。舉個例子你讓用戶在智能客服里問一句“我上個月退貨的錢什么時候到賬”系統(tǒng)可能給出完全不同的幾種回應方式也許直接調(diào)出了訂單狀態(tài)也許反問用戶退款單號甚至可能在檢索不到準確上下文時給出一段泛泛的說明。沒有哪個路徑是官方定義的“唯一正確路徑”。那評估人員就難辦了到底算用戶完成了任務(wù)還是沒完成用戶停頓三秒是在思考怎么措辭還是因為不理解AI的回答傳統(tǒng)可用性測試里那種“十個用戶測完問題清單列出來按嚴重級別排優(yōu)先級”的做法在AI產(chǎn)品上經(jīng)常排不出有效優(yōu)先級因為我們連“什么算壞”都還沒有統(tǒng)一口徑。1.2 AI系統(tǒng)的三大特性讓舊標準失效非確定性、模糊性、學習性我把AI產(chǎn)品對舊評估體系的挑戰(zhàn)提煉成三個本質(zhì)特性理解了它們后面所有方法調(diào)整都可以從這里推導出來。第一個是非確定性。同一個問題同一個用戶在同一天換一種問法系統(tǒng)輸出可能完全不一樣。這不是bug而是大模型類產(chǎn)品的本質(zhì)屬性。既然系統(tǒng)輸出是概率性的那評估就不能再看“單次回答對不對”而要看“多次交互中系統(tǒng)是否穩(wěn)定地幫用戶解決問題”?？珊芏鄨F隊還在用“每次點開結(jié)果必須一致”的確定性產(chǎn)品標準去要求AI功能得出的結(jié)論自然是又困惑又挫敗。第二個是模糊性。傳統(tǒng)軟件的任何按鈕、字段、狀態(tài)提示都是可以被精確描述的用戶明白“保存按鈕點了就是存了”。AI產(chǎn)品不一樣用戶對AI能力的期望邊界天然是模糊的。一個AI寫作助手到底能不能理解“幫我寫得更有說服力一點”一種商務(wù)場景下的說服和一種學術(shù)上的說服是同一件事嗎用戶自己都說不清楚產(chǎn)品就更難定義“做到什么程度算做好了”。第三個是學習性。好的AI產(chǎn)品用戶會越用越順因為它依據(jù)上下文反饋動態(tài)調(diào)整自己。可這也意味著用戶在第1次和第20次使用時的體驗是完全不同的。傳統(tǒng)評估測的是“用第一次的感受”而AI產(chǎn)品評估必須考慮“用了一段時間后的感受”這導致評估周期拉長執(zhí)行難度明顯提升。傳統(tǒng)可用性評估默認“產(chǎn)品是死的用戶去適應它”而AI產(chǎn)品的可用性評估必須意識到“產(chǎn)品也在適應人”。這一層認知不轉(zhuǎn)變所有后續(xù)操作都會擰巴。2. AI產(chǎn)品可用性評估應該關(guān)注什么從“好不好用”到“信不信得過”既然舊的“任務(wù)完成率思維”撐不住了那AI產(chǎn)品可用性評估到底該看什么我這幾年的體感是可以將評估顆粒度從“功能好不好用”轉(zhuǎn)向“用戶信不信得過”這是AI產(chǎn)品可用性評估與傳統(tǒng)產(chǎn)品在內(nèi)部邏輯上最顯著的分野。2.1 可理解性是AI可用性的第一道門檻“信不信得過”的第一件事是用戶能不能理解AI在做什么以及為什么這么做。傳統(tǒng)產(chǎn)品的理解成本很低按鈕叫“保存”點了就保存。AI產(chǎn)品不是這樣。用戶給出一個模糊意圖系統(tǒng)反饋一長串生成結(jié)果這個過程在用戶眼里是個黑箱。用戶不知道系統(tǒng)是依據(jù)什么邏輯生成這個答案也不知道這個答案的可信程度如何這就是許多“用戶覺得AI沒用”的核心來源。去年我參與評估一個智能文檔助手功能的早期版本用戶問“把第二章的結(jié)論放進摘要里”系統(tǒng)真的做了這件事但從結(jié)果看自然不足以讓用戶滿意。問題在于用戶看到新的摘要出現(xiàn)時并不知道“第二章結(jié)論”是否真的被準確納入也不知道原文里其他重要內(nèi)容是不是被丟棄了。功能本身沒錯但用戶缺失對AI工作的顯性化支撐就失去了進一步使用它的勇氣。所以現(xiàn)在做AI產(chǎn)品可用性評估我第一個看的設(shè)計要素必然是系統(tǒng)是否用自己的表達方式幫助用戶理解“我是誰、我當時怎么想、我操作了什么信息”。產(chǎn)品可以藏住技術(shù)細節(jié)但不能藏住決策過程。那種“一上來就丟答案”的交互模式從可用性角度看是標準的反面教材。2.2 可控性、容錯機制與信任循環(huán)比可理解性更進一步的兩個維度是可控性和容錯機制?？煽匦灾傅氖怯脩裟芊駥I行為進行干預。輸出結(jié)果里能不能編輯、要不要允許用戶否定AI的判斷、用戶能不能按自己的偏好校正參數(shù)和口徑。設(shè)計上多一個“可編輯”“可終止”“可重答”的出口可用性就會上一個臺階。我見到過不少團隊把大量精力花在優(yōu)化模型輸出上但忽略了輸出結(jié)果之后用戶沒有任何抓手去調(diào)整等于是把用戶按在椅子上等著看AI的表演這種失控感對可用性破壞力極大。容錯機制更關(guān)鍵它關(guān)系到信任的建立與崩解。傳統(tǒng)軟件的容錯是“報錯彈窗告知操作無效”用戶處理起來很直接。AI產(chǎn)品的錯往往是有禮貌地答錯它自信地輸出了一篇流暢但建立在錯誤信息上的方案。用戶如果沒有意識去核實就會把錯誤信息當作正規(guī)信息繼續(xù)使用——這種錯誤比彈窗報錯可怕得多。評估AI產(chǎn)品時我會把系統(tǒng)是否具備“承認不確定性”的能力視為核心指標。能夠?qū)Φ椭眯哦冉Y(jié)果直接表態(tài)能夠允許用戶追回上下文重新提問能夠清晰標識出信息出處這些設(shè)計細節(jié)直接影響整個產(chǎn)品的可信度邊界。我認為可以把AI產(chǎn)品的可用性建立在一個“信任循環(huán)”模型上用戶理解系統(tǒng)—用戶嘗試使用—系統(tǒng)回應并給出反饋口徑—用戶判斷反饋質(zhì)量并決定是否疊加干預—系統(tǒng)調(diào)整行為—用戶進一步理解系統(tǒng)。評估的要點就是檢查這個循環(huán)在每個環(huán)節(jié)上是否存在斷點。中斷越頻繁用戶流失越快。3. 一個真實案例智能客服知識庫系統(tǒng)的評估復盤理論說得再多不如一個具體案例。挑一個我覺得最有代表性的項目講透某B2B平臺的智能客服知識庫系統(tǒng)底層是大模型檢索增強生成架構(gòu)面向客戶企業(yè)的運營人員。這個系統(tǒng)在立項初期更多考慮的是“回答準確率”和“知識庫覆蓋度”但上線一個月后客戶反饋極其兩極分化一部分人覺得“很不錯比以前靠人工翻文檔痛快多了”另一部分人直接用“不好用”“也說不清哪里不對”來形容。團隊一開始也很困惑后臺數(shù)據(jù)顯示知識命中率已經(jīng)達到了一個比較好看的數(shù)字為什么還有大量客戶不滿意的聲音后來我們介入做了一次系統(tǒng)性可用性評估問題才真正暴露出來。3.1 項目背景與為什么重新做評估先交代一下這產(chǎn)品的實際形態(tài)。客戶企業(yè)的運營人員需要在系統(tǒng)里向AI提問比如“幫我查一下某商品在華東區(qū)這周的庫存周轉(zhuǎn)率”系統(tǒng)會去檢索后臺知識庫里同步過來的業(yè)務(wù)數(shù)據(jù)基于企業(yè)私有語料庫生成一串回答。傳統(tǒng)客服機器人的經(jīng)驗在這里直接套用了一大半包括歡迎語、快捷問題按鈕、轉(zhuǎn)人工入口等。但系統(tǒng)上線后收到的自然語言提問五花八門遠超出了預設(shè)快捷問題的覆蓋范圍。更麻煩的是很多客戶問題本質(zhì)上不是一個“標準問題”而是一個場景化需求比如“我做了一份月度促銷計劃能不能先幫我看看有沒有和庫存沖突的風險”這種問題。傳統(tǒng)客服問答案的方式在這個場景里根本不適用。重新做評估的核心原因是單一維度的“回答準確率”無法解釋客戶體驗為什么分裂。準確率只回答了“系統(tǒng)輸出是否命中知識卻沒有回答“輸出結(jié)果用戶能否理解”“交互過程用戶是否感到順暢”“出錯之后用戶能否恢復”。對一個存在模糊目標的任務(wù)場景這三項的重要性完全不亞于準確率。3.2 評估設(shè)計與關(guān)鍵發(fā)現(xiàn)這次評估我們采用了兩階段設(shè)計。先做專家評審完成后又找12名真實客戶運營人員做用戶測試每人四種任務(wù)類型三類問法總計約48個測試場景全程錄音并記錄線下操作路徑。對AI產(chǎn)品的評估這里特別想把其中一個關(guān)鍵設(shè)計點拿出來說一說我們要求每個任務(wù)都必須同時以“用戶發(fā)起提問”和“用戶繼續(xù)追問/要求修正”兩個動作來觀察而不是做完一次問答就算任務(wù)結(jié)束。這才觸到了傳統(tǒng)評估沒到過的場景。最終暴露出的問題可以整理成三類每一類都有具體的案例支撐。第一類是目標錨定缺失。大量用戶在提問時只是輸入了一個很模糊的意圖比如“庫存情況怎么樣”系統(tǒng)慣性地給出一段庫存匯總數(shù)據(jù)但用戶看后根本不知道數(shù)據(jù)是否覆蓋了自己關(guān)心的維度。用戶沒有渠道告訴系統(tǒng)“我想要的是華東區(qū)、A類商品、只看周轉(zhuǎn)率”。很多用戶就在這一步選擇了放棄他們沒有理解系統(tǒng)是需要更具體的條件才能獲得高質(zhì)量回應產(chǎn)品也沒有給出任何提示引導用戶補充必要信息。第二類是結(jié)果缺乏可復核性。系統(tǒng)給出的匯總數(shù)據(jù)沒有標注數(shù)據(jù)統(tǒng)計時間范圍和信息來源的文檔。用戶對關(guān)鍵數(shù)字抱有天然不信任的態(tài)度因為沒有依據(jù)可查他們不敢直接把AI生成的結(jié)果放進正式報告里。這個環(huán)節(jié)當時對我們的沖擊很大準確率明明有90%以上但用戶在可用性層面由于無法自行復核所以就等于把可信度折半了。第三類是錯誤恢復渠道嚴重不足。當系統(tǒng)對某個問題回答錯誤或者不完整時用戶能做的操作幾乎只有“重新提問”或者“轉(zhuǎn)人工”。而整個界面沒有任何“修改查詢條件”“歷史對話回顧”“對回答質(zhì)量進行標記”之類的出口。測試里有一個用戶連續(xù)問了三次都沒拿到想要的字段數(shù)據(jù)最后放棄了全程沒有嘗試任何糾偏措施。在我們回放錄音時用戶在第三次提問后的沉默和嘆氣非常值得研究。這類沉默在傳統(tǒng)的“任務(wù)完成率”體系里不構(gòu)成問題但它恰恰是AI交互里最珍貴的信號。系統(tǒng)不提供反饋通道本質(zhì)上是把AI默認設(shè)置的錯誤判斷成本全部轉(zhuǎn)嫁給了用戶這在可用性層面幾乎等于在勸退。3.3 修復后的變化數(shù)字說明問題在拿到問題清單后的部門協(xié)作中我們重點做了四項修復第一在提問界面增加“結(jié)構(gòu)化追問引導區(qū)”當用戶問題包含條件模糊詞時通過復選框提醒用戶補充時間范圍、品類、區(qū)域等篩選條件第二在每次生成結(jié)果底部固定展示“數(shù)據(jù)統(tǒng)計口徑”說明入口用戶點開就能查看當前回答所引用的字段和時間范圍第三把“調(diào)整查詢條件”升級為核心操作視覺層級接近提問框保證修改路徑觸手可及第四增加“回答質(zhì)量追評”功能允許用戶以預期的方式對每條回答做出標記這組數(shù)據(jù)會回流成產(chǎn)品迭代依據(jù)。修復后過了一個月我們復測了同一批任務(wù)場景一組變化的數(shù)字比較有說服力。用戶的平均交互輪次從3.2次下降到2.2次這意味著很多問題用戶能在更少的來回之間解決提問后不進行任何操作直接離開的比例下降了31%說明“一次性提問得不到有效反饋就走人”的情況明顯減少轉(zhuǎn)人工率從27%降至11%系統(tǒng)自主解決問題的比例大幅提升。最有意思的是用戶開始主動使用“修改查詢條件”功能之后系統(tǒng)里沉淀下來的高質(zhì)量追問數(shù)量越來越多知識庫的利用效率也隨之顯著提升。這個案例給我留下的最大認知是AI產(chǎn)品可用性評估真正要解決的問題往往不在模型層和自己設(shè)計的應答質(zhì)量上而在交互層——用戶能不能理解系統(tǒng)、系統(tǒng)能不能向用戶提供反饋機制這些“非模型因素”才是決定體驗生死的關(guān)鍵。4. 可落地的評估方法組合從專家評審到用戶測試的實操細節(jié)講完案例回到方法論和落地操作。我會按照自己實際執(zhí)行時的順序把一套對AI產(chǎn)品有效的評估方法組合拆開講。這套組合以“先借助分析再以測試驗證”的思路貫穿適合大多數(shù)中小團隊直接復用。4.1 “AI診斷式”專家評審針對AI特性的檢查清單常規(guī)專家評審是拿著尼爾森十大可用性原則逐項對照界面。這套做法在AI產(chǎn)品上仍然有意義但需要先做一次“預期轉(zhuǎn)換”。我在實踐里把評審清單重新定義成了三組問題。第一組用戶能否建立準確的AI能力心智模型——這個產(chǎn)品是干什么的、邊界在哪里、哪些問題適合問它是否能通過開場引導文案和示例問題在30秒內(nèi)傳達清楚。第二組交互過程中AI的狀態(tài)和行為是否處于近似透明的狀態(tài)系統(tǒng)在“思考中”“檢索中”“生成中”有沒有給予足夠的顯式反饋用戶能否判斷當前結(jié)果是何時基于哪部分信息生成的。第三組錯誤情境下的恢復效率“AI被用戶問倒”幾乎是必然事件需要檢查有沒有足夠顯性的糾偏手段和兜底路徑。這三組問題可以形成一張內(nèi)部評審打分卡1到5分制每個維度二至三個考察點。這個階段的優(yōu)勢是成本低、速度快通常半天內(nèi)就能覆蓋核心界面和主要對話路徑為后面的正式用戶測試鋪好路。但必須提醒專家評審不能替代真實用戶測試它只能幫你優(yōu)先圈定測試重點區(qū)域因為專家本身對系統(tǒng)的理解遠遠高于真實用戶會系統(tǒng)性低估用戶的理解門檻。4.2 認知走查與會話測試讓用戶與AI“自然對話”而不是“完成任務(wù)”常規(guī)可用性測試最喜歡設(shè)計的“任務(wù)腳本”在AI產(chǎn)品里最容易水土不服。因為設(shè)計腳本的人如果對用戶如何使用AI預設(shè)有偏差腳本本身就變成一種干擾因素?，F(xiàn)在做AI產(chǎn)品測試更建議采用兩種方法組合。第一種是認知走查法。讓用戶在測試過程中出聲思考把他的即時想法、預期、判斷依據(jù)全部口語化表達出來測試人員不干預只記錄。傳統(tǒng)產(chǎn)品里我們用這個方法看頁面信息是否容易被理解AI產(chǎn)品里更適合用它看用戶在對話過程中的心智博弈——對方這句話是什么意思、順著往下該怎么表達、系統(tǒng)給出的回答是否滿足他自己的預期。要特別關(guān)注“這AI怎么會覺得……”這一類的言語信號每一次都是系統(tǒng)心智模型與真實用戶認知之間的天然樣本。第二種我更愿意稱之為自然對話測試。不再為每個用戶下發(fā)固定任務(wù)清單而是給出一個場景目標讓用戶用自己的話去操作。比如場景目標設(shè)定為“你月底需要提交一份區(qū)域銷售復盤請使用這個AI產(chǎn)品盡可能高效地準備數(shù)據(jù)材料”用戶具體怎么提問、怎么追問、怎么使用界面輔助功能完全交給他自己發(fā)揮。最后通過分析完整對話的輪次數(shù)量、用戶的追問邏輯、用戶在哪個階段產(chǎn)生了放棄念頭來判斷可用性狀態(tài)。這種測試腳本上的“刻意松弛”才能還原AI產(chǎn)品在真實環(huán)境中最常見的開放性使用方式。很多通用性很強的發(fā)現(xiàn)就是在這種開放式測試里被挖掘出來的。4.3 彈窗訪談與回溯式測試捕捉“肉眼不可見”的信任問題用戶測試里有一個很容易被忽略的現(xiàn)象AI產(chǎn)品里大量可用性問題表現(xiàn)為“用戶說不出來但我正在悄悄放棄”。傳統(tǒng)產(chǎn)品里用戶點錯按鈕后通常會嘀咕一句“怎么沒反應”AI產(chǎn)品里用戶自己也沒意識到問題只覺得“可能我不會用”“這個工具大概不適合我”然后靜默流失。要想捕捉這類“不可能的可用性問題”我自己試下來最有效的是兩種輕量工具。一是彈窗訪談。在測試界面上設(shè)計一個交互反饋點當用戶完成一次提問后系統(tǒng)彈出一個簡短詢問“剛才的回答對你有幫助嗎選擇‘有幫助’或‘沒幫助’如果選擇‘沒幫助’可以告訴我們可能的原因”。這個動作成本極低但回收的是用戶在真實使用場景中第一時間最接近真實感受的主觀反饋。無論他對答案的評價是否與實際質(zhì)量一致這種“主觀可用性數(shù)據(jù)”本身就很有參考價值。二是回溯式測試。把用戶與AI交互的全過程錄屏測試后在用戶面前逐段回放請他解釋每一步操作背后的思考以及在看到結(jié)果輸出時他內(nèi)心發(fā)生了什么。這種方式特別適合挖掘?qū)υ捪到y(tǒng)中那些“沒有明確報錯但信任逐漸流失”的細微信號。比如用戶在得到回答后沒有點擊任何按鈕就切換了頁面回放時讓他解釋原因他可能會說“這個結(jié)果看起來不太可靠我打算自己重新去后臺查”。這種隱性不信任在傳統(tǒng)的數(shù)據(jù)埋點里完全看不到回溯式測試經(jīng)常會給研發(fā)團隊帶來不小的認知沖擊。5. 一堆踩過的坑和最終沉淀下來的最佳實踐后面這部分內(nèi)容我原本打算寫成標準流程指南后來想了想還是把實操中踩過的坑和最值得帶走的心得放在一起講對正在做AI產(chǎn)品評估的人應該更有參考價值。5.1 那些讓評估失去意義的做法先說我踩過的最大的坑用準確率代替可用性。項目早期做評估匯報時我說的最多的一個數(shù)據(jù)是“模型回答準確率達到87%”那時覺得有了這個數(shù)字就萬事大吉。但在用戶真實場景中用戶最需要的那個回答如果恰好落在錯誤的13%里對用戶而言準確率就是0。準確率是模型維度指標可用性是用戶維度指標兩者之間不能畫等號。更合理的做法是把準確率當成輔助診斷數(shù)據(jù)與任務(wù)完成率、用戶置信度、交互輪次效率交叉分析。第二個坑是測試任務(wù)設(shè)計過于“正式”。早期我們寫任務(wù)腳本會自然寫成“請通過系統(tǒng)查詢?nèi)A東區(qū)上周庫存周轉(zhuǎn)率并判斷是否存在補貨風險”這話沒問題但問題在于真實用戶不會這么說話。他們可能會直接說“幫我看看華東是不是快斷貨了”。這種語法組織上的微小差異可能導致AI系統(tǒng)完全不同的檢索效果。如果給用戶的測試任務(wù)語句過于規(guī)整測試結(jié)果會嚴重高估系統(tǒng)在真實場景中的表現(xiàn)?，F(xiàn)在我在設(shè)計任務(wù)時總會加上一條要求所有測試任務(wù)描述必須口語化研究團隊不給用戶示范“標準提問句式”這一點對自然語言交互型產(chǎn)品極其重要。第三個坑是要特別提醒大型語言模型的“印象管理效應”。在用戶測試中一組對話任務(wù)接一組對話任務(wù)地做用戶很容易對系統(tǒng)整體能力形成一個“它似乎挺會聊”的良好印象但在具體的深度任務(wù)中依然無法完成目標。這類印象分數(shù)如果直接作為可用性結(jié)果呈現(xiàn)會掩蓋很多真實問題。解決方法是把“整體滿意度”和“任務(wù)成功率”分開分析并重點向團隊匯報兩者的差距差距越大說明系統(tǒng)在表層交互上越具備迷惑性深層的對話目標達成能力可能越弱。5.2 從團隊協(xié)作角度分享的三條關(guān)鍵經(jīng)驗第一個經(jīng)驗要無條件把“評估結(jié)果”翻譯成“設(shè)計變更”。AI產(chǎn)品團隊里模型算法工程師和設(shè)計師常常因為語言體系不同發(fā)生雞同鴨講的局面。做評估的人不應該只丟出一份“可用性問題清單”而是幫助其成長為“交互建議”。這次智能客服項目里我們發(fā)現(xiàn)用戶不會主動補充篩選條件于是給出的建議就不是“提示用戶提供更多條件”而是具體到了哪些條件下在界面哪個區(qū)域展示哪類篩選控件。評估若不做這一步翻譯往往可能得不到團隊的足夠重視。第二個經(jīng)驗用“用戶測試的輪次間隔”主動適應AI的迭代節(jié)奏。AI產(chǎn)品迭代速度快傳統(tǒng)產(chǎn)品半年做一次大版本測試在AI產(chǎn)品領(lǐng)域基本不可行?，F(xiàn)在我的做法是“每周一測、每輪二十到三十分鐘、每次聚焦一個交互層改動點”。把可用性測試從階段性沖刺變成持續(xù)的小步快跑才能在模型更新的同時讓交互設(shè)計同步驗證保持體驗的穩(wěn)定性。第三個經(jīng)驗是要在團隊內(nèi)部建立一個統(tǒng)一的“體驗爭議仲裁機制”。AI產(chǎn)品天然存在不確定性針對一個功能做A/B實驗時產(chǎn)品經(jīng)理覺得效果提升用戶體驗研究員發(fā)現(xiàn)另一個維度的信任感下降這類爭執(zhí)幾乎無可避免。我們最后沉淀下來的做法是任何爭議都以“用戶在與系統(tǒng)完成一次完整任務(wù)后的可復述性”作為最終裁決參考。用戶結(jié)束測試后如果能清晰說出系統(tǒng)做了什么、為什么這么做、對自己的業(yè)務(wù)有什么幫助就認定這次交互是有效的反之哪怕數(shù)據(jù)面成功但用戶復述不出來一律按可用性缺陷處理。這個方法看似樸素實際操作中卻能有效拉齊團隊的驗收口徑。5.3 適合重點關(guān)注的度量指標和個人建議最后給同樣在構(gòu)建AI產(chǎn)品可用性評估體系的朋友們列一個小的指標清單。常規(guī)的完成率、任務(wù)時長、錯誤率繼續(xù)沿用但建議補充四個對AI產(chǎn)品更有針對性的指標首次交互成功率用戶第一次提問即獲得滿意結(jié)果的比例不依賴追問修偏、追問修正率用戶在初次得到不滿意結(jié)果后愿意繼續(xù)追問的比例、交互輪次效率每個任務(wù)所需的平均對話輪數(shù)輪數(shù)太多說明系統(tǒng)理解能力存在斷層、用戶信心分用戶在完成任務(wù)后自評對結(jié)果的信任程度1到5分評分低通常意味著結(jié)果不可復核或缺少可信度證明?；仡欉@段經(jīng)歷我在AI產(chǎn)品可用性評估這條路上最大的轉(zhuǎn)折點是接受“AI產(chǎn)品允許有缺陷”這個前提。傳統(tǒng)產(chǎn)品經(jīng)理總在追求零缺陷但AI產(chǎn)品的用戶其實更能接受一個會犯錯的助手他們真正無法接受的是“錯了之后連補救的抓手都沒有”。評估工作的重點與其花大量精力糾結(jié)如何讓模型永遠答對不如好好檢查產(chǎn)品是否在每一個可能的失敗點上都布置了松弛的恢復通道。多準備幾條安全繩遠比強迫模型變成超人更有利于可用性的真實提升。