Errors can be scary and confusing. By using some of these best practices, designers can help the user understand the error and how to fix it. If an error must be shown, the user should be able to immediately understand what mistakes they've made or which system errors have been triggered; and they should get clear guidance on how to resolve the issues.
Overall, the user needs to be guided towards the smoothest journey possible. Errors should be helpful, and never blame the user. Use the following guidelines to find the most appropriate error format and messaging to help the user understand and/or correct the issue.
Consider when errors should be displayed based on the situation, the user, and the current task. Should errors appear when the field loses focus (on blur)? Or only upon submitting information, such as clicking on a "Continue" button?
If the page does reload, consider having an errors summary, including a count of errors, appear at the top of the page; screen readers can then read the error messages sooner on the page. Include anchor links to the specific errors on the page in the summary.
If the page does not reload, then consider bringing the focus to the form field with the first error message and having the screen reader announce the error.
Help the user prevent errors by providing clear field labels and instructions.
- Communicate what has caused the error.
- Describe how the user can fix the error.
- Display the error message at the right time and place.
- Avoid technical jargon. Make sure to use simple words so that the user understands the message’s content.
- Don’t rely just on color. Use supporting text and the error icon.
Tips for Writing Error Messages
- Error messages should address the user, tell them what happened and instruct them on how to fix it. Example: “There’s already a file with that name. Please try another name.”
- Always provide a solution for the user when an error occurs. There might be more than one solution to the error, so keep in mind the use case and what makes the most sense for the user when crafting the error message.
- Speak the same language as the user and avoid technical jargon. Example: Don’t say, “Exception EWiz 545765345 Error code 61”
- Be concise with the error message.
- If there is a lot more information to be provided on how to fix the error, provide it in a progressive disclosure. A progressive disclosure is where you hide the remainder error information under a “show more” or “read more” link so that the user can provide more information to support or how to cure the error on their own.
- Prevent accusatory language so that the user doesn’t feel like they are taking the blame. Example: Don’t say, “You didn’t enter your name.” Instead, say “Please enter your name.”
- No one likes being yelled at, so be gentle. Avoid using all caps with an exclamation point, and be gentle in your language.
- Users prefer getting help from a human, so be friendly and avoid sounding like a robot.
- Avoid directional language, such as “see above.” Content can be scaled and moved around based on screen size so it might not always be accurate.
Displaying errors after page refresh
The following guidelines are for the scenario when the user has submitted form fields and the page refreshes.
Use the page title,
<title>element of the web page, to indicate errors and number of errors. The screen reader would read this immediately when the page is loaded. Example of page title: “3 Errors - User Information”
This method can also be used to indicate successes. Example of success scenario for page title: “Thank you for submitting your report”
- Use the main heading, such as
<h2>of the web page, to indicate errors and number of errors. The original text of the main heading should still be included. Example of main heading: “3 Errors - User Information”
- Include an errors summary at the top of the page. The errors summary contains a clear heading and includes a count of the errors. Example: “3 Errors in this form”
- Display specific, in-line error messages that are physically close to the relevant form fields.
Validations should be in-line so that as soon as the user has finished completing a field, an indicator appears nearby if the field contains an error. Minimize form text to the essentials. Not every text field needs helper and/or error text.
You need to check the validity of an input and provide feedback before submission.
What to use:
Text Field, Required Fields, Banners (if applicable)
- Avoid using the word “invalid” to define an error. When appropriate, use “not valid” instead.
- Highlight all areas that need to be fixed with clear messaging on why the error occurred.
Validations Best Practices
- Display the error message after the user has interacted with the input.
- Highlight the input red and display a clear message below indicating why the error appeared.
- Display an error for each input if there are multiple. For forms, also add an error summary message when the user tries to submit.
- Place instructions for filling out the form above the field.
- Be polite in language and clearly inform the user how to fix the error.
- Don’t display the error message before the user has moved away from the input.
- Don’t rely just on color. Use supporting text and the error icon.
- Don’t disable the primary action button. Use supporting messaging to indicate why the form cannot be submitted.
- Avoid directional language such as “the button on the right.”
Empty required form fields should be indicated by both the text field and error message below. Using an asterisk (*) along with instructions that certain fields are required, can help alleviate the amount of incomplete form errors.
Display incomplete form errors to indicate a user has skipped a field after they have advanced through a form. If unable to detect user progress through the form, display an error after the user has attempted to submit the form.
Multiple errors before form submission:
Display error messages next to each field as the user works through the form. Each form field should still keep the same rules and error structure. Additionally, add an in-line error banner to explain to the user that there are multiple errors that need to be addressed.
Enable the submit button at all times; even when the form is blank. Especially in longer forms, the user may not be aware of what to do in order to be able to submit the form. Once the user clicks the button, show the error summary indicating why the form can’t be submitted (missing required fields or fields that aren't in a valid format).
Reload the form with consolidated error messages and scrollto the top. Error messages for individual fields may be resolved as the user works through the form.
- Form Field Label: The form field label is important because it tells the user what content goes in the form field itself. Make sure this is clear and concise.
- Error Icon: Place the error icon after the form field label. This gives the user a visual so that they don’t have to rely just on color.
- Form Field: Change the color of the input border to red so that the user doesn’t have to just rely on the error help text.
- Error Help Text: Tell the user how to fix the error in the form field. Be specific, concise, and use the same language as the form field label.
When an element in the user interface is disabled, it’s an indicator that something is wrong. Disabled buttons do not explain what's wrong to the user, cause confusion, and possibly lead to abandonment of the application workflow. Additionally, disabled buttons hide the call to action within the workflow.
Disabled buttons are not focusable for keyboard interactions, making them inaccessible. They also usually have insufficient contrast, which contributes to inaccessibility.
Whenever dealing with disabled buttons, ask yourself if there is a better way to communicate the options that the user has. Think about the ways to connect with the users despite the errors — with a default selection, tooltips and hints, as well as actionable calls to action. Use disabled buttons sparingly and with purpose (but really, try not to use them at all!).
Don’t use if at all possible. Think of a different solution that does not involve disabling a button.
What to use:
- If a button needs to be disabled, place the error message in context to where the error has occurred, explaining why the button is disabled.
- Tell the user within the field instead of disabling the call to action.
Disabled Buttons Best Practices
- Allow the user to select submit buttons, even if content is missing or incorrect and prompt the error messages. This is a clear way to communicate the issues to the user.
- Disabled buttons must be focusable and be paired with a message explaining why the button is disabled.
- Don’t hide the error message behind a tooltip.
- Don’t use disabled buttons if the form is still empty.
Banner errors are used to show the visibility of the system status. They should be clear and inform the user of an important change or condition with optional actions or links.
Additionally, they can be used to alert the user if there are more than 2 errors on a page. These can be considered in-line and not global. The benefit of this type of banner is to provide the user with a global call-to-action to fix the errors on the page.
A user needs to be alerted about a condition of the system globally or more than 2 errors on a page.
What to use:
Does not exist yet.
- If alerting the user of more than 2 errors on a page, list the number of errors that there are to correct.
- Provide a call-to-action link if available.
Banner Best Practices
- Keep above the page content.
- Use only for application wide critical messaging or page level critical messaging.
- Don’t make the banner color red. This is jarring and scary to the user.
- Don’t use more than one banner at a time. Consider listing the errors within the banner instead of using multiple banners.
Global System Error Banners
Display global system error banners when there is a problem system-wide that would halt the user from completing the actions in their workflow. These messages can include links to contact customer service or read a help article. Typically these errors cannot be cured on the user’s side, and the solution should be helpful and concise. Error banners should not be dismissable as they impact the system.
In-line Error Banners
Place these banners across the content specific area that you want to guide the user towards. These can be dismissable and include a call-to-action to help the user cure the error. You might consider using these banners if there are more than 2 errors in a section and the user can fix them on their own.
Dialogs are a good way to confirm a destructive action, but not to tell them an error has occurred. Dialogs block the user until a decision has been made, which can lead to extra pressure or stress on the user.
Dialogs bring content to a higher z-layer above the current page, while allowing the user to maintain the context of a particular task. Use Dialogs to alert users to errors sparingly because they may interrupt user workflow. Think of other ways to display an error before going with a dialog.
You need to alert a user to confirm a destructive action.
What to use:
Dialog with secondary button and delete button
Dialog Best Practices
- Only use when the user needs to confirm a destructive action.
- Consider the use case for the type of language to use in the buttons.
- Don’t use as an error message because it blocks access to the rest of the application, which also blocks the user from fixing the error.
- Title: The title should bring attention to the action that the user is about to commit to. Position the title statement to be in the form of a question so the user can make the decision to confirm or deny. These should be sentence-case.
- Close dialog button: The user should have an option to close the dialog if they went to it by accident. The same action would occur if they hit the secondary cancel button.
- Description of action: Fully describe what would happen if the user were to confirm a destructive action. Make sure this is clear, concise, and transparent about what would occur by committing to the destructive action.
- Buttons: Use a secondary button on the left with language that suggests that they will not be committing to the destructive action, such as “keep” or “cancel”. The primary button is on the right and is red to convey that the action they are taking is serious. Use language to mimic the type of action they are committing to, such as “delete” or “block user” depending on the use case. These must always be paired together.