Replacing one status with another without thinking is a recipe for user frustration
Statuses often don’t seem very important until you have to design them for glanceability.
The most common and extreme case of this is with car dashboards. When you’re driving 65 mph down a highway, the last thing you want to do is take your eyes off the road to try and decipher a strange status.
Most statuses usually aren’t that time-sensitive, but understanding statuses is often a core part of the User Experience. This is because often, the happy path is to leave after checking statuses. After all, there are no unexpected issues.
But that doesn’t mean that’s always the case. So here’s what you need to remember when designing other paths.
Designing for states other than the happy path
Previously, I talked about how it was necessary to show just enough information in overviews to match the user’s happy path.
After all, all they need in that case is a quick status check, like “everything looks good.”
However, if things aren’t all good, you can’t just expect to replace one symbol with another and move on with your design.
You need to consider the statuses in more depth for one key reason: users need to be able to determine their next steps based on the status. This is often summarized in the first of Jakob Nielsen’s ten heuristics: visibility of system status.
All the status shows us is that the “Networking” status is bad, which could mean a dozen different things. It’s the equivalent of an error message that says, “Something has gone wrong.” There’s insufficient context for the user to know what to do next.
How can we improve this? First, we should ask questions that help us determine the role that statuses will play (and how to support user interactions better):
- How many statuses should you present to your users?
- What are the next steps users should take after each status?
- How do multiple alerts interact with one another?
How many states can users be expected to either know or learn?
Many times, we assume that there are only going to be three colors associated with statuses:
- Green, which means all good, “Go,” or that a step is completed
- Yellow, which means caution, warning, or “Slow down.”
- Red, which means an Error,“ Stop,” or other problems.
But one of the first questions you have to ask is whether or not this is enough to summarize all possible statuses. To explain, let’s consider a fairly typical example: something or someone is offline. What’s the best color to describe this state? It’s an important status, yet it doesn’t necessarily slot into these colors nicely.
If your package is offline (i.e., it’s not yet in the system), is there a need for a critical (Red) Alert? Maybe, maybe not. Some packages, like heart transplants, might need this status, while others, like printer paper, might not.
One of the dangers of putting everything in the “Red” category is risking Alert Fatigue, where your users start to ignore alerts (with catastrophic results). However, putting something in the “Yellow” category might downplay the status.
Offline, as it turns out, tends to be represented by gray often.
This is the danger of working with only a few colors. So how many colors do you need? It depends on your environment. For example, in the Information Technology sector, there tend to be six standardized severity levels:
- Warning
- Minor
- Major
- Critical
- Indeterminate (cannot be determined)
- Cleared (Alert has been cleared)
As a result, there can be as many as seven colors to show different necessary statuses.
Your domain might not have strict status guidelines, but you should research how many statuses you need to represent. This is because you need to understand how many colors to use and how to make them distinguishable from each other at a glance. In addition, you don’t want your users confusing a minor and major warning because they’re similar in color.
However, there’s one other question you need to consider while considering your statuses: what is the following step users are likely to take?
Design for your user’s following likely action based on a status
What should the user’s next step be if they’re given a critical alert? That’s something you need to consider, as you might need to consider additional actions to ensure that users know certain statuses.
For example, what if there’s a time-sensitive critical alert on something (like your server was hacked, or the delivery person is waiting downstairs)? In this case, there might be additional design elements you might want to consider, like warning notices or modals.
The level of severity often mirrors the Visual Information-seeking mantra from Ben Shneiderman: Overview first, zoom and filter, then details-on-demand.
It’s usually only necessary to provide a simple overview with “Green” statuses, while “Yellow” statuses often require zooming in to understand further. “Red” statuses, on the other hand, require users to dig into the details to understand what needs to be done as a next step.
However, this is just a general rule of thumb: you will need to conduct user research to understand what the user’s next steps will be, especially if you are designing with more than three color statuses.
This is especially important if you’re presenting multiple statuses on a page. In that case, you have to consider how the statuses might interact with one another.
How do multiple statuses interact with one another?
Individual statuses don’t live in bubbles, and failing to think about them can have dire consequences.
Having an alert modal pop up every time there’s a critical alert sounds nice, but having six alert modals appear each time they access a page when they’re in a catastrophic scenario with multiple critical statuses does not.
Not to mention there might be interdependencies between different statuses. For example, if a server shows as offline, what do the other statuses involving that server show (if anything)?
As a result, the more statuses you intend to show, the more you have to consider if there are any other interdependencies you need to think about.
Statuses, beyond “all good,” matter
Statuses that show problems are often more critical to your users than those that show everything is okay.
In those cases, you need to anticipate what the user will do next after seeing such statuses. As a result, you can’t simply replace the color and expect things to work well. Not giving the users any clear next steps will lead to frustration.
So if you find yourself adding different statuses to support the user and their quest for glanceability, ask yourself these three questions. In this way, you’re not just providing different color badges: you’re giving them visibility into details that matter and providing the clear next steps to take.
Kai Wong is a Senior UX Designer, Design Writer, and author of the Data and Design newsletter. His new book, Data-informed UX Design, explains small changes you can make regarding data to improve your UX Design process.
