Notification system design is a complex topic. Between transactional and marketing messages, multiple devices per user and regulatory compliance (think GDPR), there is a lot to think about. In this article we are going to highlight some of the most important aspects of notification system design that we should think of when building one. Let’s get started.
Can anyone else relate to the overwhelming number of email notifications in their inbox?
That’s because email notifications are still the default notification system in workplace tools.
Our team uses collaborative design platform Figma, and every time a comment is posted there I receive an email about it. But without enough context, it's not very meaningful or actionable. And that's just one of at least a half dozen work tools with which I interact daily.
Receiving notifications to my email inbox from every work app and tool never felt right to me, and I think that’s because of the mindset that I have around email. When I'm in my inbox, I think more globally and when I'm in a different workplace platform, I'm thinking more locally. In other words,I need the right context--for example, in my work tool--to get the most out of my notifications. For example, I go into my inbox and see notifications from figma, notion, google docs, slack, and I have to reset my mind to think about those platforms specifically in order to really understand what the notification means to my workflow. When I'm IN Google docs and I can see the comments alongside the text, it's less disorienting.
When MagicBell first brought me on to help design a complete notification system-as-a-service, I looked at what other notification systems were already out there. It was fascinating to see that even the most advanced notification systems seemed to be entirely geared around engagement, largely within apps like Facebook and LinkedIn. The in-app notification systems in many work and productivity tools were not that robust, and relied mainly on email.
But then I understood why that’s the case: Work tools are in the business of being work tools and they're not focused on efficient, customized notification system design as a primary feature.
As work activities and collaboration continue to spread across devices, locations, and time zones, a more robust notification system could make a significant difference to many of us. Here's how I began to orient myself around notification system design and all its parts--visible and not.
The most obvious building block of a notification center is the bell icon (thanks to social apps), the popover modal or even the full page where the notifications themselves live.
When looking at an individual notification, this is the short list of parts that we can expect it to have:
We think that the distinction between a social app notification system design and a notification system design for work tools is fundamentally different: engagement has nothing to do with it. In fact, the work software notification system is actively working to support the end user in sorting out the relevant information more efficiently in order to take action, while also seeking to ensure that fewer items fall between the cracks.
In order to think about email and push notification system design in a more structured way--and to identify their relevant actions--we've categorized them as follows:
When it comes to work, the majority of emails or any type of incoming message boils down to some type of a request.
This incoming message could be an email, an SMS alert system or text message via Slack (or other messaging apps), or notifications from social media.
These incoming communications can be accompanied by responses or a series of comments related to the request which are not part of the message thread itself, since the receiving party handles the request.
When an action is taken on a communication thread, employees often need to surface it to all users who have a stake in that particular thread. Each category of notifications will have a particular action as well as some global workflow actions, like the ability to unsubscribe from further notifications on that thread. .
Since workplace software and tools are an integral part of productivity and workflows, notifications around changes, improvements, or possible disruptions within this tool are incredibly important to the end user. However, only a few of them are relevant at the moment the user receives them. So, we've looked at ways that allow system notifications to be noticed while also giving the user maximum control over when they see them.
Account management notifications--administrator-driven changes--are relevant to the user account itself,as well as to other departments like billing. Similar to system notifications, many of these will be informative but will not require action, so they’ll rarely get to the top of the notification pile.
These are the messages about product updates, upgrades, and what's available for the user as their needs grow and change. These are the least relevant to the users' daily workflows, and our designs reflect this idea. The degree to which they choose to interact with these types of notifications will be entirely up to the user.
We've paid close attention to notification system design so that we’re providing the maximum amount of information possible while also enabling the end users to decide whether or not to act quickly.
Here's a bit more about the post-notification actions as they relate to the above notification types:
For example, long-form communication notification design would include a button that takes the user to the full notification itself, whereas a comment notification may allow the user to go straight into the chat to write back.
Additionally, all notifications which have an action would benefit from also having the ability to set reminder or snooze, set status, label, or delegation to a team member.
System, account management, & marketing
These types of notifications generally don't require any action, and are therefore not as important to user workflow. However, when an action is required, these notifications should make their way to the top.
So much of notification system design is not visible and often seems obvious only after the fact. However, igood notification design has the power of making a tool far more intuitive—as if it can anticipate the user’s actions. Here are the topics and considerations that have been on our minds so far:
A notification delivered at the wrong moment is an annoyance at best. In a notification system, how do we deliver the right notification at the right time to each user?
Syncing the notifications across devices as users increasingly go between desktop and mobile experiences at work is challenging.
This means that the transition between laptop, mobile, or tablet needs to happen without surprises or missteps. Additionally, notifications should be smart--when a user interacts with a comment that comes with a notification, the system should update the notification status to reflect actions in real-time.
There is a thin line between useful and annoying. We've opted for notification system design that reflects the ways we would want to deliver them---while also providing the user with enough flexibility to customize as many aspects as they need.
Despite the thinking invested in designing the best notification system, I still feel like we've only scratched the surface of what's possible--and what's needed. For example, we’re keeping push notifications and emergency notifications top of mind, as well.
As the amount of information we share at work gets bigger by the day, as employees increasingly move online, and teams continue to be distributed across geographies and times-zones, the need for robust, powerful, and reliable notification systems in work and productivity tools will only grow. I'm certain that our perspectives will evolve as we continue on our mission, although the fundamental vision for a unified notification system that more efficiently benefits users will remain.
Curious about the technical implementation? Read our article on building a notification system in Ruby on Rails.
Here are a few related articles!
This is the first part in a series of articles in which we'll design and implement a Notification System from scratch. We'll do this in Ruby on Rails, but the concepts are widely applicable to any web application framework. This part focus on the database design.
This article takes a look at how to integrate MagicBell's Notification Inbox into a web application that is built using the Angular framework. Angular is TypeScript-based and is one of the most popular single-page application (SPA) frameworks in the market today.