一個人對錯誤的反應——無論是自己犯的還是他人犯的——是一個復雜且常常令人痛苦的心理過程。在本文中，我將解釋為什么幾乎所有的錯誤提示信息的設計都公然無視用戶體驗理論。我將使用交互式原型來展示如何解決這個問題。我還將轉向交互理論，回顧模式的概念，并解釋可逆性、恰當性和及時性的原則。
每個設計師的清單里都會包含“設計錯誤界面”。但即使完成了，程序員仍然會回來說：“還有另一種情況——我們也需要一個錯誤界面。”在這種情況下，程序員是設計的客戶，這很有道理：程序員比任何人都更了解錯誤。設計師和經理們都認同這種方法——但它存在嚴重缺陷。
“我們不是我們的用戶。”設計師們不斷重復這句話。他們想表達的是：不要僅僅依賴自己的專業知識（這不可避免地會過時，而且容易產生職業偏見），而要關注用戶在自然環境中的行為。
所以，問題在于——程序員不是我們的用戶。程序員的行為、思維方式，以及與計算機的聯系與其他人截然不同。我知道我在說什么。我的大多數朋友都是程序員和工程師。我在工作中也經常和程序員交流。我自己也是一名程序員，使用多種語言（從 Swift 和 GLSL 到 Forth 和 Assembly）。但幸運的是，我也是一名非常關注心理學的設計師。那么，讓我來告訴你程序員的一天通常是怎樣度過的：
程序員甚至還沒來得及好好寫點東西——他們停頓了一下，砰，一個錯誤出現了：“空白符缺失”。不知何故，下一行也出現了錯誤（盡管那一行完全沒問題）。左側面板也滿是錯誤。這還不算編譯錯誤。除了紅色圓圈，可能還有黃色圓圈——程序員的大腦已經習慣了忽略這些警告。
如果錯誤來自硬件故障、第三方庫的 bug 或文檔不清晰，程序員不會把這些錯誤當回事。他們會把這些錯誤視為一種有用的工具，幫助找出別人的錯誤。而有些煩人的拼寫錯誤，你會在自己的代碼中苦苦追尋，希望編譯器能自動捕獲它們。那么，關于拼寫錯誤的錯誤消息就是程序員最好的朋友。
簡而言之，程序員對錯誤消息產生了一種容忍度——所有那些帶有感嘆號的圓圈和冗長、說教的紅色文字。
從人體工程學的角度來看，程序員的環境與普通用戶的環境有著根本的不同。因此，設計師絕對不應該采用程序員對待錯誤的態度。如果我們負責設計一個 IDE（集成開發環境），那么我們當然會咨詢程序員——他們是我們的用戶。但在開發其他產品時，最好不要依賴他們的觀點。相反，我們應該咨詢心理學家。
紅色感嘆號會讓用戶想起老師在課堂筆記中批改的內容，并被理解為一種懲罰（當然，除非有人已經培養了對懲罰的耐受力，比如程序員）。那么，心理學是如何看待對錯誤的懲罰的呢？
重要的是不要用消極情緒來強化錯誤，因為大腦對此非常敏感，并會將這種行為標記為不值得投入精力的事情。
我知道有些人看到錯誤信息就會慌亂不已。他們開始點擊所有按鈕，只為讓它盡快消失。這些人很難適應界面，因此他們傾向于完全避免與界面交互。這并不是因為他們愚蠢，而是因為他們是普通人——而不是程序員。
看看這個！幾乎每個字段都用紅墨水劃了線，界面提示你輸入姓名，并要求你填寫，而且是必填項！
但程序員對此完全沒意見。程序員堅信，把笨蛋塞進錯誤里是有用的，這樣他們就不會再試圖用 null 或 undefined 來破壞程序了。程序員和工程師稱之為“傻瓜式防錯”，展現了他們獨特的同理心。
當用戶從一個輸入字段切換到另一個輸入字段時，第一個字段會觸發一個名字很不靠譜的事件：“onblur”。開發者經常用它來進行驗證——以防用戶漏填字段、輸錯生日或忘記郵件中的“@”。問題是：當用戶切換到另一個應用時，“onblur”也會觸發。過去，表單跨越三頁時，空字段是個問題。如今，所有內容都能放在一個屏幕上——很難忽略一個空字段。至于其他的檢查——它們對用戶沒有任何幫助。它們只是另一種“傻瓜式”的玩意兒。但用戶不是傻瓜。當他們想要什么東西時——他們會發揮創造力。我知道有人會修改頁面代碼，以獲取他們嚴格意義上不應該獲得的政府服務。而如今，他們甚至不需要知道如何編寫代碼：只需單擊一下即可打開 DevTools，再單擊幾下——所有驗證都消失了。輸入任何你想要的內容。
通過像傻瓜一樣對待用戶，開發人員產生了兩個問題：第一 - 他們浪費時間構建“保護”，第二 - 他們陷入了一種虛假的安全感（沒有比“通過模糊性實現安全”更糟糕的保護）。
在焦點切換時進行驗證毫無意義，而且問題重重，我甚至不想在這里討論它。讓我們繼續討論主按鈕上的驗證：“繼續”、“提交”等等。
我們與雅虎界面的交互分為三個階段：
讓我們來分析一下。
激活按鈕——這很好，雅虎點贊了。我有一篇名為“禁用按鈕”的文章，解釋了這背后的理論和實踐。如果你仍然認為禁用按鈕對用戶有幫助，那你絕對應該讀一讀。
接下來是可逆性原則。這意味著你可以將界面恢復到初始狀態。雅虎又贏了——你可以重置界面。但只能通過逐個點擊每個字段來實現。這有什么意義呢？為什么僅僅因為你移開焦點，錯誤信息就會消失？這純粹是算法故障！在我關于設計流程的文章中，我指出即使是頂級公司有時也會設計出糟糕的界面，所以不要盲目追隨權威。要遵循科學。
下一個原則是恰當性。用戶點擊了“繼續”按鈕——交互的對象是按鈕，而不是輸入字段。如果按鈕發出某種震動或吱吱聲來表達不滿，這可以理解。但是輸入字段呢？根本沒人碰過它們！它們怎么可能感知到按鈕的情緒呢？只有程序員知道，在代碼中，這些對象是相互關聯的——但外部觀察者一無所知，因為它們之間沒有視覺聯系。
現在來談談時效性原則。設計師用紅色高亮顯示幾個字段，期望用戶做出什么反應？如果所有字段的重要性都一樣，用戶應該先解決哪個字段？這需要對注意力中心進行復雜的討論（這里的注意力中心不是指某個具體的輸入字段，而是“出了點問題”的整體感覺），但我建議保持簡單：界面基本上就是按照“坐下-停留-過來”的順序排列，打破了“一次一個動作”的原則。
這里，一切都非常不對勁！
界面有“模式”的概念。在我的大學里，程序員選修了一門名為“界面設計”的課程，課程內容包括解釋為什么彈出窗口被稱為“模態窗口”。現在，我驚訝地發現，程序員和設計師似乎對如何處理模式一無所知。
老式計算機有一種特殊的“HALT”模式，用于調試錯誤，也稱為“控制臺模式”。如果處理器嘗試執行無效操作，程序將被中斷，處理器將停止運行，并切換到控制臺模式。您也可以通過按下物理“HALT”按鈕手動觸發 HALT 中斷。使用開關或調試程序（在單獨的控制臺上運行），您可以修復錯誤并返回程序執行模式。
“處理器”一詞并非偶然——它源于“進程”。錯誤中斷只能在進程運行期間發生，而不會在處理器停止并處于調試模式時發生。這一事實在我們稍后討論進程和狀態之間的區別時會很有用。
向用戶清晰解釋他們最終進入不同模式的原因和方式至關重要。例如，調試器會顯示導致無效操作的指令地址。同樣重要的是解釋如何返回（記住可逆性原則）。經典的 Norton Commander 完美地詮釋了各種模式：
我見過有人批評這類解決方案：“窗口疊在其他窗口上看起來很丑”。即便接受了這種說法，我仍然無法認同設計師通常提出的替代方案：“我們把這個窗口移除，把錯誤顯示到別的地方，這樣更美觀。” 就好像設計師忘記了自己是工程師，只是拿起畫筆，像個泥水匠一樣把瑕疵掩蓋起來。
如果你真的想擺脫窗口，正確的方法是記住什么是模式、它們來自哪里以及它們是如何工作的——然后弄清楚如何避免切換到其他模式（如果你想深入了解模式，請閱讀 Jef Raskin 的《人性化界面》）。例如：軟盤空間不足？不允許復制文件。軟盤未插入？不要將其顯示在目標列表中。現代操作系統就是這樣做的——它們消除了執行可能導致錯誤中斷的操作的可能性。
現在我們可以猜一下雅虎上的“繼續”按鈕的作用了：它啟動了一個錯誤調試模式。在該模式下，用戶被賦予了程序員的角色，并被迫修復所有導致程序崩潰的空值和未定義值。不幸的是，開發人員并沒有意識到這對普通用戶來說有多么糟糕。我希望他們至少明白，他們剝奪了用戶返回上一個模式的能力——這違反了良好用戶體驗的最基本規則。
乍一看，似乎所有網站的錯誤顯示都和雅虎一模一樣。所以這肯定是“最佳實踐”，是行業標準……但事實并非如此！每個人的做法都不一樣。我們來看看亞馬遜：
讓我們來分析一下。
一個活動按鈕——很好。亞馬遜正在跟上雅虎的步伐。
自動聚焦到第一個字段——太棒了（雅虎沒有這個功能）：用戶可以立即開始輸入。填完第一個字段后，按“繼續”鍵會直接將光標移動到第二個字段，也就是錯誤所在的地方。真是聰明的舉動！
有人會反對：自動對焦在桌面端運行良好，但在移動設備上鍵盤會遮擋半個屏幕，所以最好隱藏它，直到用戶點擊輸入。這樣一來，你解決了一個問題，又制造了另一個問題。然后你選擇你的毒藥……問題是，你會認為一種弊端較小，而有些用戶會認為另一種弊端更嚴重。無論哪種情況，你都在選擇一種弊端。不要這樣做（我稍后會解釋如何做）。
界面可逆性。你輸入一些內容，錯誤消失；然后你刪除它并切換到另一個字段——哇，一個沒有錯誤的空字段。所有字段都一樣。將界面恢復到初始狀態比雅虎要難，但由于算法不穩定，仍然是可能的。
與雅虎的同事一樣，亞馬遜的程序員在“繼續”按鈕和輸入字段之間建立了心靈感應：按鈕不想繼續，但輸入字段都大聲喊出來（突然變成輸出字段）。
特別要提一下密碼確認框——為什么它不變成紅色？不填就無法繼續。想說要等到前一個框填完后才進行校驗？當然，你得給用戶解釋一下錯誤校驗算法，再給他們看源代碼——這真的會很有幫助（諷刺）。
現在，我們來快速看一下IBM的解決方案：
激活按鈕——不錯。沒有自動對焦，但至少界面會自動滾動到第一個字段并顯示錯誤。
界面不可逆——無法將字段恢復到第一個屏幕上的樣子。換句話說，你無法退出調試模式。那么，為什么還要有第一個屏幕（調試模式）呢？如果你認為空字段是錯誤，那就直接顯示第二個屏幕吧。哦，你不想立刻嚇到用戶？還記得感知心理學嗎？你決定稍后再嚇唬他們，作為對他們錯誤的懲罰？讓我再重復一遍心理學家的話：
重要的是不要用消極情緒來強化錯誤，因為大腦對此非常敏感，并會將這種行為記錄為不值得花費精力的事情。
例子不勝枚舉。以網站 capital.xyz 為例：
日期字段為空，點擊“下一步”按鈕，字段自動對焦。手機字段為空，點擊“下一步”——完全沒有自動對焦。為什么？這背后的想法是什么？劇透：根本沒這回事。只是算法出了問題。
谷歌甚至更進一步——你輸入的每一個字符它都會責罵你……
即使你不同意我的批評，你也必須承認，知名公司的頂級設計師和程序員在實現同一項任務時，都采用了截然不同的方式。這意味著完美的解決方案尚未找到。很可能，根本沒人真正去尋找它。程序員只是在缺乏對用戶交互原則清晰理解的情況下編寫代碼，然后跑來找設計師說：“嘿，這里又有一個錯誤需要顯示出來。”
當我為自己的項目設計錯誤顯示時，我沒有依賴別人的解決方案——我依靠科學。我在撰寫本文時收集了來自雅虎、亞馬遜和 IBM 的示例。在對所設計機制背后的原理沒有深入理解之前，研究參考文獻是有害的。你只會撿起別人的錯誤，然后引用權威文獻來為自己辯護。幾乎每個人都這樣做。沒有人愿意重新發明輪子——工業程序員沒有時間或動力去做這件事。所以每個人都堅持使用老式的命令行、字母數字顯示方法。還記得當時錯誤是如何顯示的嗎？如果沒有，來看看控制臺：
如今，界面開發人員仍在做著同樣的事情：直接把錯誤日志直接倒在屏幕上。21世紀唯一的升級？把文本涂成紅色，然后把信息分散到屏幕的不同位置。
這可不行。我們趕緊解決吧！
我們用“錯誤”這個詞來描述兩種截然不同的事物：事件和狀態。快速回顧一下：當處理器嘗試執行無效操作時，它會觸發中斷并進入調試模式。這是一次性事件。我們說“發生了錯誤”。然后，我們去尋找導致崩潰的內存中的特定值。該值——或者更準確地說，存儲單元的狀態——也稱為“錯誤”。換句話說，我們模糊了因果之間的界限——僅僅是因為我們沒有想出單獨的詞。為了避免混淆，我將使用兩個術語：進程錯誤（事件，某個時間點）和數據錯誤（內存中的錯誤值，一種狀態）。
我們來看一個郵箱輸入框。缺少“@”符號？這是數據錯誤。被郵件服務器退回郵件？這是流程錯誤。或者以郵政編碼為例。位數太少？這是數據錯誤。數據庫中找不到郵政編碼？這是流程錯誤。
輸入字段只是一個數據容器。數據可能會缺失。如果你沒有輸入生日，并不意味著你出生在零日。這個輸入字段根本沒有數字，只有占位符“日”。數據缺失了。
因此，空白字段并非數據錯誤。不存在的東西本身就不是什么錯誤。空白字段是創建數據的機會，是一個良好的起點，也是一個互動的邀請。你可能已經注意到，空白表單看起來比已填充的表單更優雅。那么，為什么要用有毒的紅色來破壞它呢？誰會喜歡與標記為危險的字段互動呢？
不要這么做。我準備了一個交互式原型來向你展示應該怎么做。
讓我們看看電水壺中按鈕和水的狀態是如何變化的。打開電水壺。水沸騰后，按鈕會彈開。但觸發按鈕的不是水，而是溫度傳感器。如果傳感器損壞或丟失，按鈕就不會彈開。
現在手動按下按鈕——水不會突然變冷。了解導致狀態變化的具體原因很重要。
規則如下：如果對對象 A 執行了某個操作，那么只有 A 的狀態可以改變，而對象 B 的狀態則不能改變。要更改 B 的狀態，需要一個直接作用于 B 的獨立進程。
例如，數據庫搜索可能會觸發索引重建——這會更改數據庫本身，但不會改變您搜索的值。
讓我們來看一個常見的 UI 設計錯誤。用戶想通過郵政編碼查找城市。他們輸入郵政編碼，點擊“搜索”，然后……輸入框變紅，或者值消失了。發生了什么？這是一個流程錯誤——數據庫中沒有結果。但 UI 卻將其顯示為數據錯誤，就好像用戶輸入了錯誤的郵政編碼一樣。但也許郵政編碼是有效的——只是城市還沒有添加到數據庫中。也許五分鐘后就會添加。用戶并沒有輸入錯誤數據。輸入框不應該受到指責。我們無權觸碰它。流程錯誤需要以不同的方式顯示（稍后會詳細介紹）。
根據希克-海曼定律，提供的選項越少，用戶選擇所需內容的速度就越快。將這一原理推向極致，便可得出“一屏一操作”原則。有人可能會說，復雜的程序不可能簡化到這種程度，但讓我們回想一下 Hanx Writer 文本編輯器——蘋果設計獎得主——它幾乎精簡了所有內容。或者想想在 Photoshop 中按下一個按鈕就可以隱藏整個界面，只留下一個工具可見。在某些情況下，“一屏一操作”原則非常有效。至少，在放棄它之前，先嘗試一下。
在優化了開立經紀賬戶的網頁工作流程后，我決定在移動應用中測試這種方法。看看我的交互式原型吧——它通過了 17 位用戶的快速測試，與舊版本（每個屏幕有多個輸入字段）相比，速度提升了 13%。
有人可能會說，時間的提升并不大——少了52秒，而不是整整一分鐘。但首先，試著數到8——這實際上是一段相當長的時間內，任何事情都可能發生。其次，測試表明時間減少了，而不是像一些人擔心的那樣增加了。他們假設額外的屏幕轉換會減慢用戶的速度，但結果卻恰恰相反：信息越少，用戶處理速度就越快。當只有一個操作可選時，用戶會毫不猶豫地執行。
原型就是這樣。屏幕上只有一個輸入字段。用戶輸入數據，按下“繼續”，屏幕就會滾動到下一步。如果你手動嘗試在空白字段處向前滾動，屏幕會迅速彈回：“不行，不行”。輸入字段保持焦點，提示用戶輸入數據。無需任何額外的高亮——畢竟，它是屏幕上唯一的字段。完美。
如果你點擊“繼續”，但輸入框為空或郵箱地址缺少“@”符號，鍵盤會彈回來，仿佛在說：“想繼續嗎？那就繼續填寫吧。” 沒有任何錯誤信息！
我再強調一遍：我們不會隱藏錯誤信息。相反，我們設計的系統絕對不會出錯。沒有數據就意味著沒有數據錯誤。沒有流程就意味著沒有中斷或調試模式。這里唯一的期望是數據以正確的格式輸入。順便說一句，這里有一個很棒的方法——接受任何合理格式的數據。例如，Sberbank.ru 允許您輸入帶有國家代碼 (+7)、本地前綴 (8) 或完全不帶區號的電話號碼。
從本文俄語版的評論來看，并非所有人都理解原型的用途。有些人期望看到一個完美無瑕、隨時可用的產品（一個他們可以直接復制的產品），結果卻大失所望，對諸如缺少重新發送短信驗證碼的選項之類的問題吹毛求疵。讓我再次澄清：本文中的原型并非成品的精確復制品。它們的唯一目的是展示如何消除錯誤信息。
現在，讓我們將此解決方案擴展到界面無法簡化為“一屏一操作”模式的情況。 “Ingos Investments”的原型反映了數據量巨大，以至于每個屏幕上必須顯示多個字段的情況。
讓我們設想一個場景：用戶尚未填寫所有字段，點擊了“繼續”按鈕。界面立即聚焦于第一個空白字段，調出屏幕鍵盤，并滾動到該字段正上方，方便用戶查看正在輸入的內容。即使屏幕上有多個字段，我們仍然堅持“一次一個操作”的原則，巧妙地將其他字段隱藏在鍵盤下方。在活動字段下方，會出現一條提示：“所有字段必須填寫”。這不是錯誤消息，而是一個有用的提示，沒有任何令人擔憂的危險信號。
當用戶點擊屏幕鍵盤上的“下一步”時，他們只會跳轉到下一個字段——這和填寫表單的常規流程一樣，而不是笨重的錯誤調試模式。提示已經給出，所以用戶不太可能再次嘗試填寫空白字段。但如果他們真的這么做了，那么他們會再次看到這個溫馨提示。
懷疑論者可能會說：“但如果空白字段位于屏幕最頂部，無法滾動到鍵盤上方怎么辦？或者，如果網站是在桌面上打開的，根本沒有屏幕鍵盤怎么辦？” 答案是：沒什么大不了的。所有這些極端情況都在原型中得到了完美的體現。我也聽到過這樣的擔憂：“如果我們不把每個字段都涂成紅色，用戶就不會意識到需要填寫”。測試表明，這些擔憂是毫無根據的。這些擔憂背后真正的恐懼，是害怕打破常規，嘗試一些真正新穎的東西——一些對用戶更有利，而不僅僅是對我們自己更有利的東西。
為了創建“Ingos Investments”的原型，我編寫了一個狀態管理調度器。交互元素將其內容報告給管理器，然后管理器決定如何處理它們。
程序員常說輸入字段是獨立的元素。郵箱字段不知道電話字段里的內容。當你切換輸入字段時，它會觸發對其內容的驗證。當你點擊“繼續”按鈕時，所有輸入字段都會收到一個命令——檢查你的數據。這就是為什么它們會突然一起亮起紅燈。這就是它的構造方式。程序員說你無法改變它。設計師也相信這一點。不過亞馬遜的例子表明，密碼確認字段確實知道前一個字段的內容。所以他們可以隨時修改。
這意味著你可以而且應該創建一個狀態管理器。當用戶嘗試跳轉到下一個屏幕時，狀態管理器會檢查所有字段，找到第一個包含不完整或無效數據的字段，將用戶帶回該輸入框并顯示提示。本質上，這是一次時光之旅——回到用戶出錯的點。因此，將后續字段標記為錯誤是沒有意義的——它們發生在將來，而用戶尚未到達它們。
使用狀態管理器，您還可以在鼠標懸停在“繼續”按鈕上時檢查字段內容。如果數據缺失，按鈕的標簽會更改為特定的字段名稱，例如“輸入街道”——這遵循了時效性原則（用戶嘗試繼續，但需要填寫字段，我們會通知他們）。這個新標簽在按鈕和字段之間建立了視覺聯系，使程序員有理由將這兩個元素的行為聯系在一起。
程序員可能會問：“為什么要把事情復雜化？” 沒錯——對程序員來說越復雜，對用戶來說就越容易。這是規則。說實話，這只需要一兩天的時間。需要更多精力的是通知系統。數據錯誤和流程錯誤應該顯示在各自的層級結構中：數據錯誤應該顯示在數據容器中，而流程錯誤應該顯示在應用程序范圍的通知中。這是一個完全獨立的主題，我希望有時間寫一篇關于通知設計的文章。
因此，我們發現了以下事實：