How to Design a Notification System : A Slack Case Study (PM Guide)

A practical Product Management guide to notification rules, priorities, user preferences, exceptions, delivery channels and edge cases

Notifications look like a small Product feature.

A new event happens. The system sends a message. The user opens it.

Simple.

But once a Product has different users, roles, devices, preferences, message types and urgency levels, notifications become a decision system.

Consider a messaging Product such as Slack.

Before sending one notification, the system may need to know:

• Is the channel muted?
• Is the user subscribed to the thread?
• Is Do Not Disturb active?
• Can this message override Do Not Disturb?
• Is it a direct message?
• Does it contain a direct mention?
• Does it contain @channel, @everyone or @here?
• Does it contain a highlighted keyword?
• What is the user’s preference for this channel?
• What is the user’s global notification preference?
• Is the user currently active?
• Has the message already been seen on desktop?
• Is the notification being sent to desktop or mobile?
• Has the mobile notification delay passed?

Every rule sounds manageable individually.

A channel may be muted, but the user may be directly mentioned. The user may be subscribed to a thread, but Do Not Disturb may be active. A mobile notification may qualify, but the message may have already been read on desktop.

The Product challenge is therefore not just deciding when to send notifications.

It is defining:

• which rule is checked first,
• which rule overrides another,
• which exceptions are allowed,
• what happens when a preference is missing,
• how duplicate notifications are prevented,
• what the user sees,
• and how the team tests every important combination.

The Slack flowchart is valuable because it converts the vague requirement “send the right notification” into a concrete decision model with inputs, conditions, branches and final outcomes.

The central question behind every notification system

Before designing settings, notification cards or email templates, define the exact decision that the system needs to make.

For Slack, the question is not simply:

Should we send a notification?

A more complete version is:

Should this specific user receive a notification for this specific message on this specific device at this specific time?

That single sentence identifies five important dimensions:

1. User: Who may receive the notification?
2. Event: What happened?
3. Context: Where did it happen?
4. Channel or device: Where should the notification be delivered?
5. Time: Should it be sent immediately, delayed or suppressed?

A notification system should answer this question predictably for every important event.

Part 1: Start with the notification’s purpose

The first mistake Product teams make is starting with the interface:

• Add a notification bell.
• Add email preferences.
• Add push notifications.
• Add a “Mark all as read” button.

These are interface decisions.

They do not explain why the Product needs notifications.

Start with the user problem.

A notification may serve one of four purposes.

1. Inform the user

The user needs awareness, but no immediate action is required.

Example:

Your monthly report is ready.

2. Request an action

The workflow cannot continue without the user.

Example:

Your quotation is ready for approval.

3. Warn the user

Something may negatively affect the user or their work.

Example:

Payment failed. Update your payment method to continue.

4. Confirm an action

The system acknowledges that something has been completed.

Example:

Your document was uploaded successfully.

These notification types should not be treated equally.

A confirmation can remain inside the Product. A blocking action may require an in-app notification, email and persistent dashboard banner. A security incident may require immediate delivery regardless of normal notification preferences.

Before designing any logic, define the notification’s job.

Part 2: Create an event inventory

A notification begins with an event.

The event should describe what changed in the Product.

Examples from a collaboration Product might include:

• New direct message received
• User mentioned in a message
• Thread reply received
• Channel announcement posted
• Keyword detected
• User invited to a workspace

Examples from an enterprise SaaS Product might include:

• Quotation generated
• Quotation approved
• Payment failed
• Purchase order required
• Quality issue confirmed
• Corrective action uploaded
• Dispatch delayed
• Delivery completed
• Invoice generated

Do not write events as vague topics such as:

• “Payment notification”
• “Quality notification”
• “Project update”

Write them as actual changes:

• Payment moved from processing to failed
• Quality issue moved from internal review to customer-visible
• Delivery date changed from 12 August to 15 August

This makes the system easier to design, build and test.

A practical event inventory

For every event, document:

This event inventory becomes the foundation of the notification system.

Part 3: Identify all inputs before drawing the flow

The Slack flowchart works because it considers several different types of inputs.

These inputs should not be mixed together.

1. User preferences

What the user explicitly configured.

Examples:

• Notify me about all messages
• Notify me about mentions only
• Mute this channel
• Disable email updates
• Enable mobile push notifications

2. Preference values

The selected value inside a setting.

Examples:

• Everything
• Mentions
• Nothing
• Default
• Never

3. User state

What is true about the user at that moment.

Examples:

