當(dāng)我們在進行網(wǎng)站設(shè)計時很少考慮錯誤消息頁面的體現(xiàn)，錯誤消息需要易于發(fā)現(xiàn)，但它們也需要有幫助。讓我們探討一下錯誤消息何時應(yīng)該出現(xiàn)在輸入字段之上，以及為什么忽略錯誤消息通常不是一個好主意。

事實證明，對這些信息進行戰(zhàn)略性和徹底的設(shè)計對于企業(yè)來說至關(guān)重要，尤其是在他們面臨高放棄率的情況下。錯誤消息可能會在事情惡化的情況下成就或破壞體驗。錯誤無處不在，錯誤消息也是如此。它們當(dāng)然在 Web 表單中很常見，但在復(fù)雜的表格、不兼容的過濾器、搜索查詢和失敗的交互中也很常見。它們可以是小的錯誤說明和大的錯誤摘要。

并非所有錯誤都是相同的，實際上存在兩種不同類型的錯誤。當(dāng)用戶打算執(zhí)行一項操作但又執(zhí)行另一項操作時（例如，在自動駕駛儀上填寫表格時），就會出現(xiàn)失誤。當(dāng)用戶的心智模型與系統(tǒng)不匹配時，就會發(fā)生錯誤。我們的界面需要支持這兩種類型的錯誤，而且失誤通常比錯誤更容易解決。

為了防止錯誤，我們需要確認破壞性行為（當(dāng)用戶返回上一頁時），盡早設(shè)定期望（密碼要求或文件大?。?，允許用戶改變主意（更改電子郵件或付款方式），一般來說，總是提供出路。為了衡量我們的錯誤消息是否成功，我們可以定義以錯誤為中心的設(shè)計 KPI并隨著時間的推移對其進行跟蹤。這些可能包括：用戶旅程中的平均錯誤數(shù)，錯誤恢復(fù)時間，完成率以及完成時間。我們不能真正完全消除錯誤，因為沒有人為輸入是萬無一失的，但我們可以通過讓出錯變得更加困難來減少錯誤的數(shù)量。這樣做的一種簡單方法是改進發(fā)現(xiàn)錯誤，不要只依賴錯誤消息的顏色。


最重要的是，錯誤摘要可能不應(yīng)該出現(xiàn)在操作按鈕下。很多時候，尤其是在移動設(shè)備上，用戶根本沒有意識到有任何錯誤消息，并且一直點擊那個糟糕的提交按鈕，希望得到任何形式的反饋——無論是來自瀏覽器的狀態(tài)更新，還是更改網(wǎng)址。反饋實際上就在按鈕下方，但在測試中，它通常顯示出很差的發(fā)現(xiàn)率。如果頁面在驗證后完全刷新，則錯誤摘要應(yīng)位于頁面的最頂部。但是，如果頁面在沒有刷新的情況下更新，則在用戶剛剛單擊或點擊的操作按鈕上方添加錯誤摘要是合理的 - 并用紅色和圖標突出顯示它。

一旦用戶點擊提交按鈕，我們是否應(yīng)該自動滾動到第一個錯誤？這個問題沒有明確的答案。就個人而言，我看到這種模式對某些用戶來說效果很好，但對另一些用戶來說卻慘遭失敗。頁面上的任何突然移動都可能導(dǎo)致至少一些用戶感到沮喪。如果有的話，用戶往往會發(fā)現(xiàn)自動跳轉(zhuǎn)比自動滾動更煩人——因為后者至少傳達了變化的方向并更好地提示用戶移動到了哪里。簡短的回答？開始時不自動滾動，僅顯示帶有鏈接的錯誤摘要。如果速度太慢或無法按預(yù)期工作，請考慮添加自動滾動。絕不會無緣無故地在頁面上上下移動用戶——這是一種增加完成時間并在可能不需要時引入混亂的安全方法。