Error and Alert Notifications

Overview

Error messages provide critical information that requires user action to correct, while alerts convey non-critical information that may help prevent future errors. Errors should explain the issue and how to resolve it, while alerts simply warn users of potential consequences.

Usage Guidance

When To Use This Pattern

• Use alerts to notify a user of a potential error down the line.
• Use errors to notify a user of any errors made during their workflow.
• Use this pattern when dealing with roadblocks in a users’ workflow.
• Use this pattern for system failures.

When To Use Something Else

• Use a toast to convey other types of statuses.

Variants

Inline Validation

Inline validation gives users feedback on their input accuracy as they fill out a form, displaying error messages next to the input field to help them correct mistakes. This can occur in two ways:

• When a user shifts focus out of a field, ideal for simple inputs like names.
• When a user submits a form, suitable for complex fields and those with interdependencies.

Anatomy

Form field validation consists of:

1. Error Container: This should be red to highlight there is an error in the field.
2. Error Message: The error label and corresponding message are highlighted in red. Ensure the message is concise and helpful to the user.
3. Alert Container: This should be orange to denote this is a warning state.
4. Alert Message: The alert label and corresponding message are not highlighted. This message should also be concise and helpful to the user.

Usage Guidance

When To Use This Variant

• Incorrect input or formatting in a form field
• The error or alert is directly related to a specific input field.
• Minimise disruption to the user flow.
• The content on the page is relatively short or simple.

When To Use Something Else

• Use Banners for complex form validation.
• Use a Modal for more complex errors.
• Use a Modal for custom validations configured by the customer.

Best Practices

• For errors, display container and error message in red.

• For alerts, display container in orange and the message in grey.

• Display all messages underneath the input fields.

• Be specific about the error and how to fix it.

• Prefix validations with ‘error’ or ‘alert’.

• Use placeholder text to prevent errors.

• Display error message when user activates field but before characters are entered.

• Rely only on colour to display an error or alert.

• Use vague language such as “Invalid input”.

Technical Implementations

Technical Considerations

• Custom validations set by the customer do not support inline validation.
• Ensure the user can navigate through error and alert messages using the keyboard only.
• Include messages are programmed effectively to announce errors and alerts to those using screen readers.
• Error messages supersede alert messages in the input field.

Technical Documentation And Resources

• Form Field
• Error And Alert Messages

Product Examples

Banner

Error banners are used to communicate errors and alerts to users. They typically appear at the top of the screen and utilize contrasting colours and icons to capture attention and convey the severity of the situation. The UI persists the Banner and error message until the issue is resolved.

There are typically three types of banners in use:

• A red banner that slides out from the side. These are XO widgets that are used on main pages and trigger a modal on click.
• A red banner that is displayed in the centre top of the screen. These are bespoke components that are generally used for modals. This will open another modal on click.
• A pink banner which appear in modals and side panels. This is sticky and is an XO widget. This does not trigger a modal but lists the errors and alerts below on click.

The use of each of these is dependent on the tech stack of your team.

Anatomy

Error and alert banners consist of:

1. Icon: Supplementary visual indicator used to distinguish between error and alert Banners.
2. Label: Total count of all errors and/or alerts on a page.
3. Action Text (Conditional): Link text that indicates the Banner is actionable. Activating the link opens a list of all errors and alerts on a page. Action text is only available in the full Banner variant and has a default value of View All.
4. Container: Colored container that houses the error or alert icon, message, and action text. The container can be full or sticky, in which the Banner is to be displayed along the right edge of the page.

Usage Guidance

When To Use This Variant

• Use Banners for complex form validation.
• Use Banners for errors and alerts within Microtransactions.
• When a user cannot move on until errors are addressed.
• To convey errors upon submission.
• To convey alerts that don’t require a modal.

When To Use Something Else

• Use a Toast for low emphasis alert messages that allow a user to continue in their workflow.
• Use Inline validation for fewer errors.
• Use a Modal for more complex errors.

Best Practices

• Place the banner at the top of the screen to catch the users’ attention.

• Use an error icon and red colour for error banners.

• Use an alert icon and orange colour for alert banners.

• Combine errors and alerts into a single error banner when both are present.

• Open a modal when there is an action view to multiple errors.

• Persist the error banners until the errors have been resolved.

• Display separate error and alert banners if both are present.

• Stack multiple errors or alerts on top of each other.

