How to Design a Notification System: Step-By-Step Manual With Examples

Today it’s hard to imagine a service without an integrated notification system. An attentive app notifies us that a friend liked our photo, long-awaited pizza delivery is coming, or a ride is waiting for us at our door.

Notifications are crucial for a work management system as they’re deeply integrated into the team workflow. These notifications serve to notify users of any changes in the tasks, call for completing their part of the job, and provide valuable hints.

Here I’ll share my experience with a systems approach to designing notifications. You’ll learn how to identify and account for all situations to make your product better for users and save your team’s resources.

Step 1: Specifying users involved in the process

Let’s walk through a typical day in a marketing agency: Antony, the art director, is pressed for time; the company is releasing a new product, so promo banners must be ready to launch by Friday. Designer Johnny has already done the job, but the mockups must be pre-approved by project managers before the job is accepted.

That’s why Antony sets the task for approval by Friday, with the following note: “Please approve banners for November Sale campaign.”

Now let’s describe the participants in more detail:

1. The Designer performs the job. The job may be completed, but they have to know if the mockups are accepted or rejected for corrections.
2. The Art Director accepts the job and sends it to the project manager for approval. They follow the approval votes and make tactical decisions on the fly.
3. Project Managers receive the job for approval. They need to understand what they have to review and how much time they have. Most importantly, they need to make decisions and be able to comment.

Next, let’s define in-system roles required to build a notification model:

1. Assignee: a person (persons) who is assigned to the task. The Assignee is defined in the Assignee field in the Task submenu.
2. Owner: a user who initiates the approval process.
3. Approver: one or more users set to approve the task.

The system often has covert roles that should be accounted for. If you want to send notifications on the status of a running process, it’s recommended to create a System Bot role to send notifications from the product.

⚡️ The list of roles should be as short as possible. The more complicated the role hierarchy is, the more difficult it is for users to understand.

Step 2: Building event/notification table

Frame building

Build a table to get a systemized view of all your notifications. The frame will comprise two parts:

Left column. All possible events during the approval process will be listed here broken down by roles. These events will trigger notifications. Not every role can actually take effect on the system. In our example, the Assignee is just an observer. Therefore, you may omit the Assignee from the left column, resulting in three sections:

1. Owner: Owner’s actions from the launch to the end of the approval process
2. Approver: Decision making and comments
3. System Bot: System status events

Top row. This row shows the roles that will receive notifications. Various channels are implemented, such as push notifications or text messages. For the sake of simplicity, let’s take a single communication channel: Incoming, or a personal notification feed:

1. Approver
2. Assignee
3. Owner

⚡️ The most convenient way to build a table is through Google Sheets. It offers an array of useful functions, including the option to share with your team and other teams that might need the table, i.e. User Support.

⚡️ Select the “Anyone with the link can comment” option when sharing. Your team can discuss the events by adding comments to the cells. Only you will be able to edit or delete the events.

Adding events

After you’ve made the frame, add all possible events available to users during approval to the left column. Analyze each interface state for every role and write down all actions available. Below are some tips for this stage:

1. The wording of the event should be as short as possible. If you start grouping right away, you may lose some of the simpler events, make the wording too complex, and sacrifice the clarity of the table.
2. Consider the logical model of the system. Results may differ for the same events depending on the context. For instance, if you remove the latest approver from an active process, not only will the approver be removed, but the approval will also be canceled.
3. Duplicate events are nothing to worry about. There may be duplicate events for specific roles. The owner or any user with similar rights, for example, can change the completion date. Yes, the table might be a little longer, but all available and all role-specific actions will be described.

Step 3: Defining principles for notification receivers

After adding the events, you should define role-specific conditions for receiving notifications. It will help you design notification lists relevant for each role without flooding the users with irrelevant information. Rely on the user interview data, research of similar products, and underlying conceptual solutions.

Our notification model is based on the following principles:

1. Owners receive notifications on the approvers’ decisions as well as on all changes to the process made by others.
2. Approvers receive notifications on the start of a new approval they’re added to, as well as on all significant changes to the process.
3. Assignees monitor the process. They receive notifications on the start and end of the approval and any decisions made.

⚡️ Write these principles for each role in the rows allocated for notification receivers. A good practice is to add them as comments. As the system gets more intricate, these principles will help you stay on track.

Step 4: Creating notifications

Now you can start creating notifications. Move in sequence from the event in the left column to each receiver role. Take care to do the following:

1. Try to reuse the wording to make notifications more consistent. If you’re working on an international product, it’ll make life easier for the localization team.
2. Highlight variables in the notification phrases, such as “USER: set approval due date to DATE,” so it’s more convenient for developers to work with your strings.
3. Remember the rules of good notifications: Keep them brief, include as much useful information as you can, keep the tone in line with your brand, and use the predefined principles of notification receivers. Set aside time to preview the length of strings in your product interface or mobile push notifications — some phrases may be hard to read or cut short with an ellipsis point.
4. Draw a line in the cells where no notifications are to be sent. If you have a long-term project, it’s easy to confuse the cells left blank to be filled later with the cells left blank intentionally. This will make it easier to understand for the team.

⚡️ It’s a good idea to use color coding. Add a legend for your color codes to the table header, e.g. black text — string draft, green text — string checked and ready, red text — implementation problems. For more information, use comments on the cell.

Step 5: Fine-tuning events

Now that you’ve filled all the cells, go back to your table and do the following:

1. Make all similar strings consistent with each other. Sometimes parts of a long list with a similar meaning have slightly different grammar, prepositions, or use synonymous verbs.
2. Add wording for bulk events, if possible, to reduce unique or one-time notifications, e.g. “USER: Added approval for N files.”
3. Add new, unique strings to replace a group of consecutive events, e.g. substitute removing approvers and adding other approvers with “Replaced APPROVER with APPROVER.”
4. Discuss all notifications with the development team. Some of your ideas might be impossible to implement due to architectural restrictions, even if they look logical. Show your drafts to your backend developer as early as possible to save time for later development stages.

Conclusion

With systems approach and clearly defined principles, even the most complex scenarios will be easy to understand and accessible to developers. A well-designed notification table will help designers make the product more intuitive and user-friendly, and also help the team focus on implementation without sacrificing time and effort to understand all its details.

Tips for working with the table:

1. Use a separate page for each scenario, so that it’s easier to find your way around the table.
2. Make a presentation for the development team. Explain the logic and underlying principles. Answer their questions and make sure that everyone is on the same page.
3. If other designers work with notifications on your product, share this approach and the table with them. All events will be in the same place, and everyone will get the big picture.