為自主代理進行設計會帶來獨特的挫折感。我們將一項複雜的任務交給人工智慧，它將消失 30 秒（或 30 分鐘），然後返回結果。我們盯著螢幕。有效嗎？難道是出現幻覺了？它是否檢查了合規性資料庫或跳過了該步驟？ 我們通常會用兩個極端之一來應對這種焦慮。我們要么讓系統成為一個黑盒子，隱藏所有內容以保持簡單性，要么我們恐慌並提供資料轉儲，將每個日誌行和 API 呼叫串流傳輸給用戶。 這兩種方法都沒有直接解決為用戶提供理想透明度所需的細微差別。 黑盒子讓使用者感到無能為力。資料轉儲造成通知盲目性，破壞了代理承諾提供的效率。使用者會忽略源源不絕的資訊流，直到出現問題為止，此時他們缺乏修復它的上下文。 我們需要一種有組織的方式來找到平衡。在我之前的文章「為代理 AI 進行設計」中，我們研究了建立信任的介面元素，例如預先顯示 AI 的預期操作（意圖預覽）以及讓用戶控制 AI 自行執行的操作（自主撥號）。但知道要使用哪些元素只是挑戰的一部分。對於設計師來說，更困難的問題是知道何時使用它們。 您如何知道 30 秒工作流程中的哪個特定時刻需要意圖預覽，以及哪些可以透過簡單的日誌條目進行處理？ 本文提供了一種回答該問題的方法。我們將逐步完成決策節點審核。這個過程讓設計師和工程師在同一個房間將後端邏輯映射到使用者介面。您將學習如何確定用戶需要了解人工智慧正在做什麼的更新的確切時刻。我們還將介紹影響/風險矩陣，該矩陣將有助於確定要顯示的決策節點的優先順序以及與該決策配對的任何相關設計模式。 透明時刻：案例研究範例 以 Meridian（非真名）為例，這是一家使用代理人工智慧來處理初始事故索賠的保險公司。用戶上傳車輛損壞的照片和警方報告。然後，代理人消失一分鐘，然後帶著風險評估和建議的支付範圍回來。 最初，Meridian 的介面只是顯示計算索賠狀態。使用者變得沮喪。他們已經提交了幾份詳細文件，並且不確定人工智慧是否審查了警方報告，其中包含了從輕處罰的情節。黑盒子造成了不信任。 為了解決這個問題，設計團隊進行了決策節點審核。他們發現人工智慧執行了三個不同的、基於機率的步驟，其中嵌入了許多較小的步驟：
影像分析代理將損壞照片與典型車禍場景的資料庫進行比較，以估計維修成本。這涉及到置信度得分。 文本審查它掃描了警方報告中影響責任的關鍵字（例如過失、天氣狀況、清醒）。這涉及對法律地位的機率評估。 保單交叉參考它將索賠詳細資訊與使用者的特定保單條款進行匹配，搜尋例外情況或承保範圍限制。這也涉及機率匹配。
團隊將這些步驟變成了透明時刻。介面順序更新為：
評估損壞照片：與 500 個車輛碰撞剖面進行比較。 審查警方報告：分析責任關鍵字和法律先例。 驗證保單承保範圍：檢查您的計劃中是否有特定的排除項目。
系統仍然花費相同的時間，但有關代理內部運作的明確溝通恢復了使用者的信心。使用者明白人工智慧正在執行其設計的複雜任務，如果最終評估似乎不準確，他們確切地知道應該將注意力集中在哪裡。這種設計選擇將焦慮的時刻轉變為與使用者聯繫的時刻。 應用影響/風險矩陣：我們選擇隱藏的內容 大多數人工智慧體驗都不缺少在處理過程中可能顯示的事件和決策節點。審計最重要的結果之一是決定哪些內容不可見。在 Meridian 範例中，後端日誌為每個聲明產生 50 多個事件。我們可以預設顯示每個事件，因為它們是作為 UI 的一部分進行處理的。相反，我們應用風險矩陣來修剪它們：
日誌事件：Ping 伺服器West-2 用於冗餘檢查。 過濾器判決：隱藏。 （低風險，高技術性）。
日誌事件：將維修估算與 BlueBook 值進行比較。 過濾器判決：顯示。 （高風險，影響用戶的支出）。
透過刪除不必要的細節，重要資訊（例如覆蓋範圍驗證）更具影響力。我們創建了一個開放的介面並設計了一個開放的體驗。 這種方法的理念是，當人們看到工作正在完成時，他們會對服務感覺更好。透過展示具體步驟（評估、審查、驗證），我們將 30 秒的等待時間從擔心的時間（「它壞了嗎？」）改為感覺有價值的東西正在被創建的時間（「它正在思考」）。 現在讓我們仔細看看如何審查我們產品中的決策過程，以確定需要清晰資訊的關鍵時刻。 決策節點審核 當我們將透明度視為一種風格選擇而不是功能需求時，透明度就會失敗。我們傾向於問：「使用者介面應該是什麼樣子？」在我們問「代理人實際上決定什麼？」之前 決策節點審核是一種使人工智慧系統更易於理解的簡單方法。它的工作原理是仔細規劃系統的內部流程。主要目標是找到並明確定義系統停止遵循其設定規則並根據機會或估計做出選擇的確切時刻。透過映射這種結構，創建者可以直接向使用系統的人展示這些不確定點。這將系統更新從模糊的陳述轉變為關於人工智慧如何得出結論的具體、可靠的報告。 除了上面的保險案例研究之外，我最近還與一個團隊合作建立了一個採購代理。該系統審查了供應商合約並標記了風險。原本，螢幕上顯示的是一個簡單的進度條：「正在審核合約。」使用者討厭它。我們的研究表明，他們對缺失條款的法律影響感到焦慮。 我們透過進行決策節點審核來修復此問題。我在本文的結尾處列出了用於進行此審核的分步清單。 我們與工程師進行了一次會議，並概述了系統的工作原理。我們確定了「決策點」——人工智慧必須在兩個好的選項之間做出選擇的時刻。 在標準電腦程式中，過程很明確：如果 A 發生，則 B 總是會發生。在人工智慧系統中，這個過程通常是基於機會的。 AI 認為 A 可能是最佳選擇，但確定性可能只有 65%。 在合約系統中，我們發現人工智慧根據我們公司的規則檢查責任條款的時刻。這很少是完美的匹配。 AI 必須決定 90% 的匹配度是否夠好。這是一個關鍵的決策點。
一旦我們識別了這個節點，我們就把它暴露給使用者。該介面不再是“審查合約”，而是更新為：“責任條款與標準範本不同。分析風險等級。” 這次具體的更新給了用戶信心。他們知道代理人檢查了責任條款。他們了解延遲的原因，並相信後端正在發生所需的操作。一旦代理生成合同，他們也知道在哪裡進行更深入的挖掘。 要檢查人工智慧如何做出決策，您需要與工程師、產品經理、業務分析師和做出影響人工智慧工具功能的選擇（通常是隱藏的）的關鍵人員密切合作。畫出該工具所採取的步驟。標記過程因滿足機率而改變方向的每個點。這些是您應該注重提高透明度的地方。 如下圖2所示，決策節點審計涉及以下步驟：
將團隊聚集在一起：引入產品負責人、業務分析師、設計師、關鍵決策者以及建立人工智慧的工程師。例如， 想像一個產品團隊建立了一個人工智慧工具，旨在審查混亂的法律合約。該團隊包括使用者體驗設計師、產品經理、使用者體驗研究員、擔任主題專家的執業律師以及編寫文字分析程式碼的後端工程師。
繪製整個過程：記錄人工智慧採取的每一步，從使用者的第一個動作到最終結果。 團隊站在白板前，勾勒出關鍵工作流程的整個序列，其中涉及人工智慧在複雜合約中搜尋責任條款。律師上傳五十頁的 PDF → 系統將文件轉換為可讀文字。 → AI 掃描頁面以尋找責任條款。 → 使用者等待。 → 片刻或幾分鐘後，工具會在使用者介面上以黃色反白顯示找到的段落。他們也為該工具支援的許多其他工作流程執行此操作。
查找不清楚的地方：查看流程圖，尋找人工智慧比較沒有完美匹配的選項或輸入的任何位置。 團隊查看白板以發現不明確的步驟。將圖像轉換為文字遵循嚴格的規則。尋找具體的責任條款涉及猜測。每家公司對這些條款的編寫方式都不同，因此人工智慧必須權衡多個選項並做出預測，而不是找到精確的單字匹配。
確定「最佳猜測」步驟：對於每個不清楚的點，檢查系統是否使用置信度分數（例如，是否有 85% 的把握？）。這些都是人工智慧做出最終選擇的點。 系統必須猜測（給出機率）哪些段落與標準責任條款非常相似。它為其最佳猜測分配一個置信度分數。這個猜測就是一個決策節點。介面需要告訴律師它正在突出顯示潛在的匹配項，而不是說明它找到了明確的條款。
檢查選擇：對於每個選擇點，計算出具體的內部數學或正在進行的比較（例如，將合約的一部分與保單進行匹配或將破損汽車的圖片與損壞汽車照片庫進行比較）。 工程師解釋說，系統將各個段落與過去公司案例中的標準責任條款資料庫進行比較。它計算文本相似度分數，以根據機率決定匹配。
編寫清晰的解釋：為使用者建立訊息，清楚描述人工智慧做出選擇時發生的特定內部操作。 內容設計師為此時刻編寫了一條特定的訊息。文字內容如下：將文件文字與標準公司條款進行比較，以識別潛在的責任風險。
更新畫面：將這些新的、清晰的解釋放入使用者介面中，取代「審查合約」等模糊訊息。 設計團隊刪除了通用的處理 PDF 載入旋轉器。當人工智慧思考時，他們將新的解釋插入文件檢視器正上方的狀態列。
檢查信任：確保新的螢幕訊息為用戶提供任何等待時間或結果的簡單原因，這應該會讓他們感到更加自信和信任。
影響/風險矩陣 一旦你仔細觀察人工智慧的流程，你可能會發現它在很多地方做出選擇。人工智慧可能會為一項複雜任務做出數十個小選擇。將它們全部顯示出來會產生太多不必要的資訊。您需要對這些選擇進行分組。 您可以使用影響/風險矩陣根據 AI 正在採取的操作類型對這些選擇進行排序。以下是影響/風險矩陣的範例： 首先，尋找低風險和低影響的決策。 低風險/低影響
範例：組織文件結構或重新命名文件。 透明度需求：最小。一個微妙的 toast 通知或一個日誌條目就足夠了。使用者可以輕鬆撤銷這些操作。
然後確定高風險和高影響力的決策。 高風險/高影響力
例如：拒絕貸款申請或執行股票交易。 透明度需求：高。這些操作需要工作量證明。系統必須在其行動之前或立即證明其理由。
考慮一個對所有買入/賣出訂單一視同仁的金融交易機器人。它執行 5 美元的交易，其不透明度與 50,000 美元的交易相同。用戶可能會質疑該工具是否認識到透明度對大額交易的潛在影響。他們需要係統暫停並展示其對高風險交易的工作。解決方案是為任何超過特定美元金額的交易引入審查邏輯狀態，允許用戶在執行之前查看推動決策的因素。 將節點對應到模式：設計模式選擇標準 一旦確定了體驗的關鍵決策節點，您必須決定將哪種 UI 模式套用到您將顯示的每個節點。在代理人工智慧設計中，我們引入了意圖預覽（用於高風險控制）和操作審核（用於回顧安全）等模式。在它們之間進行選擇的決定性因素是可逆性。 我們過濾每一個決策節點透過影響矩陣來分配正確的模式： 高風險且不可逆轉：這些節點需要意圖預覽。由於使用者無法輕鬆撤銷操作（例如，永久刪除資料庫），因此透明時刻必須在執行之前發生。系統必須暫停，解釋其意圖，並要求確認。 高風險和可逆：這些節點可以依賴操作審核和撤銷模式。如果人工智慧驅動的銷售代理將銷售線索轉移到不同的管道，只要通知用戶並提供立即撤消按鈕，它就可以自主執行此操作。 透過以這種方式嚴格對節點進行分類，我們可以避免「警報疲勞」。我們只為真正不可逆轉的時刻保留高摩擦意圖預覽，同時依靠行動審核來維持其他一切的速度。
可逆 不可逆 低影響 類型：Auto-ExecuteUI：被動 Toast / LogEx：重新命名文件 類型：ConfirmUI：簡單撤銷選項Ex：存檔電子郵件 高影響力 類型：ReviewUI：通知 + 審閱 TrailEx：向客戶發送草稿 類型：意圖預覽UI：模態/顯式權限Ex：刪除伺服器
表 1：然後可以使用影響力和可逆性矩陣將透明時刻對應到設計模式。 定性驗證：「等待，為什麼？」測試 您可以識別白板上的潛在節點，但必須用人類行為來驗證它們。您需要驗證您的地圖是否符合使用者的心理模型。我使用一種名為“等等，為什麼？”的協定。測試。 要求使用者觀看代理完成任務。指導他們大聲說話。每當他們問問題時，「等等，為什麼要這樣做？」或「卡住了嗎？」或「它聽到我說話了嗎？」 - 你標記一個時間戳。 這些問題顯示使用者感到困惑。使用者感覺自己的控制力正在消失。例如，在一項針對醫療保健調度助理的研究中，使用者觀看代理商進行預約。螢幕靜止了四秒鐘。參與者不斷地問：“是檢查我的日曆還是醫生的日曆？”
這個問題揭示了一個缺失的透明時刻。系統需要將四秒鐘的等待分成兩個不同的步驟：“檢查您的可用性”，然後是“與提供者時間表同步”。 這個小小的改變降低了使用者表達的焦慮程度。 當它僅描述系統操作時，透明度就失效了。介面必須將技術流程與使用者的特定目標連結起來。顯示「檢查您的空閒時間」的畫面由於缺乏上下文而顯得平淡無奇。用戶知道人工智慧正在查看日曆，但他們不知道為什麼。 我們必須將行動與結果結合。系統需要將四秒的等待分成兩個不同的步驟。首先，介面顯示“檢查日曆以查找開放時間”。然後它會更新為“與提供者的日程同步以確保您的預約”。這將技術流程紮根於使用者的實際生活中。 考慮使用人工智慧來管理當地一家咖啡館的庫存。系統遇到供應短缺。介面上寫著「聯絡供應商」或「查看選項」會讓人感到焦慮。經理想知道系統是否正在取消訂單或購買昂貴的替代品。更好的方法是解釋預期結果：「評估替代供應商以維持週五的交貨計劃。」這準確地告訴用戶人工智慧想要實現的目標。 實施審計 您已完成決策節點審核並透過影響和風險矩陣篩選您的清單。現在您已經列出了保持透明的關鍵時刻。接下來，您需要在 UI 中建立它們。這一步驟需要不同部門的團隊合作。您無法使用設計工具自行設計透明度。您需要了解系統在幕後如何運作。 從邏輯審查開始。與您的首席系統設計師會面。帶上你的決策節點圖。您需要確認系統實際上可以共用這些狀態。我經常發現技術系統並沒有揭示我想要展示的確切狀態。工程師可能會說系統只是回到一般的「工作」狀態。您必須推動詳細更新。您需要係統發送具體通知當它從閱讀文字切換到檢查規則時。如果沒有這種技術連接，您的設計就不可能建造。 接下來，讓內容設計團隊參與其中。你有人工智慧行為的技術原因，但你需要一個清晰的、人性化的解釋。工程師提供底層流程，但內容設計師提供溝通方式。不要單獨寫這些訊息。開發人員可能會編寫“執行函數 402”，這在技術上是正確的，但對使用者來說毫無意義。設計師可能會寫“思考”，這很友好，但太模糊了。內容策略師找到了正確的中間立場。他們創建了特定的短語，例如“掃描責任風險”，表明人工智慧正在工作，不會讓用戶感到困惑。 最後，測試訊息的透明度。不要等到最終產品建成才看文字是否有效。我對簡單的原型進行了比較測試，唯一改變的是狀態訊息。例如，我向一組（A 組）顯示一條訊息，上面寫著“驗證身份”，向另一組（B 組）顯示一條訊息，上面寫著“檢查政府資料庫”（這些都是虛構的例子，但你明白這一點）。然後我問他們哪種人工智慧感覺比較安全。你經常會發現某些字詞會引起擔憂，而有些字詞則會建立信任。您必須將措辭視為需要測試並證明有效的內容。 這如何改變設計過程 進行這些審核有可能加強團隊的合作方式。我們不再交付精美的設計文件。我們開始使用凌亂的原型和共享的電子表格。核心工具變成了透明度矩陣。工程師和內容設計師一起編輯此電子表格。他們將精確的技術代碼映射到用戶將閱讀的單字。 團隊在邏輯審查期間會遇到摩擦。想像一下，設計師詢問工程師人工智慧如何決定拒絕在費用報告上提交的交易。工程師可能會說後端僅輸出通用狀態代碼，例如“錯誤：丟失資料”。設計師表示，這不是螢幕上可操作的資訊。設計師與工程師協商創建特定的技術掛鉤。工程師編寫了一條新規則，以便系統可以準確地報告遺失的內容，例如遺失的收據圖像。 內容設計師在此階段充當翻譯者。開發人員可能會編寫技術上準確的字串，例如「計算供應商匹配的置信度閾值」。內容設計師將該字串翻譯成短語，為特定結果建立信任。該策略師將其重寫為「比較當地供應商價格以確保週五交貨」。使用者了解操作和結果。 整個跨職能團隊都會參加使用者測試會議。他們觀察真人對不同狀態訊息的反應。看到用戶因為螢幕顯示「執行交易」而感到恐慌，迫使團隊重新考慮他們的方法。工程師和設計師就更好的措辭達成一致。他們在購買股票之前將文字更改為「驗證足夠的資金」。一起測試可以確保最終的介面既符合系統邏輯，又讓使用者安心。 將這些額外的活動納入團隊的日曆確實需要時間。然而，最終的結果應該是一個更開放溝通的團隊，以及更好地理解人工智慧驅動的工具代表他們做什麼（以及為什麼）的使用者。這種整合方法是設計真正值得信賴的人工智慧體驗的基石。 信任是一種設計選擇 我們經常將信任視為良好使用者體驗的情感副產品。人們更容易將信任視為可預測溝通的機械結果。 我們透過在正確的時間展示正確的訊息來建立信任。我們透過壓倒用戶或完全隱藏機器來摧毀它。 從決策節點審核開始，特別是對於代理人工智慧工具和產品。找出系統做出判斷的時刻。將這些時刻映射到風險矩陣。如果賭注很高，請打開盒子。展示作品。 在下一篇文章中，我們將研究如何設計這些時刻：如何撰寫副本、建立 UI 以及在代理程式出錯時處理不可避免的錯誤。 附錄：決策節點審核清單 第一階段：設定和映射 ✅ 將團隊聚集在一起：引進產品負責人、業務分析師、設計師、關鍵決策者以及建構人工智慧的工程師。 提示：您需要工程師解釋實際的後端邏輯。請勿單獨嘗試此步驟。 ✅ 繪製整個過程：記錄人工智慧採取的每一步，從使用者的第一個動作到最終結果。 提示：實體白板會話通常最適合繪製這些初始步驟。 第二階段：找到隱藏的邏輯 ✅ 查找不清楚的地方：查看流程圖，查找人工智慧比較沒有完美匹配的選項或輸入的任何位置。 ✅ 確定最佳猜測步驟：對於每個不清楚的點，檢查系統是否使用置信度分數。例如，詢問系統是否有 85% 的確定性。這些都是人工智慧做出最終選擇的點。 ✅ 檢查選擇：對於每個選擇點，找出具體的內部數學或正在進行的比較。一個例子是將合約的一部分與策略相匹配。另一個例子涉及將破損汽車的圖片與損壞汽車照片庫進行比較。 第三階段：創造使用者體驗 ✅ 編寫清晰的解釋：為使用者建立訊息，清楚描述人工智慧做出選擇時發生的特定內部操作。 提示：將您的訊息立足於具體的現實。如果人工智慧在當地咖啡館預訂與客戶的會議，請告訴用戶系統正在檢查咖啡館預訂系統。 ✅ 更新畫面：將這些新的、清晰的解釋放入使用者介面中。用具體的解釋替換模糊的訊息，例如審查合約。 ✅ 檢查信任：確保新的螢幕訊息為使用者提供任何等待時間或結果的簡單原因。這應該會讓他們感到自信和信任。 提示：與實際使用者一起測試這些訊息，以驗證他們理解所實現的具體結果。