• User is active
• User is offline
• User is in Do Not Disturb
• User is using mobile
• User has already seen the message on desktop

4. User action

What the user has previously done.

Examples:

• Subscribed to a thread
• Muted a channel
• Followed a project
• Acknowledged an issue
• Approved a quotation

5. Event content

What the event contains.

Examples:

• Direct mention
• Group mention
• Highlighted keyword
• Direct message
• Critical error
• Required approval

6. Business rules

Rules defined by the Product or organisation.

Examples:

• Security alerts cannot be disabled
• Only project administrators receive payment alerts
• Internal quality observations are not shown to customers
• A user must have project access before receiving project notifications

7. Delivery context

Where and when the notification may be delivered.

Examples:

• Desktop
• Mobile
• Email
• SMS
• User’s time zone
• Mobile push delay
• Quiet hours

When these categories are separated, ownership becomes clearer.

Product defines intended behaviour. Engineering identifies available data. Design explains the behaviour. QA tests the combinations.

Part 4: Define notification priority

Not all events deserve the same urgency.

A useful notification system needs a priority model.

Priority 1: Critical

The user may experience financial, security, compliance or operational harm if they miss the message.

Examples:

• Account security incident
• Payment failure blocking service
• Critical quality issue requiring immediate approval
• Delivery exception affecting a deadline

Possible delivery:

• Persistent in-app banner
• Email
• Mobile push
• SMS for exceptional cases

Priority 2: Action required

The user must complete something for the workflow to continue.

Examples:

• Approve quotation
• Upload purchase order
• Review corrective action
• Confirm dispatch

Possible delivery:

• In-app notification
• Dashboard action
• Email
• Reminder if not completed

Priority 3: Important update

The user should know, but does not need to act immediately.

Examples:

• Project moved to production
• Document approved
• Delivery date updated

Possible delivery:

• In-app notification
• Email digest
• Optional mobile notification

Priority 4: Informational

Useful context that should not interrupt the user.

Examples:

• Team member added a comment
• Report generated
• Project metadata updated

Possible delivery:

• Activity feed
• Notification centre
• Daily or weekly digest

The priority should influence:

• delivery channel,
• timing,
• persistence,
• visual treatment,
• reminder behaviour,
• and whether user preferences can suppress the message.

Part 5: Define rule precedence

Rule precedence is the most important part of a complex notification system.

Imagine the following conditions:

• The channel is muted.
• The user is directly mentioned.
• Do Not Disturb is active.
• Direct mentions normally override mute.
• DND normally suppresses notifications.
• A critical override is available.

Which rule wins?

Without explicit precedence, different engineers may implement different interpretations.

A practical precedence model could be:

1. Security, privacy and legal restrictions

These rules should be evaluated first.

Examples:

• Do not send confidential project information to unauthorised users.
• Do not expose an internal quality issue to a customer.
• Do not include sensitive information in an email preview.

2. Recipient eligibility

Determine whether the user is a valid recipient.

Questions:

• Does the user belong to the workspace?
• Does the user have access to the project?
• Is the user’s role relevant to the event?
• Is the user still active?

3. Mandatory business notifications

Some messages may not be disabled.

Examples:

• Security alerts
• Legal notices
• Payment failures
• Critical service disruptions

These exceptions must be clearly communicated to the user.

4. User interruption state

Evaluate:

• Do Not Disturb
• Quiet hours
• Vacation mode
• Temporary notification pause

5. Specific preferences

Evaluate the most specific relevant preference.

For example:

• Thread preference
• Channel preference
• Project preference
• Event category preference

6. General preferences

Use global preferences when no specific preference exists.

7. Message or event type

Evaluate:

• Direct message
• Mention
• Group mention
• Keyword
• General update

8. Presence and duplication

Check whether:

• the user is active,
• the event has already been seen,
• another channel already delivered it,
• the same notification has already been sent.

9. Device and timing rules

Finally, determine:

• desktop,
• mobile,
• email,
• delay,
• digest,
• or suppression.

The exact order can change between Products. What matters is that the order is deliberate and documented.

Part 6: Understand global and specific preferences

Slack’s model contains multiple layers of notification preferences:

• global settings,
• channel settings,
• thread subscription,
• DND,
• device specific behaviour.

This introduces both scope and inheritance.

Consider this example:

• Global preference: Mentions only
• Channel preference: All messages
• Thread preference: Subscribed
• DND: Active

The system must decide which setting overrides which.

A common Product principle is:

The more specific preference overrides the more general preference, unless a higher priority restriction or mandatory rule applies.

For example:

