Before building a notification system, best know the requirements of your developers and non-technical teammates who will create the notifications for end-users.
Join the DZone community and get the full member experience. So your CTO has just handed you a project to revamp or build your product’s notification system. It seemed like a simple and straightforward project, but you started doing research and realized that not only is the process pretty complicated, there’s not a lot of information online on how to do it. After all, companies like LinkedIn, Uber, and Slack have large teams of over 25 employees working just on notifications. But smaller companies don’t have that luxury – so how can you meet the same level of quality with a team of one? This can certainly be overwhelming, which is why we’ve created a blog post series to guide you through building the best notification system for your company. This is the first post in this series, and we’re introducing you to the essential user requirements for both developers and non-technical users of your notification system. It’s crucial that before building a notification system, you should know the requirements for your fellow developers and non-technical teammates who will be creating the notifications for your end-users. Understanding these teammates’ personas will help you to build a more effective product with a better user experience. A notification system is a collection of services (templates, provider integrations, routing logic, preferences, logging, etc.) that make it possible to quickly and easily create clear and direct communication between an app and its users. This clarity of communication generally involves a myriad of channels, including email, SMS, push notifications, etc. that allow the app to reach each user with the best possible user experience. A well-built notification system removes complexity from the process of creating each notification, which allows for a consistent experience across products and teams. This also provides a centralized hub for notifications across the organization, thus making monitoring and analytics more accessible. Depending on your company’s product, a notification system can work with different use cases. You can use a central notification system to alert your end-users about an incoming request, send messages about actions taken, inform end-users about product updates and upgrades or promotions, or even deploy account management notifications. A developer needs to understand the framework of the notification system so they can integrate it into other parts of the application or software. They are the ones who end up wiring up notifications for the myriad of applicable use cases, so it’s important to build the system with them in mind. Reliability makes it possible to avoid dropped messages. Even if many messages are coming in simultaneously or the system is at peak load, message delivery should be guaranteed. While there could be delays at peak load, you should be confident you aren’t losing messages. The system should also retry failed message deliveries by sending messages reliably over the network and try again if a message fails. An organization will need to send varying volumes of notifications at various times, so the developer using the API will not need to bother with auto-scaling the infrastructure. For example, an organization needs to send plenty of notifications when it has flash sales. At other times, during low-volume periods, it will need to send fewer notifications. The system should be able to scale up and down resource-efficiently as the volume of notifications changes and as an organization grows. In the absence of a central notification system, inconsistency among channels like SMS, email, or push notifications are likely to become an issue whether among fellow developers, customer success, marketing, etc. You can change the notification channel provider, whether AWS SES or Twilio for emails, in the notification service without changing the application code in any other products. Thus, the notification channels and providers will be abstracted and centralized instead of having the code sprinkled all over the application codebase. So if your company stops doing business with a particular provider, it can switch to a new provider in a few hours without impacting any other part of the notification service. The uniform interface makes development simpler for each product and team by abstracting the different notification providers (email, push, SMS, etc.) so the developer can easily switch between different providers without rewriting the code. For other developers to use your notification system, you have to provide good documentation to understand how to use it. Internal documentation is an integral part of any system, as it educates and helps users to reference and know how to use your product. When building a platform for other developers, you have to provide great documentation so that they have the tools to figure out any support-related issues. Good documentation for a notification system should be an easy guide to help them get started.
