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