Internet Explorer is not supported by Design Library

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

How to guide the user to success.


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.

This page discusses our general guidelines. When the user makes errors, help them out with a clear, kind and helpful message.

The primary guidelines of good form validation are:

  • Talk to the user! Tell them what is wrong!
  • Use colours to alert
  • Place the error message under the input field
  • Stay on the same page until the error is corrected, preferably as soon as the user has inputted the data
  • Use positive inline validation while typing
Common shell guidelines

How to work with error and incidents specifically within the Common Shell context: Errors and incidents - Common Shell

Error handling in forms

Error messages

Error messages in forms can be visualized in two different ways, depending on the type of error:

  1. Field error
  2. General form error
1. Field 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 occurred.

2. General form error

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.


  • Error text on white/grey background: #9F000A

Components that communicate error states:

Error page design

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.

Error page 500

Page is down, major technical problems.

Error page 404

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.


All error texts should follow the following guides:

  • Written in plain language rather than technical terms.
  • Precise by explaining exactly what went wrong.
  • Constructive so users know what needs to be done to fix the problem.

Page last updated


Was this helpful?