
Photo courtesy of flickr user tasuki
Traffic lights are ubiquitous and can be found in almost any city in the world. Whether it’s a pedestrian crossing, road intersection or anywhere with competing flows in traffic, you will always see traffic lights.
The concept is simple:
Traffic lights alternate the right of way accorded to road users by displaying lights of a standard color (red, yellow/amber, and green) following a universal color code (and a precise sequence to enable comprehension by those who are color blind).
- Illumination of the green light allows traffic to proceed in the direction denoted,
- Illumination of the yellow light denoting, if safe to do so, prepare to stop short of the intersection, and
- Illumination of the red signal prohibits any traffic from proceeding.
When it comes to designing software experiences this days, there is sometimes the need to display statuses against a record, usually coming in the form of a contrasting colour, self-explanatory icons, or even accompanied by text to better explain the status of the record.
Rather than re-inventing the wheel each time, why not look to the excellent design of traffic lights as a guiding principle?
Traffic lights are a part of life
Think about it, being able to understand how traffic lights work and what each colour means is something we all know. Red means “Stop”, yellow means “Look”, green means “Go”. It is ingrained in most of us since childhood.
Even without thinking, most of us react once we see this colours on our computer screen in our every day lives.
When to use it?
Just because some of the other systems uses statuses wouldn’t mean its suitable for your feature/context/product. Instead, its merely a solution that might come in handy in the following situation:
- The user is dealing with a big amount of records in a single go – Lists, Grids, Tables, etc
- There is a need to quickly communicate to the user whether they should be worried or not for some of the records.
- There is more than one information to communicate against a record
- There is limited screen real space
Interpreting statuses
I’m a big fan of the use of traffic light colours to quicken communication to users. On top of these 3 colours, I’m also very much into using grey as well. There are times when it would also make perfect sense to go the extra mile and use icons alongside statuses to communicate more information.
The tough bit is understanding that the communicated info would differs based on the context or objective of the system. Some examples below along with explanation on what it would communicate to the user and why is it necessary:
Inventory Management System
Status is used to communicate of stock levels.
| # | Colour | What does it communicate to the user | Why is it necessary |
| 1 | Red | Be worried it’s looking bad, action required | Stock level is running out |
| 2 | Yellow | Might be worrying, no further action required yet | Stock level is running low |
| 3 | Green | Don’t worry it’s all good, no action needed | Stock level is good |
| 4 | Grey | Ignore, not relevant anymore | Not keeping stock for this item anymore |
Financial Solutions
Status is used to communicate of your financial situation.
| # | Colour | What does it communicate to the user | Why is it necessary |
| 1 | Red | Be worried it’s looking bad, action required | You have exceeded your budget |
| 2 | Yellow | Might be worrying, no further action required yet | You’re about to exceed your budget |
| 3 | Green | Don’t worry it’s all good, no action needed | You’re well within your budget |
| 4 | Grey | Ignore, not relevant anymore | Your budget in the past, not as relevant now |
Customer Relationship Management
Status is used to communicate a customer’s relationship with your business
| # | Colour | What does it communicate to the user | Why is it necessary |
| 1 | Red | Be worried it’s looking bad, action required | Customer retention at risk, has overdue charges, etc. |
| 2 | Yellow | Might be worrying, no further action required yet | Customer might be at risk |
| 3 | Green | Don’t worry it’s all good, no action needed | Customer is fine |
| 4 | Grey | Ignore, not relevant anymore | Customer has went cold, moved to another country, chose another competitor, etc. |
Chatting Systems
Status is used to communicate which of your contacts are available for chat
| # | Colour | What does it communicate to the user | Why is it necessary |
| 1 | Red | Not available | Contact is online but busy, don’t disturb |
| 2 | Yellow | Might not be available | Contact is online but away, might not respond |
| 3 | Green | Available | Contact is online |
| 4 | Grey | Irrelevant | Contact is offline |
Some real world examples
Examples of them being used
| # | Example | Image | What does each status communicate? |
| 1 | Google Talk Chatting tool |
![]() |
|
| 2 | Facebook Chat Chatting tool |
![]() |
|
| 3 | iconnect360 Membership management solution |
|
|
| 4 | TortoiseSVN Source control software |
![]() |
|
Some tips and tricks
Below are some tips and tricks to take note of when showing a status of a record:
- If possible, minimise the use of colours between 2-4. Every additional colour would increase your user’s learning curve in using features.
- If your status is displayed as an icon, try to make sure the icon makes sense to the user.
- It’s perfectly fine to accompany each status with a short text, as long as it short and makes sense to the user.
- Less is more only if it is self-explanatory, so don’t cut that line of text and show an icon that nobody understands.
- There are situations when more information needs to be displayed to provide reasoning on why a record is now in a particular status, either:
- Use a tooltip – Show the information only when the user’s mouse cursor hovers over the status
- Use progressive disclosure – Hide it and show it only when the user clicks on the status a link beside it.
- Show it – Have it alongside the status, maybe even in a list if there are multiple entries.
Summary
Just to recap, the design of statuses is just one of the many ways we can use existing design principles around us to shape interactions in our products, the key takeaway here is to make sure all statuses are self-explanatory.
Feel free to share in the comments if you find these guidelines to be useful.