• Display a banner without highlighting the errors or alerts.

• Place a banner where it blocks important content or navigation.

Technical Implementations

Technical Considerations

• Focus banners that are triggered by user action to guide interaction.
• Avoid focusing system-generated banners as this can disrupt user flow.
• Banners must clearly convey their content and type (alert or error) to screen readers.

Technical Documentation And Resources

Banner

Product Examples

Modal

Alert Modals are used to inform the user about errors that need to be corrected before the user can proceed. They typically appear as a pop-up window overlaid on the current page with a darkened background. All UI in the background is inaccessible until the user takes action on the modal. These are often used in conjunction with banners and inline validation. Where errors on the page are not immediately visible or there are multiple, modals are often more appropriate than inline validation or banners. This pattern is disruptive so should be used mindfully.

Anatomy

Modals consist of:

1. Card: The Card contains content for a modal. It has no stroke or depth applied because it appears in front of an overlay.
2. Heading (Optional): Heading should display the title of the content or task.
3. Body: Modals contain many different types of content in the body. Typical types of content include media, alerts, dialogs, and/or task-oriented flows.
4. In-line Buttons (Optional): Action should be at the bottom of the container when used. There are multiple alignments available for use; Left (Default), Center, Full Width & Full Width Stacked, or Right aligned.
5. Close “X” Icon (Optional): Users must be able to intentionally dismiss a modal. This icon inherits styling and interactions from our Tertiary Icon-Only Button Variant.
6. Overlay: Used to block user interaction with content behind it. When there are no Close “X” Icon, clicking on the overlay doesn’t dismiss the modal.

Usage Guidance

When To Use This Variant

• Provide error messages that don’t pinpoint to specific elements on the page.
• The users’ full attention is required.
• Errors that are generated after the information is submitted.
• Customer configured validations that cannot avail of inline validation.

When To Use Something Else

• Use a Toast for low emphasis alert messages that allow a user to continue in their workflow.
• Use Banners for form validations where error and alert messages apply to specific elements on a page.
• Use Inline Validation for inputs that generate immediate errors or alerts.

Best Practices

• Use a clear title with a concise error message.

• Provide specific instructions on how the user can resolve the error.

• Where possible, set focus to the first input in the modal.

• Allow users to resolve errors in the modal if possible.

• If the user clicks a modal error linked to an input field outside the modal, close the modal and focus that input field.

• Use vague language to describe errors.

• Have more than one task in the modal.

• Trigger the modal without warning.

• Show an error that is not linked or highlighted to a field outside the modal.

Technical Implementations

Technical Considerations

• Move focus inside the modal to ensure accessibility.
• Ensure there is clear definition the context has changed to “modal dialog” for appropriate screen reader usage.

Technical Documentation And Resources

• Modal
• Error Alert Modal Figma Component

Product Examples

Empty State

While some empty states are helpful, error empty states halt user progress. Unlike other empty states, these require no user action to fix, occurring due to missing content, lack of permissions, or system failures. Whether shown fullscreen or within a container, these states signal a complete stop in the user journey. If the issue stems from missing content, consider using an Empty State Illustration.

Anatomy

Empty States consist of:

1. Illustration: Choose an appropriate illustration for the error.
2. Body: Use concise, helpful content to add context to the error and help guide the user.
3. Buttons (Optional): Action should be beneath the illustration and body copy.

Usage Guidance

When To Use This Variant

• A document does not exist.
• There is no content to display.
• A user does not have the correct permissions to access something.
• There is a system failure.

When To Use Something Else

• Use a Toast for low emphasis alert messages that allow a user to continue in their workflow.
• Use Inline Validation, Banners and Modals for critical errors that need to be rectified before proceeding in a workflow.

Best Practices

• Use clear language to explain the situation.

• Provide guidance on what the user can do next to move on.

• Return the user to a place that can allow them to progress, either the previous step or the homepage of what they’re working on.

• Tailor the tone, content and imagery to the specific context.

• Use vague language to explain the situation such as “Error 404” etc.

• Use language that blames the user such as “Your input was incorrect.”

• Exclude any calls-to-action or suggestions about how to proceed.

• Include imagery that conflicts with the content.

• Distract the user with too many visuals and elements.

Technical Implementations

Technical Considerations

• Imagery must not be exposed to assistive technology like a screen reader.

Technical Documentation And Resources

• Empty States
• Empty State Text

Product Examples

Product Examples