Error messages should clearly describe the issue to the user. Be as specific possible. Explain what happened and why it happened (if known).
Provide a solution with specific guidance for how to fix the error, including any steps the user should take. If no solution is known, direct the user to other resources, such as the support team or the help center.
There was an error generating the report. [Submit issue].
There was an error loading the page. Please try again. If the problem persists, [contact support].
There was an error generating the report. Please navigate to the support page and click the submit issue link.
There was an error loading the page.
If the problem persists, navigate to the support page and click the contact support link.
Keep the message short and to the point. Use simple and easy-to-understand language.
Say “can” and “do” instead of “can’t” and “don’t”. It gives users confidence. Be polite and respectful: use a friendly tone and don’t blame the user for the error.
Avoid being too cheerful as it can come off as insincere. Never say “Oops!” or “Whoops!”.
There was a problem. Check the format and try again.
There was a problem. You most likely used the wrong format
Even though we want to be polite, use “please” sparingly. Only say “please” if the error is due to an issue with the product, or if the suggested action is inconvenient for the user.
The error message should be written for humans, not robots. Write a message that a layperson could understand. Don’t include error codes.
Error messages should be consistent. Use the same language, formatting, and placement across the platform.
Use inline validation as much as possible, meaning that if there is an error in a field, text explaining the error should be displayed beneath the field.
For situations where there is limited space, use a tooltip. This should be a last resort. Tooltips are not as accessible as visible text, and users may not realize that the alert icon includes a tooltip and may not see the message. It also adds extra effort to access the information.
Required field left blank
When the error is due to the user leaving a mandatory field blank, enter a short, simple message like:
Enter the email address
Select the start date
Budget is required
Invalid format
If the error is due to the user entering a value that we don’t accept for that field, be as specific as possible in describing the error. For example:
Email address: basisblaze#basis.com
Error message option 1: Email addresses must include the @ symbol
Error message option 2: Invalid format. Email addresses must use the format: name@example.com
Start date: 4/22/2025
Error message option 1: Date format must be DD/MM/YY
ZIP Code: 123456789
Error message option 1: Invalid ZIP code format. ZIP codes must be 12345 or 12345-6789