Would you like an email, a push notification, an in-app alert and a daily digest confirming that you received the other three? Many products appear to have answered on the user’s behalf.
Notifications connect events to attention. They tell someone that work is ready, risk has changed, a colleague needs input or a deadline now matters. In collaborative products, this signalling system is fundamental. Without it, people repeatedly check. With too much of it, they stop listening.
The design problem is not sending messages. It is deciding which changes deserve interruption, who can act and what the product expects them to do.
Start with responsibility
Notifications are often event-led: a status changed, a comment was added, a file uploaded. Events are easy for systems to detect and poor at deciding who should care.
Begin with responsibility. Who owns the next action? Who is accountable for the outcome? Who needs awareness but no action? Who should not be disturbed at all?
One event may produce different communication. The assignee receives an actionable alert. The case owner sees the update in a digest. A customer gets a carefully worded confirmation. An administrator sees nothing unless the process fails.
Copying everyone feels safe because nobody can claim exclusion. It also converts shared responsibility into shared noise. When an alert goes to ten people, each can reasonably assume one of the other nine is handling it.
Name the owner in the product, not only in the message.
Distinguish attention from information
Not every change deserves interruption. Some information belongs in the interface, ready when a user returns. Some belongs in a digest. Some requires immediate attention because delay changes consequence.
Classify signals by urgency and actionability. An approval approaching a contractual deadline may justify a timely alert. A colleague correcting punctuation does not. A failed financial posting may need escalation. A successful nightly synchronisation can remain quietly successful.
Urgency should come from the work, not the sender’s enthusiasm. Allowing every workflow author to mark messages High Priority creates a system where priority means “someone found the setting”. Establish product-level rules and governance.
Use interruption sparingly. A notification earns urgency when the recipient can and should act within the relevant period.
The message needs a next step
“Quote updated” creates awareness without direction. Updated how? By whom? Does the recipient need to review, celebrate or merely acknowledge the universe’s continued change?
An actionable notification includes the object, material change, reason for relevance and expected next step. “The proposed margin for Quote 1842 is below the commercial floor. Review the override by 16:00” gives the recipient a decision.
Deep-link to the relevant context, not the product homepage or generic inbox. Preserve authentication and return path. If the user opens the alert on mobile but the task requires desktop, explain and allow them to mark it for later rather than presenting a compressed impossibility.
When no action is required, say so. “For your information” can be useful when used honestly and rarely.
Timing is part of meaning
A reminder sent too early is ignored. Sent too late, it becomes an explanation. Notification design needs the timeline of the work.
Trigger around meaningful thresholds: when ownership begins, when a dependency clears, when enough time remains to act and when escalation becomes necessary. Avoid sending reminders simply because a record has existed for a number of hours. Some records are correctly waiting.
Respect working hours, timezones and operational patterns. A global team cannot rely on one office’s morning. Urgent operational alerts may need round-the-clock routing; routine updates should wait or follow recipient preferences.
Bundle activity that belongs together. Five comments in ten minutes are a conversation, not five independent emergencies. Delay briefly where aggregation improves comprehension without harming response.
Channels have different jobs
Email is durable and shareable but easily buried. In-app alerts keep context close but require presence. Push is immediate and intrusive. Chat integrations fit team habits but can detach decisions from the record.
Choose channels by consequence and behaviour, not because the platform supports them. A critical failure may use push and in-app, with escalation if unacknowledged. A weekly summary belongs in email. A collaborative mention may appear in-app and in the team’s chosen chat channel.
Avoid sending identical copy everywhere. A push needs a concise decision cue. Email can include context. The in-app version can show evidence and actions. Maintain one underlying notification state so reading or resolving in one channel updates the others.
The product should not pretend four copies are four separate tasks.
Preferences need sensible structure
Notification settings often present a long list of event names with channel toggles. Users face a configuration exam before they have experienced the product.
Provide role-appropriate defaults and group preferences around jobs: assignments and approvals, customer communication, operational exceptions, reporting. Explain consequence. Turning off “workflow events” means little; turning off “requests that need your approval” is clear enough to inspire caution.
Protect mandatory operational or security notifications, but state why they cannot be disabled. Allow frequency and digest choices where immediate delivery is unnecessary. Support temporary pauses and delegation for leave.
Preferences should follow the user across channels and remain visible from the notifications they affect. “Why did I receive this?” should answer the rule and offer a direct route to adjust it where allowed.
A notification centre is not a storage cupboard
In-app centres often become chronological piles of everything the system emitted. Read and unread are the only states, as though attention were library administration.
Organise around work. Separate items requiring action from updates and resolved history. Group by record or workflow. Show due context and owner. Let users complete simple actions safely, defer, assign or dismiss informational items.
Reading is not resolution. An approval remains open after the message is viewed. A failed integration remains failed after the alert loses its blue dot. Connect notification state to work state.
Archive resolved signals automatically while preserving access. Search by object, person and type. The notification centre should help people decide what needs attention now, not document how many things once wanted it.
Escalation should be designed
When an alert receives no action, products either repeat it or do nothing. Escalation deserves a model.
Define acknowledgement, response and resolution. A person may acknowledge an incident while investigation continues. A request may be reassigned. A deadline may pass and change the appropriate decision. Escalate to a role or rota, not an individual who happens to appear senior in the directory.
Show the escalation path before it activates. Let owners intervene, delegate or provide context. Record why escalation occurred and avoid shaming language. The goal is continuity of work, not automated managerial theatre.
Repeated escalation is product evidence. It may indicate the wrong owner, poor timing, unclear actions or workload beyond capacity.
External notifications carry the brand
Customer and partner messages are part of the service, not technical exhaust. They need clear subject lines, accurate status, appropriate confidentiality and a credible route for questions.
Do not expose internal terminology or every workflow transition. Customers care that a quote is ready, a document needs review or a schedule changed – not that status moved from 4 to 6. State what happened in their terms and what it means.
Be careful with sensitive data in email and push previews. Links may require authentication, but the message itself can still reveal relationships or commercial information. Design content for the least secure channel it uses.
Allow teams to preview templates with real variation, not one immaculate example. Long names, missing optional data and several exceptions reveal whether the communication remains coherent.
Measure outcomes, not sends
Delivery rate is a system metric. Notification success is whether the right person understood and acted in time without unnecessary interruption.
Measure action rate, time to meaningful response, duplicate channel use, dismissals, preference changes and alerts that repeatedly go unresolved. Compare notified workflows with outcomes. Look for people opening an alert and then searching elsewhere because the link or context failed.
High open rates can reflect anxiety. Low rates can reflect irrelevance or successful in-app awareness. Pair analytics with interviews and observation.
Monitor volume per person and role. Notification burden is cumulative. Each team may send a reasonable number while the individual receives a digital percussion section.
A calm product can still be responsive
Good notification design feels quieter because signals are better. People know which messages require action, which can wait and where the work lives. Ownership is explicit. Timing reflects consequence. Channels cooperate rather than compete.
Calm does not mean passive. It means the product reserves interruption for moments when attention can change the outcome, then supplies enough context for action. Everything else remains available, organised and honest without demanding a ceremonial dismissal.
This calmness requires more design than sending everything. Teams must model responsibility, urgency, state, escalation and communication. They must remove alerts whose only purpose is proving the system did something.
A nervous system does not report every cell. It carries signals that help the organism respond. Products should aspire to the same restraint – particularly before sending the third reminder about a reminder.
