錯誤訊息從來都不是件有趣的事。然而，寫得不好的錯誤訊息可能會嚴重干擾您的使用者，甚至損害您的品牌形象。在 Sketch，我們決心透過一些規劃、團隊合作，當然還有一些巧妙的使用者體驗文案，來擺脫糟糕的錯誤訊息！
為什麼錯誤訊息很重要
錯誤訊息對使用者的影響比大多數其他類型的文案都要大，因為
- 您會獲得使用者全神貫注的注意力，這種情況在最佳情況下都很少發生，因此您需要在糟糕的情況下充分利用它。
- 您會在使用者工作時打斷他們，如果問題不容易解決並成為阻礙，這可能會特別令人沮喪。
- 使用者希望您在錯誤訊息中說明故障點，無論是誰的錯（軟體、使用者或第三方）。
從更廣泛的層面來看，錯誤訊息可以很好地反映網站或應用程式的整體完善程度。只需一條寫得不好的錯誤訊息，就會毀掉使用者的體驗，而這是他們不會輕易忘記的。
發送錯誤的訊息和混淆的信號
現在，讓我們看幾個糟糕的錯誤訊息示例，以及我們如何改進它們。
問題與解決方案
我們將從一個您可能見過的常見內嵌錯誤開始
撰寫第一條錯誤訊息的人將其描述為一個問題陳述，而且是以抽象的方式。這將責任歸咎於使用者，而且沒有什麼幫助。相反，可以直接要求使用者按照您的要求去做，這在第二個示例中很清楚。
當您的空間有限時，請直接進入解決方案，而不是拐彎抹角地解釋問題。專注於引導使用者，而不是羞辱他們。
讓您的錯誤訊息清晰易懂
接下來，這是一個來自舊作業系統的錯誤訊息
第一個訊息示例幾乎把所有事情都做錯了。它既正式又晦澀難懂，雖然假裝成非法駭客可能很酷，但我們真正想告訴使用者的是什麼？相反，我們可以使用第二個示例。
換句話說：您正在使用的應用程式壞了，請嘗試將其關閉再打開。如果這樣做沒有用，請與供應商聯繫（或選擇「檢視詳細資訊」）。
瞭解您的受眾
以下是另一個示例，取自照片編輯軟體
看看第一條錯誤訊息，這可能是開發人員為其他開發人員寫的。然而，大多數終端使用者對列舉的突變不感興趣。就連「確定」按鈕似乎也屈服於實際發生的事情的謎團。
可悲的事實是，有時沒有人真正知道為什麼會出錯。是單一故障，還是我們無法解決的多重叢集災難？是使用者造成的錯誤，還是討厭的錯誤造成的罕見後端問題？
如果您沒有答案，通常最好使用第二條錯誤訊息之類的通用訊息。
當然，這不是一個令人滿意的結局，但這是一個使用者理解並可以採取行動的結局。
不友善的錯誤訊息會讓人反感
最後一個示例，這次來自線上零售商
雖然第一條錯誤訊息近乎敵意的語氣確實讓我們感到好笑（「我們警告你！這個密碼是絕對不能接受的！」），但在現實生活中遇到這個錯誤的使用者可能不會覺得它很有趣。
我們建議你參考第二個例子，它採取了更友善的方式。
輸入錯誤的密碼是每個人都會犯的小錯誤，而且通常很容易解決。請以平常心看待這件事。請使用友善的語氣，不要責怪任何人，也不要過度解釋他們錯在哪裡。
糟糕的提示訊息也是錯誤
糟糕的錯誤訊息無所不在，我們甚至承認，我們在 Sketch 中還有一些需要修正的地方。但我們決心要消滅它們，因為糟糕的錯誤訊息也是錯誤，我們需要修正它們。
展現你的專業
消除錯誤的第一步是學習如何辨識它們。如果你是一位寫作者，請花時間向你的團隊展示糟糕的錯誤是什麼樣子的，尤其是開發人員。建立一些範本和範例來幫助其他人區分糟糕和良好的錯誤訊息。
別忘了品管團隊！只要稍加培訓，你的品管分析師就能成為強大的盟友，在錯誤邊緣案例無意間釋出到產品環境之前就將其捕獲。
分享愛
由於糟糕的錯誤訊息也是錯誤，這表示團隊中的每個人都可以幫助尋找和修正它們。例如，使用者體驗設計師應該在設計和測試期間記錄預期的錯誤情境（或者，最好在錯誤發生之前就先設計好解決方案）。
糟糕的錯誤訊息也是錯誤，我們需要修正它們。
同時，開發人員應分享可能出現在前端或後端的已知錯誤情境。對於特別難以理解的錯誤，開發人員和寫作者應共同建立錯誤訊息。開發人員永遠不應該自己寫錯誤訊息。
建立單一事實來源
如果你還沒有，你需要一個錯誤檔案庫，一個單一的事實來源，用來儲存你的文案生態系統隨著時間累積的所有錯誤訊息。
如果你夠幸運，你會有一個整合的內容管理系統 (CMS)，可以神奇地提取和顯示你的錯誤字串。如果沒有，只需將你的錯誤記錄在可共用的試算表或文件中即可。將它們放在哪裡並不重要，只要將它們儲存在_某個地方_，以避免在以後遇到類似（甚至相同）的錯誤情境時重複工作。
錯誤檔案庫當然應該包含字串本身。但它也應該包含有用的中繼資料，例如唯一的 ID（以便於追蹤）、描述、類別標籤，以及相關設計文件或 GitHub 議題的連結。
修正錯誤需要團隊合作
糟糕的錯誤訊息是生活中無法避免的事實，但它們不應該成為痛苦的體驗，無論對你還是你的使用者來說都是如此。無論你是在撰寫新的訊息還是在修正舊的訊息，請記住，你是在修正錯誤，這些錯誤將改善你的產品。這一切努力都是值得的。
祝你抓蟲愉快！
