Keep Reading
If you enjoyed the post you just read, we have more to say!
Notification system design (shortened to NSD where possible for the sake of this article) is a complex topic. There is much to think about between transactional and marketing messages, multiple devices per user and regulatory compliance (think GDPR). In this article, we are going to highlight some of the most important aspects of NSD that we should think of when building one. Let's get started.
Rethinking Email Notification System Design
Can anyone else relate to the overwhelming number of email notifications in their inbox?
That's because email notifications are still the default notification service in workplace tools.
Our team uses the collaborative design platform Figma, and every time a comment is posted there, I receive an email notification 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 think more locally.
In other words, I need the right context 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 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. Another example is when I receive multiple notifications within a couple of minutes from the same document (without using bulk notification) - this means there is a chance you will miss important updates and more likely for you to be less engaged. There are endless examples of where some small customizations in these tools would make all the difference.
When MagicBell first brought me on to help design a notification system, I looked at what other 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 design and all its parts--visible and not.
The Bell & Notification Center Window
The most obvious building block of a web notification system 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:
- notification content
- a time stamp or time elapsed since it was received
- an icon or thumbnail to indicate who it's from (person image, brand logo etc.,)
- a visual status indication to immediately communicate whether it is unseen/seen, unread or read.
- a global action that can be taken on all notifications regardless of category: "set importance," "mark as new," "mark as read," "mute," "archive," "delete"
We think that the distinction between a social app NSD and the one 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:
Incoming request or message notification
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.
Notifications for action taken
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 and some global workflow actions, like the ability to unsubscribe from further notifications on that thread.
System notifications
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(user preference) over when they see them.
Account management notifications
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.
Marketing notifications
These messages are 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.
Acting on Notifications
We've paid close attention to NSD 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:
Communication notifications & actions
- view in context
- quick reply
- reminder ("at a scheduled time," "snooze," or even could include logic (" when _ happens, do __ ")
- delegate
- label (to organize)
- set status (to indicate action or communicate changes to team members)
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 delegate 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.
Notification system design - The invisible stuff
So much of NSD is not visible and often seems obvious only after the fact. However, good 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:
Timeliness: the right moment
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 across devices
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.
Powerful notification settings
There is a thin line between useful and annoying. We've opted for NSD 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.
Our work is not done
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.
I think it is only a matter of time before companies like Notion and Figma (to name just two) have to take engagement with notifications into a part of their net promoter scores. This will, in turn force them to think of efficiencies and customization to notifications as a primary feature.
Curious about the technical implementation? Read our article on building a notification system in Ruby on Rails. Or test our MagicBell playground.