|
| 1 | +# Error and Warning Message Guidelines |
| 2 | + |
| 3 | +These guidelines ensure that messages are user-friendly, clear, and helpful while maintaining a professional tone. 🚀 |
| 4 | + |
| 5 | +Some details: |
| 6 | + |
| 7 | +- Originated from [guidelines](https://wiki.speag.com/projects/SuperMash/wiki/Concepts/GUI) by @eofli and refined iterating with AI |
| 8 | +- Here’s the fully expanded and rewritten list of **error and warning message guidelines**, each with: |
| 9 | + - A **guideline** |
| 10 | + - A **rationale** |
| 11 | + - A ❌ **bad example** |
| 12 | + - A ✅ **good example** |
| 13 | + - A **reference** |
| 14 | +- This list is intended to be short enough to be read and understood for humans as well as complete so that it can be used as context for automatic correction of error/warning messages |
| 15 | + |
| 16 | +--- |
| 17 | + |
| 18 | +## 1. Be Clear and Concise |
| 19 | + |
| 20 | +- **Guideline:** Use straightforward language to describe the issue without unnecessary words. |
| 21 | +- **Rationale:** Users can quickly understand the problem and take corrective action when messages are simple and to the point. |
| 22 | +- ❌ **Bad Example:** |
| 23 | + `"An error has occurred due to an unexpected input that couldn't be parsed correctly."` |
| 24 | +- ✅ **Good Example:** |
| 25 | + `"We couldn't process your request. Please check your input and try again."` |
| 26 | +- **[Reference](https://uxwritinghub.com/error-message-examples/)** |
| 27 | + |
| 28 | +--- |
| 29 | + |
| 30 | +## 2. Provide Specific and Actionable Information |
| 31 | + |
| 32 | +- **Guideline:** Clearly state what went wrong and how the user can fix it. |
| 33 | +- **Rationale:** Specific guidance helps users resolve issues efficiently, reducing frustration. |
| 34 | +- ❌ **Bad Example:** |
| 35 | + `"Something went wrong."` |
| 36 | +- ✅ **Good Example:** |
| 37 | + `"Your session has expired. Please log in again to continue."` |
| 38 | +- **[Reference](https://www.nngroup.com/articles/error-message-guidelines/)** |
| 39 | + |
| 40 | +--- |
| 41 | + |
| 42 | +## 3. Avoid Technical Jargon |
| 43 | + |
| 44 | +- **Guideline:** Use plain language instead of technical terms or codes. |
| 45 | +- **Rationale:** Non-technical users may not understand complex terminology, hindering their ability to resolve the issue. |
| 46 | +- ❌ **Bad Example:** |
| 47 | + `"Error 429: Too many requests per second."` |
| 48 | +- ✅ **Good Example:** |
| 49 | + `"You’ve made too many requests. Please wait a moment and try again."` |
| 50 | +- **[Reference](https://cxl.com/blog/error-messages/)** |
| 51 | + |
| 52 | +--- |
| 53 | + |
| 54 | +## 4. Use a Polite and Non-Blaming Tone |
| 55 | + |
| 56 | +- **Guideline:** Frame messages in a way that doesn't place blame on the user. |
| 57 | +- **Rationale:** A respectful tone maintains a positive user experience and encourages users to continue using the application. |
| 58 | +- ❌ **Bad Example:** |
| 59 | + `"You entered the wrong password."` |
| 60 | +- ✅ **Good Example:** |
| 61 | + `"The password doesn't match. Please try again."` |
| 62 | +- **[Reference](https://atlassian.design/content/writing-guidelines/writing-error-messages/)** |
| 63 | + |
| 64 | +--- |
| 65 | + |
| 66 | +## 5. Avoid Negative Words and Phrases |
| 67 | + |
| 68 | +- **Guideline:** Steer clear of words like "error," "failed," "invalid," or "illegal." |
| 69 | +- **Rationale:** Positive language reduces user anxiety and creates a more supportive experience. |
| 70 | +- ❌ **Bad Example:** |
| 71 | + `"Invalid email address."` |
| 72 | +- ✅ **Good Example:** |
| 73 | + `"The email address format doesn't look correct. Please check and try again."` |
| 74 | +- **[Reference](https://atlassian.design/content/writing-guidelines/writing-error-messages/)** |
| 75 | + |
| 76 | +--- |
| 77 | + |
| 78 | +## 6. Place Messages Appropriately |
| 79 | + |
| 80 | +- **Guideline:** Display error messages near the relevant input field or in a clear, noticeable location. |
| 81 | +- **Rationale:** Proper placement ensures users notice the message and understand where the issue occurred. |
| 82 | +- ❌ **Bad Example:** |
| 83 | + Showing a generic "Form submission failed" message at the top of the page. |
| 84 | +- ✅ **Good Example:** |
| 85 | + Placing "Please enter a valid phone number" directly below the phone input field. |
| 86 | +- **[Reference](https://www.smashingmagazine.com/2022/08/error-messages-ux-design/)** |
| 87 | + |
| 88 | +--- |
| 89 | + |
| 90 | +## 7. Use Inline Validation When Possible |
| 91 | + |
| 92 | +- **Guideline:** Provide real-time feedback as users interact with input fields. |
| 93 | +- **Rationale:** Inline validation allows users to correct errors immediately, enhancing the flow and efficiency of the interaction. |
| 94 | +- ❌ **Bad Example:** |
| 95 | + Waiting until form submission to show all validation errors. |
| 96 | +- ✅ **Good Example:** |
| 97 | + Displaying "Password must be at least 8 characters" while the user types. |
| 98 | +- **[Reference](https://cxl.com/blog/error-messages/)** |
| 99 | + |
| 100 | +--- |
| 101 | + |
| 102 | +## 8. Avoid Using All-Caps and Excessive Punctuation |
| 103 | + |
| 104 | +- **Guideline:** Refrain from writing messages in all capital letters or using multiple exclamation marks. |
| 105 | +- **Rationale:** All-caps and excessive punctuation can be perceived as shouting, which may frustrate users. |
| 106 | +- ❌ **Bad Example:** |
| 107 | + `"INVALID INPUT!!!"` |
| 108 | +- ✅ **Good Example:** |
| 109 | + `"This input doesn't look correct. Please check and try again."` |
| 110 | +- **[Reference](https://uxwritinghub.com/error-message-examples/)** |
| 111 | + |
| 112 | +--- |
| 113 | + |
| 114 | +## 9. Use Humor Sparingly |
| 115 | + |
| 116 | +- **Guideline:** Incorporate light-hearted language only when appropriate and aligned with the application's tone. |
| 117 | +- **Rationale:** While humor can ease tension, it may not be suitable for all users or situations and can sometimes be misinterpreted. |
| 118 | +- ❌ **Bad Example:** |
| 119 | + `"Oopsie daisy! You broke something!"` |
| 120 | +- ✅ **Good Example:** |
| 121 | + `"Something went wrong. Try again, or contact support if the issue continues."` |
| 122 | +- **[Reference](https://cxl.com/blog/error-messages/)** |
| 123 | + |
| 124 | +--- |
| 125 | + |
| 126 | +## 10. Offer Alternative Solutions or Support |
| 127 | + |
| 128 | +- **Guideline:** If the user cannot resolve the issue independently, provide a way to contact support or access help resources. |
| 129 | +- **Rationale:** Offering support options ensures users don't feel stranded and can seek help to resolve their issues. |
| 130 | +- ❌ **Bad Example:** |
| 131 | + `"Access denied."` |
| 132 | +- ✅ **Good Example:** |
| 133 | + `"You don't have permission to view this page. Contact support if you think this is a mistake."` |
| 134 | +- **[Reference](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-error-handling-guidelines/)** |
0 commit comments