This article is the twenty-second edition of the Advent of Patterns series. In this series, running from December 1st to December 24th 2024, I will document one design or programming pattern I have noticed recently. Read more about this series.

Knowing the status – or “state” – of a system or task is an essential part of interaction design.

Status indicators give a user an understanding as to the state of a system or task. Applications commonly use status indicators to indicate whether a task is in progress, has succeeded, or has failed. Applications may also use status indicators to indicate whether something has been read or not yet read (i.e. notifications in an application, emails in an inbox). Indeed, any time a task or system has a status to communicate, an indicator can be used to give an overview.

The indicator can then be accompanied by a more detailed description if required. For example, if a task fails, a reason should be given that is in a place intuitive to the user (i.e. next to the failed task in a list, via notification).

Below, I am going to walk through three examples of status indicators, then talk about some ways in which status can be conveyed.

Consider an email inbox. By default, emails that are unopened appear different to those that are opened. In ProtonMail, for example, unopened emails have a white background and opened emails have a grey background:

The white and grey backgrounds allow me to easily know whether an email has been read or is yet to be read. Furthermore, the text in an unread email is bold. This gives me another visual cue that the email is unread.

Combined with the other data in the email preview , I can make a decision about what to do: open an email, mark it in a specific folder, or leave it until later.

When I send an email, ProtonMail shows a “Sending Message…” indicator with a loading wheel. This tells me that my action has been completed. With this information, I can confidently move on to the next task: I know my email is being processed.

GitHub Actions, a piece of software I use to publish software, has four main states:

• In progress (conveyed by an orange, animated loading wheel)
• Success (conveyed by a green checkmark)
• Failed (conveyed by a red X)
• Canceled (conveyed by a grey question mark)

All of the chosen icons and symbols are relevant to the context of the application. I expect a loading state to show a loading wheel, a success state to show green or a checkmark, a failed state to show red and an icon associated with an error. The canceled icon is harder to convey, but it stands out both because of its unique icon and its lack of a bold colour like orange, green, or red.

The above states are conveyed in the overview of all workflows run in a project, and within each task itself. Here is an example of a project overview showing several workflows:

Above, there are two workflows: one has a green checkmark icon, another has a red X icon. The former indicates a workflow run successfully and the latter indicates there was a problem. From this data alone, I can learn both the state of the workflows and use this to easily identify workflows I need to check on. For instance, if I didn’t expect a workflow to fail, I can go in and investigate. Or if a workflow has been in progress for longer than I expected, I can go in and take a look.

When a task fails or is canceled, a notification is sent to relevant users. This ensures that everyone is aware of the failure and can thus investigate if required. This notification ensures that a user finds out about a failure even if they are navigating another part of the application at the time the task fails. A notification from GitHub Actions indicating a task fails shows the failed status indicator and, when clicked, takes a user to the page where they can find out more about what exactly caused the issue.

When I browse a Spotify playlist, a green download icon appears if a song has been successfully downloaded. If the song is queued to download, a loading indicator will appear. Both of these statuses give me useful information. If a song is green, I know I can play it offline; if a song is still downloading, it means I will need to maintain my internet connection to continue the download.

Here is an example of the downloaded state in Spotify:

Where possible, indicating more complex statuses in text – like “Downloading” for a song – is essential to ensure a user fully understands what you are trying to communicate.

The NN Group has more information on the specific characteristics that define effective indicators. The details of this topic are vast and there are many intricacies to ensure that indicators are understandable, meaningful, accessible, and do not overwhelm users. I encourage you to read their description on the ways to implement indicators to learn more.