Form errors happen when the system encounters invalid inputs, and they persist until resolved. Responsible form design offers users contextual and relevant information for correcting any errors in order to meet the necessary input criteria.
There are two types of form errors: single input and group input. The type impacts how the error is triggered and displayed.
A single input error affects only one component. A group input error reflects that there are errors with several components, and the errors are aggregated into a single message.
The most common type of form error delivery is through the usage of help text on input components. Some examples of this include text field, text area, radio group, checkbox group, picker, and combo box. Any input component could potentially trigger an error with an invalid input. Errors must be resolved before a user can move forward and successfully complete the form.
When an error message occurs, it will switch help text with error text on an input. Follow Spectrum’s guidelines for writing the error message and think about how to write error messages that show a solution. Thoughtful error message design helps users resolve problems quicker and move forward with less frustration.
When multiple input errors occur on a page, an in-line alert aggregates the error messages and increases visibility. Place this alert at the top of the page or section of a form. It can be used alongside single input errors.
If an in-line alert is shown with multiple single input errors, it will persist until all errors have be resolved.
There are two ways for how a form can be validated. Either is acceptable, depending on user needs and product use cases.
The most common type of form validation occurs when the user submits their inputs — often by selecting a button with a “submit” action label — and the form gets processed on the backend. If there’s any invalid inputs, then the system will return input errors.
Another type is validation in real time, where the form does not need to be submitted to return any input errors. Errors that appear in real time should not be shown until the user is done typing.
Here's a step-by-step example of how validation happens in real time:
For real time validation, make sure that the user is completely finished entering information before showing any input errors. Showing an error before being done with typing is frustrating and confusing.
In a single form, mark only the required fields or only the optional fields, depending on whichever is less frequent in the entire form.
If most of the fields are optional, only the required fields should be give an asterisk icon or have labels appended with “(required)”. If most of the fields are required, only the optional fields should be appended with “(optional)”. Never use an asterisk icon to note that a field is optional.
Communicate error messages in a human-centered way by guiding a user and showing them a solution — don’t just state what’s wrong and then leave them guessing as to how to resolve it. Ambiguous error messages can be frustrating and even shame-inducing for users. Also, keep in mind that something that a system may deem an error may not actually be perceived as an error by a user.
For help text, usually the error is related to something that needs to be fixed for in-line validation, so a helpful tone is most appropriate. For example, if someone were to miss filling out a required field that asks for their email address, write the error message like you’re offering a hint or tip to help guide them to understand what needs to go in the missing field: “Enter your email address.”
Learn how this applies to help text for text field, text area, combo box, and picker.
When aggregating error messages into an in-line alert, give a high-level summary of what the issue is with the form. Don’t point out each and every field that needs to be addressed; this is a security risk.
Forms are utilitarian, and not a place to be overly emotive. When an error happens, just tell the user what’s happening and what they can do to resolve the error to complete the form. View Writing for errors for more guidelines on crafting human-centered error messages.
Date | Number | Notes |
---|---|---|
Jun 01, 2022 | 1.0.0 |
|