An award-winning collaborative, global project.

This wiki is no longer being updated. But it is still available for anyone who wants to make style decisions based on evidence and data.

Search

Part of: Clear language

Error messages

Last updated: 10 February, 2020

Following this helps everyone, particularly people with:

  • time pressures

  • cognitive impairments

  • visual impairments

  • motor impairments

  • non-fluency


Guidelines

The best approach is to test your designs from the beginning of, and throughout, the design and development process. 

And get a user centred design writer to write all the words. Words include: content, notification and error messages, field names, field labels, microcopy instructions. 

Instructions and messages should work alongside the system, providing contextual help to prevent people making errors, and to recover from them when they do. 

Accept that humans: 

  • make errors, 

  • are not always logical,

  • skip through things.

1. Involve a content designer or user experience writer from the start.
2. Test your digital product with users very early on, and throughout development.
3. Give instructions contextually when users need to take action.
4. Provide error messages contextually.
5. Write error messages in plain language and active voice.
6. Give as much information as you can without causing security issues.
7. Use a friendly tone and do not blame the user.
8. Avoid putting links in error messages.
Usability evidence

1. Involve a content designer or user experience writer from the start.

Having a writer with user centred design skills creating the content helps make sure people understand information throughout their online journey.

This means they will be more likely to choose the right actions for their needs, and to understand any instructions they have to follow.

2. Test your digital product with users very early on, and throughout development.

Find out what users do not understand, and where they go wrong. Set up tasks that trigger error messages, so that you can research whether they make sense to users, and that they know what to do next.

3. Give instructions contextually when users need to take action.

If users need to click a button or input information into a form field, provide instructions close to where they need to interact.

Contextual guidance and prompts help users take the correct an action for them. This reduces errors.

4. Provide error messages contextually.

Position error message content where the error is, not as a list at the top of the page. List can be overwhelming and hard to remember. Contextual information is also more accessible for people with a narrow field of visual focus, motor impairments or cognitive challenges.

For example, provide the error message below the form field where the user needs to change something. Make sure your error message is not inside the form field.

Make it clear that there are errors that need correcting, so that user isn’t left wondering why they cannot progress.

5. Write error messages in plain language and active voice.

Apply readability guidance around clear language. Get a content designer or user experience writer to write the error messages, working closely with developers.

As a content designer or user experience writer, help this happen by communicating with developers regularly, even if you are not co-located. Ask in advance when you can support developers with error message creation, and designers with field naming, labeling and microcopy instructions.

Generally, error codes and related technical jargon are not understood by users who are not developers.

6. Give as much information as you can without causing security issues.

Avoid writing something meaningless just to make sure it is secure. Say as much as you can, clearly. 

Make sure no one on the design and development team is being overcautious. Find out how much you can say. Involve a service designer if you have one on your team, and the product owner. 

Informative error messaging is important and is a Web Content Accessibility Guidelines 2.1 requirement. Error messages need to help users, not confuse them. It may be that the user did not understand something else, which resulted in the error. These users need clarity and support.

7. Use a friendly tone and do not blame the user.

Tone is important for error messages. Frustration at error messages can raise users’ cortisol levels. Do not blame the user. 

Do not over-apologise. If it is a system error, explain that and do apologise.Use a friendly, human tone, but avoid starting with “oops” or trying to be humourous. Errors delay users in completing online tasks. Their time is being wasted. An automated joke shows no empathy, can be very annoying and is not usually helpful.

Provide an obvious “contact us” link in the header or footer, so that you do not need a contact link in an error message. Make sure the content on your contact page includes information about technical support. 

Usability evidence

Error identification, World Content Accessibility Guidelines (WCAG) 2.1, 3.3.1, World Wide Web Consortium (W3C), 2019

Labels or instructions, World Content Accessibility Guidelines (WCAG) 2.1, 3.3.2, World Wide Web Consortium (W3C), 2019

Error suggestion, World Content Accessibility Guidelines (WCAG) 2.1, 3.3.3, World Wide Web Consortium (W3C), 2019

Error message component, Design System, UK Government Digital Service, 2019

Error summary component, Design System, UK Government Digital Service, 2019

Error Message Guidelines, J. Nielsen, Nielsen Norman Group, 2001

Visibility of system status, A. Harley, Nielsen Norman Group, 2018

How to Report Errors in Forms: 10 Design Guidelines, R. Krause, Nielsen Norman Group, 2019

Real-time measurement of human salivary cortisol for the assessment of psychological stress using a smartphone, S. Choi, S. Kim, J. Yang, J. Lee, C. Hyo-Il Jung, Sensing and Bio-Sensing Research, 2014

Do You Care if a Computer Says Sorry? User Experience Design through Affective Messages, M. Khoo, 2012. Online PDF, or download 232 KB.

Touch OK to Continue: Error Messages and Affective Response on Interactive Public Displays, H. Kukka, Department of Computer Science and Engineering, University of Oulu, undated

Inline Validation in Web Forms, L. Wroblewski, A List Apart, 2009 

Technostress aus einer neurobiologischen Perspektive, Technostress from a Neurobiological Perspective, System Breakdown Increases the Stress Hormone Cortisol in Computer Users, R. Riedl, H. Kindermann, A. Auinger, A. Javor, SpringerLink, 2012

The Average Checkout Flow Has 14.88 Form Fields – Twice as Many as Necessary, Baymard Institute, 2019

Form Field Usability: Should You Use Single or Multi-Column Forms?, B. Labay, 201

Text fields, anatomy, Material Design, Google, after 2014: research is undated

Error message advice from other trusted design systems

We do not yet have knowledge about how much usability testing and research these organisations do, so we provide these references for interest only. They were not used to inform the readability guidelines on this wiki page. If you can link to research carried out in connection to these, please post the link on this page's comment section.

Alerts, Human Interface Guidelines, Apple

Error Messages, Design Guidelines, Microsoft