So, you want to design a notification system?

Possible ways of notifying a user

Notifications come in so many flavors, yet we can categorize them as follows:

Push notifications (usually modal popups on screen, or an item in the notification panel of your phone), may be a notification in your action center/notification center on your PC coming from:

• Your own application environment (desktop app, mobile app or web browser).
• Twitter
• Skype
• Slack
• MS Teams
• Facebook
• <insert your social network/chat application echo system here>
• SMS
• Email

And the list might go on depending on your business requirements, scenarios and the types of your users.

However, one can suggest categorizing types of notifications under two possible categories:

• A notification that requires an action (some might call it “call for action” notifications)
• An informal notification that requires no action from the user (as in informing the user about system or organizational related events). 

Bringing order to chaos

Keeping notifications in one place is important, such that users can refer to that single place whenever needed and more importantly, categorizing and sorting them. Imagine all the clutter when many types of notifications arrive at the notification center, competing for users’ attention. Sorting, color coding and icons can help mitigate that problem (e.g. sort notifications by importance or relevance in descending order, where the most important notifications are at the top and the least important is at the bottom of the list or stack). Moreover, it’s important to allow your users to subscribe/unsubscribe to/from the source(s) of notification(s).

When to use which?

This is a very important question, which the majority of us could have subjective or objective opinions based on statistical data or other formal methods, yet we could probably agree on some common points (kindly note, these are merely suggestions and/or pointers rather than strict guidelines):

   - Emails

The more you spawn them, the more they get overlooked and eventually become spam. I personally look at email communication as a medium to formalize and keep records of important events and/or decisions (e.g. think about the 5min corridor talks about important matters, or 15 min standups where you brainstorm an idea and you would like to formalize it and give it some manageable organized form, this is where emails in general might come in handy). Of course, emails could be used as a tool for booking events (e.g. outlook meeting invitations, hangouts invitation events, etc…), or a permanent notification. To recap, emails are powerful, use them wisely and don’t abuse their power, or they become a spam. Try to reduce noise and utilize push notification channels more.

   - Push notifications

Push notifications are awesome, especially if you incorporate them in your own frameworks or systems for people on the field (i.e. those who are not sitting at their desks 8hrs a day). You might need to be quick and concise with your notifications. Once a person glances at their lock screen they can see the source of the notification and at least the first sentence which clearly states what it’s about. Moreover, it’s important when do you send your notifications (just imagine when a push notification kicks in while your user is sleeping at night), hence depending on the priority of the notification, it is probably a good idea to take timing and time zone calculations into consideration.

Another type of push notifications would be a discoverability feature, in case you did an upgrade and would like to notify your users about the new shiny features you added to your software, push notifications are a good tool for that.

Keep in mind that push notifications are not meant to be kept forever, that’s what emails are for, if you have something you would like to persist, then emails are your best pick (more on that in another discussion about architecting the notification system).

   - SMS

Now at the age of social media and free text communication services, SMS offers the only thing which other types of notifications can’t offer, if you are completely off the internet grid and/or you really need to reach that specific user or for the two-factor authorization, this is probably your best choice.

Notification persistence

Depending on the kind of system you have, eventually, users of your system might get back to their notification(s) sooner or later. However, because we get a lot of them, storing them forever on a server is surely not cheap. What you could do, is store the notification simultaneously in 2 databases, one which users can refer to and have immediate access, then probably 3 days later you can erase it from the main database, and keep the back-up for whenever the user would like to refer to that archive of notifications. Later you could delete those notifications after a certain period of time (in about 20~30 days).

Targeting and fanout effect

Your notifications should target the correct users, otherwise it would just be an unnecessary distraction. Furthermore, in an enterprise, notifications sometimes yield a fanout effect (i.e. when many subscribers are subscribed to a specific subject, there is big “foreach loop” for pushing these notifications instantly). Moreover, notifications are spiky, at a certain time of the day if a CEO of a company pushes a notification inside an organization with thousands of employees, there is going to surely be a spike in your servers where these notifications have to be pushed instantly to its targeted employees, therefore load balancing is surely required to keep the notification system working in such situations. Here is a slide from Gary Lam and Saurabh Pathak talk about the spiky nature of notifications when an event occurs in twitter (link of the complete talk is in the references below):

Figure 1 Real-Time & Personalized Notifications @Twitter talk by Gary Lam and Saurabh Pathak

With such spiky nature, sticking clients to a single push server might yield time performance problems. These performance questions that could arise in production requires you (from the very beginning) to think about implementing telemetry and diagnostics support within your notification system, such that you can have early warnings in case you could run into performance problems so you could handle them on time. Furthermore, scaling your notification system on demand is an important feature, such that you could minimize or mitigate service downtimes (i.e. allow some room for your system to breath in case of sudden spikes), which we are going to discuss in detail throughout this series.

If you are interested in the statistics and timing of pushing a notification, this article has a comprehensive survey about the types of push notifications and their effects on users.

Don’t be shy, make some noise

This is probably one of the most overlooked points in making notifications. Engineers and system architects are mostly busy talking about architectural challenges, performance challenges and customer interaction and retention strategies, yet very few are discussing sounds. The ability to grab the users’ attention for urgent notifications when they are completely away from their devices, and the most common way is to trigger other sensory organs like hearing and sight (I’m talk about notification LEDs). Choosing the right sound of the notification is really important, it has to deliver the feel of the type of the notification and shouldn’t be annoying. Striking this Goldie lock zone requires research, experimenting and clever user surveys while developing your system. Of course, it’s worth mentioning that you need to give the ability to mute your notifications, as users might have other notification sounds competing for their attention, it may as well define your brand.

There are very interesting articles talking about the nature of sound (https://waitbutwhy.com/2016/03/sound.html) and designing notification sounds (https://www.futurice.com/blog/designing-notification-sounds/) that are worth reading.

In the next blog post, I’m going to discuss how we could approach some of the points mentioned above and architect a system that is scalable and can handle such requirements.

Further reading and recommended videos:
https://observer.com/2019/05/app-sounds-notifications-design/
https://www.toptal.com/designers/ux/ux-sounds-guide
https://uxdesign.cc/designing-with-sounds-98a4003e2133
https://www.youtube.com/watch?v=6w6E_B55p0E&t=2373s
https://www.youtube.com/watch?v=pme_n2zQiDQ&t=2715s
https://www.youtube.com/watch?v=YWk__39JkIE