Many software developers fail to understand the principles of designing usable notifications the right way.
It sounds like a simple feature, but when you look at it from the end-user’s perspective, there are some important things that need good execution.
Let’s start with defining what a notification — in the sense of a software product — is.
Notification in a software product is a piece of information (audio, visual or both) that tells the user about an occurence of an event he otherwise wouldn’t be aware of.
How notifications work in popular products? Here are some examples.
Examples of badly designed notifications
Reminders app on the iPhone is great at the concept level. However, the execution leaves much to be desired.
Apple failed to seamlessly notify you about your tasks when you’re using multiple devices. If you’re using a Macbook with iPhone and iPad on the side, the notification will pop-up within a short period of time on all these devices. As a result, you will hear a single notification three times in a row.
Furthermore, if you notice a reminder on your Macbook and press the “Close” button, the reminder will not be marked as “Completed”.
You still need to open the Reminders app and put a check next to the completed item. That’s when you realise the Reminders app is not designed to just remind you about some events. It’s actually a more advanced to-do list.
Pingdom service notifies you about their beta features in “Beta labs” menu. The problem is, the notification persists even if you’ve already read the message. As a result, I have seen this notification for 6 months now!
Examples of well-designed notifications
iPhone’s Messages app is a classic example of well-made notifications in a software product.
The red badge has a strong contrast among colorful icons. The badge stays in this state until we read the message, and disappears immediately once we read it.
Facebook did a good work with notifications, too.
They follow a common visual pattern in both web and mobile versions of the product. Notifications disappear only when you read the message the notification refers to.
Principles of usable notifications
Let’s consider three basic features of usable notifications.
- Display a notification if the user hasn’t read the message. Stop displaying it immediately once the message is read.
- Follow a proven design pattern, which shows the number of unread messages displayed on a red background.
- If the item the notification refers to is not immediately visible (for example, the item is not displayed on the first page of the paginated list), help the user reach this item by displaying notification badges inside the paginated list.
The 3rd point refers to a rare situation that I explain on the screenshots below.
How LiveChat displays notifications
Our customers rely on the notifications during their everyday work. We help our users know what’s going on regardless of which part of the app you’re currently viewing.
When a visitor sends a message during the chat, the agent is notified with a native browser notification in top-right corner of his screen.
Moreover, a red badge is displayed in the main menu in LiveChat.
When the agent is currently viewing a different browser tab, he will see the number of unread messages on the app’s tab as well.
When the agent is already chatting with a customer, and someone else responds, the notification appears on a circle representing the chat with the customer.
If the agent has lots of concurrent chats, the chats with highest idle time are hidden on the second page. However, if the customer reponds to one of the idle chats, a notification on the pagination arrow appears. It indicates that some of the chats on the second page need our attention.
Each of these notifications have little impact alone, however, together they build a cohesive system of notifications that makes sure the customer will receive an immediate response from the agent.
What to improve
The presented notifications patterns used in LiveChat are still missing some advanced use-cases coverage.
For example, due to its real-time nature, LiveChat does not remember the unread messages anywhere in the backend. It’s the application GUI that displays the red badges when needed. As a result, when you close the app for a moment and get back to it, your unread messages notifications are lost.
To fix this, we would need to store unread messages list or the current state of the GUI in our backend. It’s not a one-minute-job and can potentially lead to unexpected badges behaviour if done wrong.
Another issue is the synchronisation between different devices. While it’s pretty easy to synchronise the app instances opened in multiple browser tabs, LiveChat agents can use other devices to chat with their customers (iPhone, iPad and Android). It involves the work in the backend to synchronise the notifications across devices.
Final notes
In most cases, following the basic principles should be enough to build a usable notifications system.
When you work in line with the Lean methodology, you probably don’t want to spend whole weeks on building a complex logic behind notifications. It is better to skip the advanced refinements like synchronising read notifications across other devices in real-time as basic principles cover ~95% of situations.