1. Security restriction
2. DND
3. Thread subscription
4. Channel preference
5. Global preference
6. Default behaviour

But even that hierarchy needs exceptions.

Should a direct mention override a muted channel?

Should a critical alert override DND?

Should thread subscription override channel mute?

There is no universal answer. These are Product policy decisions.

Document each setting properly

For every preference, define:

A setting without this information is incomplete.

Part 7: Treat defaults as intentional Product decisions

“Default” is not the absence of a decision.

It usually means:

Inherit behaviour from another level.

In a messaging product like Slack, users may have notification settings at multiple levels: global, workspace, channel, thread and device. A more specific setting may override a broader one, while “Default” usually means the Product should inherit behaviour from the next broader level.

For example:

• A channel inherits the user’s global notification preference.
• A thread follows the channel preference unless the user subscribes to it.
• A new workspace begins with the user’s existing notification settings.
• A mobile device follows the user’s general mobile notification preference.

Most users will not manually configure every option.

That means the default often becomes the real experience for most users.

A PM should define:

• What happens for a new user?
• What happens when the user joins a new workspace?
• What happens when a new channel is created?
• What happens when a preference has never been selected?
• Does a channel continue following the global preference when that global preference changes?
• Can the user see that a preference is inherited?
• Can the user reset a customised preference back to Default?
• What happens when the Product introduces a new notification type?

Bad defaults can create notification fatigue and push users to disable notifications completely.

Defaults that are too restrictive can also cause users to miss important messages.

A useful default should balance relevance, user control and the risk of missing important information.

Part 8: Design Do Not Disturb and override rules carefully

Do Not Disturb looks simple:

Do not send notifications during this period.

But a real Product must answer:

• Does DND suppress everything?
• Are security alerts still delivered?
• Can administrators override DND?
• Can direct messages override it?
• Are messages delayed or permanently skipped?
• What happens when DND ends?
• Should the user receive a summary?
• Does DND apply to email as well as mobile push?

A practical DND model may include:

Suppress

The notification is not delivered.

Appropriate for low value informational events.

Delay

The notification is delivered when DND ends.

Appropriate for important but non-urgent updates.

Override

The notification is delivered immediately.

Appropriate only for clearly defined critical events.

The user should understand these exceptions.

Example microcopy:

Notifications are paused until 8:00 AM. Critical security and payment alerts may still be delivered.

Without this explanation, correct system behaviour may still feel unpredictable.

Part 9: Handle presence and multiple devices

Multi device delivery creates another layer of complexity.

A user may have:

• the desktop application open,
• a browser session active,
• a mobile device connected,
• email notifications enabled.

Sending the same notification everywhere can create unnecessary interruption.

Slack’s flowchart includes user presence and mobile timing because the system may need to avoid sending a mobile push immediately when the user is already active on desktop.

A practical multi device policy might be:

1. If the user is active on desktop, show the notification on desktop.
2. Wait for a defined mobile threshold.
3. If the event remains unread, send a mobile push.
4. If the user reads the event before the threshold, cancel the mobile push.
5. Send email only if the event remains unresolved or unread for longer.

This requires Engineering to track:

• event creation time,
• delivery time,
• read status,
• active sessions,
• device tokens,
• notification cancellation,
• and deduplication state.

From a PM perspective, the important question is:

What behaviour creates the right level of awareness without repeatedly interrupting the user?

Part 10: Design the notification as an actionable object

A notification is not just text.

It should help the user understand and respond.

Every useful notification should answer:

1. What happened?
2. Where did it happen?
3. Why does it matter?
4. Do I need to act?
5. What happens when I click?
6. When does this become irrelevant?

Weak notification

Project updated.

This gives the user no useful information.

Better notification

Delivery date updated

Project Alpha is now expected on 15 August, three days later than originally planned.

Actionable notification

Delivery approval required

Project Alpha is ready for dispatch. Review the shipment details and approve dispatch by 4:00 PM tomorrow.

Action: Review dispatch

The notification should lead directly to the relevant object or action.

Do not send users to a general dashboard and expect them to search for the reason they were notified.

Part 11: Separate notification logic from notification presentation

A complex flowchart should not become a complex interface.

Slack users do not need to see every rule in the decision model. They may only need understandable controls such as:

• All messages
• Mentions
• Nothing
• Mute channel
• Notify me about thread replies

The system handles the underlying logic.

This is an important Product principle:

Internal complexity should be absorbed by the system, not transferred to the user.

The interface should expose only the settings users can understand and meaningfully control.

