UX Guidelines for Error Handling

message not proximate
Not what you want to see!

Error handling is too often an overlooked aspect of UX design. Removing the pain from error experiences is critical because if a user encounters an error, they are probably already frustrated.

Error messages expose the interface. A well-designed interface becomes invisible; the user is not thinking about the interface but about her tasks. So errors are where the interface manifests — where users actively think about the experience. If it’s poor, users will judge the system harshly.

Here, then, is a set of basic guidelines I have developed for those seeking ways to improve their user’s experience of error messages. They are not “best practices”, just a set of general tips cobbled together from various sources, including my own experience. They are mostly aimed at improving form/input errors.

  • Avoid the error occurring in the first place
  • Show the user the field where the error has occurred
  • Use inline validation
  • Be polite – don’t blame the user
  • Be precise – clearly describe the issue, and how to resolve it
  • Reduce the work required to fix the problem

Avoid the error occurring in the first place


Example: in a calendar date-picker, the user should not be able to select a date prior to today.

date in past



By making dates prior to today unavailable for selection, a potential error is avoided.

Show the user the field where the error has occurred


After the user clicks the submit button, some pages display error messages in a list near that button, or in a box at the top of the page. The user then has to  hunt for the relevant fields. The error message should be near the relevant element.

message not proximate


message - red only

The examples above are an improvement because the error messages are proximate to the relevant filed.

They also highlight the message text and (in the latter example) the input border, by changing their colour to red.

While the user of red for warnings is a common design pattern, and is usually satisfactory, there is an accessibility caveat. The methods shown above are not sufficient for some colour-blind users, who may not notice when elements turn red.

Do (Accessible Version)

messages - do

The above examples use a combination of red text with an additional visual indicator (icon / thicker border).

Use inline validation


old style validation

Error messages that only appear after the user submits the form are particularly annoying, as the user would have been expecting to go to the next page. If there are multiple errors, the form can appear aggressive. There is also a greater risk that the users’ data is wiped with this approach.


inline validation

Inline validation helps the user to correct the error immediately. It also reduces the wait time before the error appears, and reduces the chance of losing data in the form.

Note:  When there are more than a few fields, it is better not to validate blank fields until the user submits the form. Users often don’t fill fields in the order they appear.

Be polite – don’t blame the user


error language don't

The error message above seems to “scold” the user.


error language do

Instead, by immediately pointing out how to fix the error, and by using word “please”, the above message is softer.

Be precise – clearly describe the issue, and how to resolve it


email message dont

This  message is vague.


error language do

This message is more precise, and indicates what the problem is so the user can resolve it.

Reduce the work required to fix the problem


invalid user dont

In the example above, the username originally entered by the user is now gone.


user not found do

A better approach is to keep the data the user has entered, so they can see if it looks wrong, and try to fix it.