The last version of Internet Explorer, version 11, was released on October 17, 2013. This is a very long time ago when taking into account the rapid development of web technologies. These days it is often difficult and time consuming to get modern technologies to work well in this old browser. More and more frameworks are dropping support, and even Microsoft themselves has announced that they will fully drop support for IE in their own services in 2021.
Consequently, we have decided to not include support for IE in the Design Library website.
Luckily, there are modern options in active development. Please use Firefox, Edge or Chrome instead.
Error handling guides the customer to fulfil their task successfully.
"Error messages are the only text that we hope that the customers will never see."
This page discusses our general guidelines and links to more details. The first principle of great user experience is to make the user feel safe. By design, lead them so that it is easy to do the right thing and use positive indications that they are on track.
The primary guidelines of good form validation are:
How to work with error and incidents specifically within common channel context:
Errors and incidents in common channels
All error messages should follow these:
Space below the entry fields, is often limited. Therefore, the message needs to be short. Avoid telling what the customer has done wrong – unless it is needed. Instead, focus on the solution, that is how to fill in the field correctly.
Use verbs like these:
Or, if the customer can choose to either type or select in a list or date selector:
Situations when the message needs to be explicit are for instance, when the same message needs to be displayed for more than one type of error or when the characters that can be used are unusually constraint. In these cases, it is helpful to tell both what is wrong and how to enter the field correctly.
However, the message does not need to be over explicit when it is obvious how to do the right thing. Such situations are for example when the customer needs to choose another date because the date is not a business day or a day in the past.
Never use messages such as Mandatory field or Must not be empty. Ask the customer to fill in the field. But just Fill in this field is not enough. You should also mention what kind of information the customer should enter. For each field.
Never use messages such as Invalid characters or Illegal data. Instead, encourage the customers to fill in the field and mention what kind of data they should enter, for example:
We know something is wrong, but we don't know what. We ask the customer to check the input data again:
The validation error is one of the most important interactions the users have with us. It is often tricky to get the tone-of-voice, the instructions and the vocabulary correctly in such a tiny space. This is what our UX writers are trained for, so please don’t hesitate to contact the UX writing team for error handling. Reach out in the Teams channel “UX writing” in Green Design System, send an e-mail to firstname.lastname@example.org, or if you already have a connection, simply contact that person.
Error messages in forms can be visualized in two different ways, depending on the type of error:
When the user enters information in a field, the input should be validated when the user leaves the field. If there is an error connected to the input in the field, the user will get an error message when leaving the field. There will be a red mark under the field and an explanation of the error that happened.
Examples of components with error states:
The colour for error text and indication (box, line, etc) on white/grey background:
When the user is submitting the form by an action (e.g. a submit button), a validation should occur for all fields. If there is an error connected to a specific field, for example if the user has not entered any information in a field that is mandatory, the error will be shown as for the field specific errors (see 1).
If there is a more general error for the field, the error will be presented in a red alert ribbon below the button. When the user presses the button the the viewport should adjust to make the alert ribbon visible. The alert ribbon should contain a message about the general error. If there also are specific errors connected to specific fields, both 1 and 2 can be combined.
Exemple of general form component with error states:
The error page is typically used when a system is down or a generic error has occurred.
When an error can not be presented on the current page, a separate page is used just to display the message. The error page should ideally contain a good description of what the nature of the problem is and how the user may avoid or rectify the problem.
Page is down, major technical problems.
The page on the internet is not available any longer.
If the error is a 404 (page not found) the page may include some nice options of where to go. Common items may include the index/home-page, search or other sites.