Help users avoid errors

Prevention is better than any cure. We should design products that help users to avoid seeing error messages in the first place.

Avoid authentication errors

Avoid situations where the session expires but the page doesn’t change. This is a common problem which is usually caused by only checking if the session is still active when the user does something.

This is frustrating because everything looks fine, until the user submits a form or clicks a link, and then any changes they made or information they entered is lost.

Instead, try to manage any session timeouts in a way where the user is actively redirected away from the page after a period of inactivity, instead of silently timing out in the background.

Avoid unecessary complexity

Most users make mistakes when they:

• are overwhelmed
• have too many choices
• can’t understand the interface

Keep the language and interface simple and free from clutter. Keep any choices scoped to the current task. And, make any interactions obvious.

This will make it a lot less likely the user will misunderstand something or click on the wrong thing.

Avoid abstract concepts

By abstract concepts, we mean anything which requires the user to make connections between pictures or symbols and their meaning.

For example, do not use an asterisk to highlight required fields. This is abstract, it's not clear for everybody. It also creates additional work for accessibility, as screen readers will just read out the asterisk.

At Elastic, we work on the principle that all fields are required unless stated otherwise. If a field is optional, ask yourself, is it really needed?

Having too many fields on the page at once increases the cognitive load and the likelihood users will make a mistake. Optional fields just add to the noise.

If something is truly optional, and there is a definite need to include it, add (optional) to the label.

Good example:

Occupation (optional)

Bad example:

First name *

Avoid guesswork

For interactions which may not be obvious, set the expectations for the user.

For radio buttons, you might say:

• choose one
• select one

For checkboxes, you might say:

• choose as many as you like
• select all that apply

For a sortable list, you might say:

• drag the items to reorder the list
• use the drag handles to reorder the items

Avoid rigid formats

Always expect users to enter information in different formats. Some will use uppercase, some will use lowercase, some will use a mix of both. Some may also include special characters or spaces.

Assistive technology, such as Dragon speech recognition, will add space characters when people pause for breath, and capital letters at the start of a sentence. You should allow users to submit these characters, but sanitize them before validating.

Sanitizing is reducing the inputted information to its simplest form. You should always sanitize user inputs for security anyway, to strip out any attempts to inject code.

For example, if you want the user to enter a percentage as just a number, they still might enter it a few different ways:

• 100
• 100%
• 100 %
• 100 percent

We should work hard behind the scenes to accept the user's input in whatever format they entered. If we can’t, we should be specific about why.

A good example of a sanitisation and validation process:

1. validate if the input contains information

   1. if it does, goto step 2

   2. if it does not, highlight an error and tell the user it cannot be blank

2. sanitize, remove any non-numeric characters, like letters, symbols and whitespace

3. validate the remaining number is greater than 0

   1. if it is, goto step 4

   2. if it’s not, highlight an error and tell the user the number must be more more than 0

4. validate the remaining number is less than than 100

   1. if it is, accept the input as a valid percentage

   2. if it’s not, tell the user the number must be less than 100

A bad example of a sanitisation and validation process:

1. validate if the input contains information
2. validate if the input is a number
3. validate the number is greater than 0
4. validate the number is less than than 100
5. if any of the checks failed, tell the user their input is invalid

Where a specific format is required, follow

content patterns and provide help text to help the user fill it out correctly the first time around.

For example:

Label:

Temporary key

Help text:

It’s in your welcome email. For example: ES12345