System alerts

How to make our users aware of potential and current system status updates that might require user interaction.

Guidelines

When there is a change in functionality or account status, a message in the user interface provides users a sense of what is going on with the application and/or can prompt for further user action.

For example; we inform logged-in users that the system is going to be in maintenance mode between 18:00-22:00.

Placement of alerts

There are four types of alerts that depends on the context. Make sure to place the alert near the issue that triggered it.

Levels of severity

Each type of alert has three levels of severity. Use colours to get the level of attention you deem necessary.

Behaviour

Alerts should behave the same way, regardless of device or resolution. 

General concept

An empty state happens when there’s nothing to display in a particular context.

We differentiate between two ways of handling this - either you want the empty area to draw attention, or you want it to be subtle:

  1. In some cases this is a “problem”, for example the user doesn’t have any accounts to display in an overview.
  2. In other cases it’s quite normal for a table to be empty, for example an empty list of payments. 

 

Examples

Empty state with higher attention

In this case user doesn’t have any accounts. In zone 2 where the accounts should have been listed, an error-ribbon (whisper) is used to indicate where the accounts should have been. In zone 3 we do our best to sell the prospect of opening the missing products if this is appropriate for this user.

 

Empty state with low attention

In this case we have a function where the user has simply not added any information yet. The table headers are visible, but the table contains no rows yet. This is subtle and is not a cause for major concern.