簡介：「錯誤提示」是表單出現輸入錯誤時，為使用者展示的一條引人注目的解釋性消息，該消息可能描述使用者如何修複錯誤。
顯示錯誤提示的目的是幫助使用者修複他們在輸入時遇到的問題，讓使用者盡可能快速，輕松地完成任務。
以下是兩種常見的錯誤提示方法：
第一種是通過模态對話框向使用者報告錯誤資訊。這些資訊可能會很有幫助，但是使用者在修複錯誤之前需要先單擊關閉該模态對話框，且關閉後使用者就再也看不到錯誤資訊了。
第二種是在使用者送出後載入新頁面以顯示錯誤消息。同樣，使用者在再次輸入時，需要後退到曆史頁面更改，且記憶成本很高，需要記住所有錯誤内容，這不但耗費精力，而且容易出錯。
是以，Web 表單的填寫應該把錯誤提示放在引發錯誤的元件旁邊，并且即時回報。這樣一來，使用者一眼就可以看出是哪裡出錯，并可以根據提示資訊直接修複。
在填寫表單時，使用者進行了不合法的資訊輸入。例如，使用者跳過一些必填字段，或者輸入了不合格的數字、無效的電子郵件位址等。錯誤提示的目的是鼓勵使用者再次嘗試資訊輸入，幫助指出資訊輸入有誤的地方。這個模式的使用條件是：
使用者進行了不合法的資訊輸入；
糾正和引導使用者的輸入内容；
常用的解決辦法是标記出引發錯誤的表單，即在表單上面或者下面用顔色高亮（常用紅色/黃色）說明錯誤資訊，注意不要等使用者送出後才顯示錯誤，可以在使用者完成目前項便給予回報。
注意，設計表單的時候要防止一些特定的錯誤發生，例如：
當選項有限且不便輸入的情況下，使用下拉選擇 ，不用輸入文本框；
提供 輸入說明 、 輸入提示 、 自動完成、良好預設 來支援文本輸入；
盡可能限制表單字段的總數；
使用一個清晰的提示邏輯标記出選填和必填内容；
關于如何書寫錯誤提示，實際上超出了這個模式的範疇，但是可以給讀者一些快速的指引:
提示資訊保持簡短但清晰，以便能解釋哪個地方出錯，以及錯誤的原因是什麼。
正面案例： “沒有提供位址”
反面案例： “資訊不足”
使用日常用語，而不要用計算機語言。
正面案例 ：“郵政編碼裡包含一個字母”
反面案例 ：“數字驗證錯誤”
保持禮貌。
正面案例： “對不起，出現了一個錯誤！請再次單擊‘Go’”
反面案例 ：“JavaScript 693号錯誤”
反面案例： “這個表單沒有包含資料”
使用者需求：重置密碼
使用者重置系統密碼時，輸入新密碼提供實時的嚴格校驗标準，能讓使用者知道已經輸入的資訊是否滿足要求；并且當使用者輸入确認密碼時，若是出現錯誤，兩個表單都會報錯，并提示使用者報錯原因是：“兩次密碼輸入不一緻”。
案例二：Teambition 編輯字段的錯誤提示
使用者需求：用 Teambition 編輯一個自定義的字段
當使用者錄入了一個字段資訊“緊急程度”，但是該字段的合格格式是不能與其他人的錄入字段重合，Teambition 會在表單上方顯示錯誤資訊，并提示字段被誰鎖定，以幫助使用者明白原因，糾正輸入錯誤。
案例三：Webstorm 源代碼編輯器的錯誤提示
使用者需求：用源代碼編輯器輸入代碼資訊
Webstorm 源代碼編輯器對輸入資訊的合适有非常嚴格的要求，當使用者輸入錯誤的格式，便會在錯誤的内容下用紅色波浪線辨別，同時旁邊出現一個可互動的小燈泡，使用者點選燈泡，系統可以提供一些修正政策，幫助使用者繼續目前任務。
你可以在下方檢視「清單建構器」更多的案例：
https://airtable.com/shr5WlzknRZiGDeso/tblXEEC6HykKOL3Ef