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). A robust notification system must support multiple notification types, such as transactional, promotional, and system-generated alerts, to address diverse user and business needs. 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, 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. A dedicated bulk notification UI, integrated with a bulk notification service, allows users to select filters and compose messages to efficiently send bulk alerts to targeted user groups. This approach helps reduce notification overload and ensures important updates reach the right audience, improving overall engagement. 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"
A notification bell and pop-up modal
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. Each of these communications is processed as a notification request, which is then formatted into a notification message and delivered through channels such as email, SMS, or push.
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, push 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.
Components of Notification Systems
A robust notification system is made up of several interconnected components, each playing a vital role in ensuring that users receive timely, relevant notifications across all their preferred channels. Let’s break down the essential building blocks that power a scalable notification service and support major notification channels like push notifications, in app notifications, SMS, and email.
1. Notification ServiceAt the heart of every notification system is the notification service. This core component is responsible for processing incoming notification requests, validating user preferences, and orchestrating the delivery of notifications. Whether it’s a transactional alert or a promotional message, the notification service ensures that each notification is handled efficiently and routed correctly. 2. User Preferences ServicePersonalization is key to delivering relevant notifications. The user preferences service stores and retrieves each user’s notification preferences—such as preferred channels (email, push, SMS), frequency, and notification types. By fetching user preferences before sending notifications, the system respects the user’s choices and avoids notification fatigue. 3. Notification GatewayThe notification gateway acts as the entry point for all notification requests. It receives requests from business services and forwards them to the appropriate channel services, ensuring that each notification reaches the right delivery path, whether it’s for ios push notifications, android push notifications, or SMS. 4. Channel ServicesChannel services are specialized components that communicate with external delivery channels. For example, they integrate with Apple Push Notification Service (APNs) for iOS push notifications, Firebase Cloud Messaging (FCM) for Android push notifications, and third-party SMS services for SMS notifications. These services handle the specifics of each channel, ensuring smooth notification delivery. 5. Message QueueTo handle high volumes and ensure reliability, notification systems use message queues. A message queue temporarily stores notification requests, allowing for asynchronous processing. This means that even if a downstream service is slow or temporarily unavailable, notifications aren’t lost—they’re simply queued for later delivery. 6. Notification HandlerThe notification handler is responsible for processing each notification, fetching user preferences, and determining the best delivery channel based on the user’s settings and the notification type. This ensures that notifications are sent in the most effective way for each user. 7. Notification TrackerVisibility into notification delivery is crucial. The notification tracker logs the delivery status of each notification, providing valuable insights into which notifications were delivered, which failed, and why. This data helps teams monitor notification effectiveness and quickly identify issues. 8. Retry MechanismSometimes, notification delivery fails due to network issues or external service downtime. A robust retry mechanism automatically attempts to resend failed notifications, often using exponential backoff to avoid overwhelming external services. This ensures at least once delivery and improves the reliability of the notification system. 9. Notification Template RepositoryConsistency and personalization are made easy with a notification template repository. This component stores pre-defined templates for different notification types, allowing teams to quickly customize notification content and maintain a consistent user experience across all channels. 10. Scheduled NotificationsNot all notifications need to be sent immediately. The scheduled notifications component manages notifications that should be delivered at a specific time, supporting use cases like reminders, scheduled alerts, or time-sensitive promotional messages.
These components work together to create a scalable notification system that covers all major notification channels and supports both functional and non-functional requirements. In a typical push notification system, business services send notification requests to the notification service, which processes them, fetches user preferences, and forwards them through the notification gateway to the appropriate channel services. Channel services communicate with external delivery channels to send push notifications, in app notifications, SMS notifications, or emails. The notification tracker logs delivery status, while retry mechanisms ensure that notification delivery is reliable, even when failures occur.
To achieve high availability and scalability, consider the following best practices:
- Scalable Notification Service: Design your notification service to handle large volumes of notification requests without performance bottlenecks.
- Load Balancing: Use load balancing to distribute traffic across multiple instances of your notification service, ensuring smooth operation during peak times.
- Caching: Cache frequently accessed data, such as user preferences, to reduce database load and speed up notification processing.
- Message Queues: Employ message queues to buffer notification requests, providing resilience against temporary failures and supporting bulk notifications.
- Retry Mechanisms: Implement robust retry mechanisms to handle notification delivery failures, ensuring that all the notifications eventually reach their intended recipients.
By understanding and implementing these components, you can build a notification system that not only delivers timely and relevant notifications but also scales with your application’s growth and meets the evolving needs of your users. Whether you’re sending transactional alerts, promotional notifications, or in app notifications, a well-architected notification system ensures your users stay informed and engaged—without being overwhelmed.
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.
A robust notification system must implement rate limiting and enforce rate limits to control the number of notifications per user and per system, preventing overload and ensuring a good user experience. Rate limit mechanisms are essential for managing the volume of notifications per second or per minute, especially during peak loads, to guarantee timely delivery. The system should be designed to support sending notifications at scale, with the ability to trigger notifications in response to user or system events, and to send notifications reliably across multiple channels even under high demand.
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. Delivering notifications in a timely and reliable manner requires robust message queuing, retries, and monitoring to ensure users receive important updates when they matter most. 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 and user's notification preferences
There is a thin line between useful and annoying. Our notification system is designed to efficiently access and respect each user's notification preferences, allowing users to manage their preferences for receiving notifications across different channels. This ensures that notifications are delivered according to the user's preferences, including opt-in and opt-out choices, frequency limits, and scheduling, for a personalized experience. 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
To support this vision, our notification system collects and analyzes notification data to provide business intelligence on notification volume, types, and performance. We maintain detailed notification logs for auditing, troubleshooting, and tracking delivery outcomes. Low priority messages are processed separately to ensure urgent notifications are delivered promptly, while less critical messages can tolerate some delay. Failed message deliveries are routed to a dead letter queue, allowing for manual review or reprocessing without disrupting the main workflow. A notification validator checks and prioritizes messages, routing them to appropriate channels based on urgency. The system leverages user id to personalize notifications, and integrates with user service and user preference service to fetch user information and preferences, ensuring compliance with opt-in/opt-out choices and preferred channels. Our sms service interacts with multiple SMS vendors to deliver messages reliably across regions.
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.