Some examples of errors include:
User input errors
App errors
Incompatible state errors
Forms
General usage errors
Sync errors
Connectivity
Permissions
Errors occur when an app fails to complete an action, such as:
Minimize errors by designing apps that make it easy for users to input information flexibly. Apps should accept common data formats that use affordances to improve user understanding.
To address errors:
Help users fix input errors as soon as they are detected. Disable the submission of a form if errors are detected, and if detected only after form submission, clearly explain the error and how to fix it.
Helper text may be included before, during, or after a user interacts with each field on a form.
Show error text only after user interaction with a field. If the user inputs incorrect data, helper text may transform into error text.
Minimize form text to the essentials. Not every text field needs helper and/or error text.
Specification:
Place 16dp of vertical space between text fields and below the error text.
Example of a text field input
Example of a text field input with error text
The Submit button should be enabled by default.
If you are performing inline form validation, and the field with the error is clearly marked, the submit button may be disabled until the error is corrected.
Error text should reflect your product’s color palette. It’s recommended that you use a contrasting color for error states, such as a warmer hue like red or orange.
Error text should be legible, with noticeable contrast against its background color.
Sites such as webaim.org offer color contrast checking tools.
Light theme for these states: normal with hint text, normal with error text, normal with helper text, and normal with helper as error text
Dark theme for these states: normal with hint text, normal with error text, normal with helper text, and normal with helper as error text
Example with helper text
Example with error text
Example with helper text
Example with error text
Examples of normal with helper text and normal with helper and error text
Input and error text
Tile height: 64dp
Padding above input text: 16dp
Padding below input text: 8dp
Padding above and below error text: 4dp
Example of floating text label with input text
Example of floating text label with error text
Examples of normal with hint text/label and normal with input text, label and error
Specs for floating text label
Tile height: 80dp
Padding above label text: 8dp
Padding above and below input text: 8dp
Padding above and below error text: 4dp
A character counter may be displayed before, during, and after user interaction with a field. Consider not displaying the counter until the user approaches the character limit.
Example of a single-line input label with character counter and user input text
Example of a single-line input label with character counter and error text
Example of a multi-line input label with character counter and user input text
Example of a multi-line input label with character counter and error text
Examples of these states: single-line input label with user input text, single-line input label with error text, single-line input label with user input text, and multi-line input label with error text
Text field input
Height of entire input area: 88dp
Single-line input label top padding: 16dp
Top and bottom padding for input text for a single-line field: 8dp
Padding above counter: 8dp
Show errors for incompatible values during or after a user interacts with a text field.
If two or more fields have incompatible inputs:
Reload the form with consolidated error messages and scroll position at the top. Error messages for individual fields may be resolved as the user works through the form.
Example of a form
Example of errors detected after attempted form submission
Empty form fields should be indicated by both the text field and error message below.
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.
Individually label error messages as the user works through the form.
Example of a form
Example of an incomplete form
Example of a single-line list error
App errors occur independent of user input.
When an error occurs, an app should display loading indicators until the error message appears.
Features not available may be indicated as disabled in the UI. For example, a button not may be displayed in a disabled state, paired with text explaining it is not available. Not every error requires a new component to pop up.
If possible, give your user an action that will help them address the error.
Alert dialog: app feedback about an error that is blocking normal operation
The snackbar contains app feedback about a peripheral error. Snackbars are transient. Don't use them for critical, persistent, or bulk errors.
When sync is down or content has failed to load, the user should be able to interact with as much of the rest of the app as possible.
Empty state for the screen/content failing to load
Container/component specific error with action
When connectivity is down, the user should be able to interact with as much of the rest of the app as possible.
If appropriate, present a link to help a user accomplish their task. Only offer links that you can actually support. For example, don't offer an option like "Try again" in cases where you can detect that the operation will fail.
Snackbar with action to retry
Empty state for a screen that is only available online
Incompatible state errors occur when users attempt to run operations that conflict, such as making a call while in airplane mode or taking a screenshot from a restricted work account. Help prevent users from putting themselves into these situations by clearly communicating the states they are selecting and the implications for the rest of their experience. When these errors are triggered, do not imply that they are the user’s fault.
Clarify the reason for and origination of the error.
For example, screenshots and premium features are not allowed while in a restricted mode.
Snackbar + special mode indicator
Display an unobtrusive, persistent indicator when users are offline but try to do tasks that require being online.
Examples:
Snackbar
Indicator that the device has been placed into airplane mode.
If your app requires user permission before proceeding with an action, include the permission request in the app flow instead of treating it as an error.
If permissions are necessary before the first run of an app, consider including them into your app’s first-run experience.
Examples:
Dialog