"Error messages are the only text that we hope that the customers will never see."
(Kinnereth Yifrah)

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.

Good form validation

The primary guidelines of good form validation are:

• Talk to the user! Tell them how to do it right!
• 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 channel guidelines

How to work with error and incidents specifically within common channel context:
Errors and incidents in common channels

Validation errors

Messages below input fields

All error messages should follow these:

• Written in plain language rather than technical terms.
• Constructive so the customers know what needs to be done to fix the problem.
• If it is helpful and there is enough space, explain what went wrong.

4 main principles

1. Focus on how to enter the data correctly
2. Principles for mandatory fields
3. Principles of invalid characters or formats
4. Something is wrong but we don’t know what it is

1. Focus on how to enter the data correctly

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:

• Fyll i …, Välj …, Skriv …
• Enter…, Choose…, Fill in…, Type… or Write…

Or, if the customer can choose to either type or select in a list or date selector:

• Fyll i eller välj …
• Enter or choose…

When the message needs to be explicit:

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.

When you need to display the same message for more than one error:

• Datumet har fel format eller så finns det inte. Du kan använda formatet ååååmmdd.
• The date is in the wrong format or does not exist. Please use the format YYYYMMDD

When the characters that can be used are very constraint (for international payments):

• Du kan använda: 0–9, a–z (små och stora) och tecknen ? / - ( ) . , + : ’
• You can use: 0–9, a–z (uppercase and lowercase) and the characters ? / - ( ) . , + : ’

When the error is helpful enough and the solution is over explicit:

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.

When the date must be a business day:

• Datumet måste vara en vardag.
• The date must be a business day.

• Datumet måste vara en vardag. Välj en annan dag.
• The date must be a business day. Choose another day.

When the date must be in the future:

• Datumet måste vara senare än idag.
• The date must be later than today.

• Datumet måste vara senare än idag. Välj en annan dag.
• The date must be later than today. Select another date.

2. Principles for mandatory fields

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.

Example 1

• Fyll i din e-postadress.
• Enter your e-mail address.

Example 2

• Fyll i eller välj mottagarens kontonummer.
• Enter or choose the recipient’s account number.

Example 3

• Fyll i betalningens OCR-nummer.
• Enter the payment OCR number.

3. Principles of invalid characters or formats

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:

Example 1

• Skriv personnumret med 12 siffror.
• Enter the personal identity number with 12 digits.

Example 2

• Skriv kontonummer med 11 siffror utan mellanrum.
• Enter the account number with 11 digits and no space.

4. Something is wrong but we don’t know what it is

We know something is wrong, but we don't know what. We ask the customer to check the input data again:

Example 1

• Kontrollera att du skrivit din e-postadress rätt.
• Check if you typed your e-mail address correctly.

Example 2

• Kontrollera att du skrivit rätt Iban-nummer.
• Check if you typed the IBAN correctly.

Contact the UX writing team

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 cx-skribenter@seb.se, 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:

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 happened.

Examples of components with error states:

• Radio buttons
• Checkboxes
• Input fields
• Toggle selector

The colour for error text and indication (box, line, etc) on white/grey background:

• Error

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.

Exemple of general form component with error states:

• Alert ribbon
• Toast notification

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.