However, simplification must not hide important consequences.

Suppose a user mutes a channel but remains subscribed to a thread. If thread replies can still produce notifications, the interface should explain that.

Example:

You may still receive notifications for direct mentions and subscribed threads.

In an enterprise Product, the same principle applies.

Example:

Routine project updates are disabled. Critical payment, quality, delivery and security alerts will still be sent.

The user does not need the complete decision model. They need to understand the exceptions that affect their expectations.

Part 12: Convert the flowchart into a decision table

Large flowcharts are useful for understanding sequence.

Decision tables are often better for checking combinations.

Here is a simplified Slack style example:

This table forces the team to define ambiguous outcomes.

“Apply policy” should eventually be replaced with an explicit result before development begins.

For example:

• Notify
• Do not notify
• Delay
• Send in-app only
• Send mobile push
• Add to digest

Part 13: A practical enterprise notification example

Consider a B2B project platform.

The system needs to notify customers about quality issues.

The initial requirement might be:

Notify the customer when a quality issue occurs.

This is not sufficient.

The PM should first define the decision:

Should this customer receive a notification about this quality issue right now?

Inputs

• Is the issue confirmed?
• Is it internal or customer-visible?
• Does it affect the customer’s order?
• Is customer action required?
• Is evidence ready?
• Does the issue contain sensitive supplier information?
• Is the issue open, closed or reopened?
• Does the recipient have project access?
• Has the recipient already acknowledged it?

Possible outcomes

• No customer notification
• Internal notification only
• Customer information notification
• Customer action-required notification
• Delayed notification until evidence is ready
• Reopened issue notification

Decision table

This is more useful than writing:

Customers should receive notifications for relevant quality issues.

Part 14: Decide which notification channel to use

A notification system should not send every event through every channel.

Each channel has a different purpose.

In-app notification centre

Best for:

• Product updates
• History
• Non-urgent information
• Items that can be revisited

Limitations:

• The user must open the Product.

Persistent action banner

Best for:

• Blocking actions
• Critical project states
• Tasks that remain unresolved

Limitations:

• Too many banners reduce their importance.

Email

Best for:

• Important updates
• Longer context
• Users who are not constantly inside the Product
• Records that may need forwarding

Limitations:

• Email can be delayed or ignored.

Mobile push

Best for:

• Time-sensitive events
• Short, actionable updates
• Users working away from desktop

Limitations:

• Highly interruptive
• Limited context

SMS

Best for:

• Exceptional critical cases
• Authentication
• Severe operational incidents

Limitations:

• Costly
• Highly intrusive
• Limited formatting

Digest

Best for:

• Low priority activity
• Repeated updates
• Summary based consumption

Limitations:

• Not appropriate for urgent actions

A channel matrix helps:

Part 15: Define deduplication and grouping

Notification fatigue often comes from repetition, not from one bad message.

Imagine ten people reply to the same Slack thread within five minutes.

Should the user receive ten notifications?

A better approach may be:

Five people replied to a thread you follow.

Possible grouping dimensions include:

• the same thread or conversation,
• the same event type,
• the same channel,
• the same actor,
• the same time window.

The PM should define:

• Which notifications can be grouped?
• How long should the grouping window remain open?
• When should a new event update an existing notification?
• Does the unread count increase once or for every event?
• What happens when one event is more important than the others?
• Should direct mentions remain separate?
• Does opening the grouped notification mark every event as read?
• What happens when the user has already viewed some of the grouped activity?

Grouping combines several related events into one notification.

Deduplication solves a different problem. It prevents the exact same event from being delivered more than once because of retries, duplicate processing or delivery failures.

Deduplication keys

Engineering may use a key such as:

recipient + event type + object + time window

For example:

recipient: user 381 + event: thread reply + object: thread 923 + grouping window: five minutes

The technical implementation belongs to Engineering, but Product must define the expected user experience:

• Should the user see one notification or several?
• Should the notification update as new replies arrive?
• Should direct mentions appear separately?
• When should the grouping window close?
• What information must remain visible?

Product defines what the user should experience. Engineering decides how the system reliably produces that behaviour.

Part 16: Define notification lifecycle states

Notifications have their own lifecycle.

A useful model may include:

• Created
• Eligible
• Suppressed
• Scheduled
• Delivered
• Failed
• Seen
• Read
• Acted upon
• Expired
• Cancelled

These states help answer operational questions:

• Was the notification generated?
• Was the user eligible?
• Was it blocked by DND?
• Was it successfully delivered?
• Did the user read it?
• Did the user complete the action?
• Did the event become irrelevant before delivery?

