Error handling UX design guide

This guide will show you how to display errors in various situations for WorkSafeBC Apps

Field level errors

When the error happens at the input-field level, use this style

Field-level errors should display below the form field in sunset orange (#DC4405). The outline of the form field should also change colour to sunset orange.
Errors should display after the user makes the error (i.e., when the navigate away from the field) and not as soon as the start typing.
Errors can be triggered via events such as the clicking of a button
Error messages with one sentence don’t require a period at the end; however, error messages with multiple sentences do require a period.
Typically, buttons should always be enabled so that if the user skips a field or has an in-field error and clicks a continue button, they are automatically scrolled to where the first error occurred.

Example:

Your ID

Please provide a valid ID

Common errors in form fields

Field	Message	Condition
Account number	Please enter a 6- or 9-digit account number	User leaves the WorkSafeBC account number field blank
Claim number	Please enter your 8-digit claim number	User leaves the claim number field blank
Email address	Please enter your email address in the format name@email.com	User leaves the email address field blank or does not follow the correct email format
First name	Please enter your first name	User leaves the first name field blank.
First name	Your first name must contain X characters	...
Phone number	Please enter a 10-digit phone number	Please enter a 10-digit phone number

View reference

Combination-level errors

When a user is required to provide a combination of fields in order to continue, and their combination is incorrect, we display back a red blockquote

Example:

Last name

Please provide a valid claim number

Date of birth

Claim number

Claim not found

Thee information you've entered does not match a claim on file. Please try again

Application level errors

Application-level errors (e.g., we’re unable to display any of the user’s information) are displayed using our Alert styling.

This styling is to be used for scheduled downtimes
Errors should display after the user makes the error (i.e., when the navigate away from the field) and not as soon as the start typing.
The heading will tell the user what we’re unable to display depending on the application (e.g., payments, reports, resources, etc.)
The subtext will tell the user to refresh the page or call our technical support team (this is standard across all applications)

Example:

No search results found

Within an application, if a user searches or filters for something and it returns to results, we display a yellow blockquote

Example:

No [INSERT WHAT THEY WERE SEARCHING FOR] match the criteria you specified.

File upload errors

Upload errors are handled at the front end level as much as possible immediatelly after the error is detected.

Example:

Click to upload a file

The file type you selected is not supported and cannot be uploaded

View form uploader states

Error handling UX design guide

Field level errors

Example:

Common errors in form fields

Combination-level errors

Example:

Claim not found

Application level errors

Example:

We were unable to display your ______

No search results found

Example:

File upload errors

Example:

Your contact information

Will you or someone else be helping the injured worker with their claim?

Yes - No toggle controls

input fields

Input group - date of birth

Input group - mailing address

Mailing address

Radio buttons

Text areas

Checkboxes

Form group - Time approximate