This is especially important for action-required notifications.

For example, if a quotation is approved before a scheduled reminder is sent, the reminder should be cancelled.

Part 17: Convert every important branch into a test case

The notification flowchart is useful for QA because every meaningful path can become a test.

Instead of saying:

Test the notification system.

Provide expected behaviour.

Combination based testing is essential because complex systems often fail when two individually correct rules interact.

The mute logic may work correctly.

The thread subscription logic may also work correctly.

But mute plus thread subscription may behave incorrectly.

The intersection is where many Product defects appear.

Part 18: Measure notification quality

Sending more notifications is not necessarily success.

A good notification system helps users notice and act on relevant information without creating unnecessary interruption.

Useful metrics include:

Delivery metrics

• Delivery success rate
• Push failure rate
• Email bounce rate
• Delivery latency
• Suppression rate
• Duplicate notification rate

Engagement metrics

• Open rate
• Click through rate
• Read rate
• Time to open
• Time to complete the requested action

Quality metrics

• Notification disable rate
• Channel mute rate
• Unsubscribe rate
• DND usage
• Support complaints
• “Not relevant” feedback
• Critical notifications missed

Product outcome metrics

For action based notifications:

• Approval completion rate
• Payment recovery rate
• Issue acknowledgement time
• Document upload completion
• Reduction in workflow delays

The best metric depends on the notification’s purpose.

A payment failure alert should be measured by successful payment recovery, not only by open rate.

Part 19: Assign clear ownership

A notification system should be designed collaboratively.

Product owns

• user need,
• event taxonomy,
• notification purpose,
• priority,
• business rules,
• precedence,
• expected outcomes,
• important exceptions,
• success metrics.

Design owns

• notification presentation,
• information hierarchy,
• action clarity,
• preference settings,
• explanation of exceptions,
• accessibility,
• empty and error states.

Engineering owns

• event generation,
• delivery architecture,
• data availability,
• retries,
• deduplication,
• scheduling,
• device handling,
• performance and reliability.

QA owns

• branch coverage,
• combination testing,
• failure scenarios,
• boundary conditions,
• regression coverage.

Security and legal may own

• sensitive data rules,
• mandatory messages,
• consent,
• retention,
• compliance requirements.

The PM does not need to independently specify every technical detail.

But the PM should ensure that Product behaviour is coherent and that the team agrees on the expected outcome.

Part 20: Common notification design mistakes

Mistake 1: Sending every update

Not every event deserves a notification.

Some events belong only in the activity log.

Mistake 2: Treating all notifications equally

A comment and a payment failure should not receive the same urgency.

Mistake 3: Starting with channels

“Should we send email or push?” comes after deciding whether the user should be notified at all.

Mistake 4: Ignoring precedence

Without rule ordering, conflicting settings produce inconsistent behaviour.

Mistake 5: Hiding exceptions

Users lose trust when a muted or disabled notification still appears without explanation.

Mistake 6: Using vague content

“Project updated” forces the user to investigate.

Mistake 7: Sending users to the wrong destination

A notification should link directly to the affected object or required action.

Mistake 8: Ignoring resolved events

A reminder should not be sent after the action has already been completed.

Mistake 9: Duplicating across devices

Desktop, mobile and email should coordinate rather than compete.

Mistake 10: Testing only the happy path

The highest risk bugs usually appear in combinations and exceptions.

A reusable PM template for notification design

Before creating the flowchart, complete this framework.

Decision

What exact question must the system answer?

Should this user receive this notification for this event on this channel at this time?

Event

What exactly happened?

Recipient

Who may need to know?

Eligibility

What permissions, roles or relationships are required?

Purpose

Is the message informational, actionable, warning based or confirmational?

Priority

Critical, action required, important or informational?

Hard constraints

Which rules must never be violated?

Preferences

Which user or organisation settings influence the result?

Precedence

Which rule wins when conditions conflict?

Channels

In-app, banner, email, mobile, SMS or digest?

Timing

Immediate, delayed, scheduled or grouped?

Deduplication

How will repeated notifications be prevented?

Expiry

When does the notification stop being relevant?

Action

What should the user do next?

Destination

Where should the notification take the user?

Exceptions

Which uncommon situations require different behaviour?

Test cases

What combinations must QA verify?

Metrics

How will the team know whether the notification is useful?

Only after answering these questions should the team draw the flowchart and design the interface.

Good notification design delivers the right information to the right person, through the right channel, at the right time—and makes it clear what the user should do next.