Send fewer of them, and make each one pass a test before it is allowed to interrupt. Muting is not a user problem to be solved with better copy. It is a verdict on the ratio of useful notifications to noise, and the only way to change the verdict is to change the ratio.
Every product team we have worked with has had a version of this conversation. Engagement is down, so the answer is more notifications, so more people mute, so engagement drops further. The loop is easy to enter and hard to notice from inside.
This is the test we apply, the channel rule that follows from it, and the accessibility requirements that most product teams miss entirely.
Less than you think, and the distinction matters. Nielsen Norman Group's article on indicators, validations and notifications, written by Kim Flaherty and published on January 17, 2024, separates three things that teams treat as one.
An indicator is a way of making a page element stand out to inform the user that there is something special about it. It is contextual, conditional and passive, and it does not require user action. A validation message is an error message related to users' inputs, communicating whether the data just entered was incomplete or incorrect.
A notification, by contrast, alerts the user of general occurrences within a system and may not be directly tied to user input. That last clause is the important one. A notification arrives while the user is doing something else, which is exactly why it costs more than the other two.
Three reasons, and only one of them is volume. The first is irrelevance, where the notification is about something the user does not care about. The second is timing, where a genuinely relevant message arrives at a moment when it cannot be acted on. The third is repetition, where the same event notifies more than once through different routes.
Repetition is the one teams miss. A comment on a document can produce an in app badge, a desktop push, an email and a message in a chat integration. Each was added by a different team solving a different problem, and the user experiences it as your product shouting the same thing four times.
Muting is rational in all three cases. Once you accept that, the design question stops being how do we get attention back and becomes which of these should never have been sent.
Three questions, and a notification has to pass all three. Does this require a decision from this specific person. Would waiting an hour cause harm. Can they act on it from where they will be standing when it arrives. Anything that fails one of those is not urgent, whatever the feature owner says.
NN/g's framing supports this split. It describes action required notifications as urgent events demanding user response, which should be intrusive, and passive notifications as informational only, delivered through less intrusive means such as badges and corner popovers, while acknowledging those risk being missed.
Risk being missed is the honest trade and it is the right trade for most messages. A passive notification that is occasionally missed costs almost nothing. An intrusive notification that was not urgent costs you the channel permanently.
Match the channel's interruption cost to the message's urgency, and never send the same event twice. Our default ladder is a quiet in app marker for things that can wait, an in app notification centre for things worth finding later, email for things that need a record, and push only for the small set that passed all three priority questions.
The rule that does the most work is one event, one channel. If an event is important enough for push, it does not also need an email. If it is important enough for email, it does not also need a desktop alert. Pick the highest appropriate rung and stop.
The exception is escalation over time. A message that was passive and has been ignored for a week can legitimately be promoted, because the situation changed. That is a different thing from broadcasting on four channels at once.
It converts many interruptions into one. Ten notifications in an hour cost ten context switches. The same ten in a single digest cost one, and the user reads them in a state where they can decide what to act on.
Batching also fixes a problem that copy cannot. A single event out of context is often meaningless, and NN/g's guidance notes that context and background information are essential since users may be focused elsewhere when notifications appear. A digest supplies that context for free by putting related events beside each other.
What batching does not fix is relevance. A daily digest of things nobody cares about gets muted at the same rate as the individual messages did, just with fewer clicks required. Batch after you have cut, not instead of cutting.
More than most product teams implement, and the standards are specific. WCAG success criterion 2.2.4 Interruptions, at Level AAA, states that interruptions can be postponed or suppressed by the user, except interruptions involving an emergency. The stated intent is to allow users to turn off updates from the author or server except in emergencies.
The Understanding document is clear about who this protects. It says individuals with attention deficit disorders can focus on content without distraction, and that individuals with low vision or who use screen readers will not have content updated while they are viewing it, which can lead to discontinuity and misunderstanding if they start reading in one topic and finish in another.
If your product has anything on a timer, criterion 2.2.1 Timing Adjustable at Level A also applies. Among its options, the user must be warned before time expires and given at least 20 seconds to extend the time limit with a simple action, and be allowed to extend it at least ten times, unless the limit is longer than 20 hours or extending it would invalidate the activity. Our WCAG guide covers how these fit together.
Politely, almost always. The aria-live attribute sets the priority with which a screen reader treats updates to a live region, with settings of off, polite or assertive. Mozilla's documentation states that normally only aria-live="polite" is used, for regions receiving updates that are important for the user to receive but not so rapid as to be annoying, and that the screen reader will speak changes whenever the user is idle.
Assertive is the one to be careful with. The same documentation says it should only be used for time sensitive or critical notifications that absolutely require the user's immediate attention, that a change to an assertive region will interrupt any announcement the screen reader is currently making, and that it can be extremely annoying and disruptive and should only be used sparingly.
There are roles with implicit live behaviour. role="alert" is for an error or warning message, role="status" for an updated status, and role="log" for a chat or error log, with the guidance to add a redundant aria-live="polite" for status and log. One warning worth knowing is that adding both aria-live and role="alert" causes double speaking issues in VoiceOver on iOS.
The biggest is announcing nothing at all. Assistive technologies generally only announce dynamic changes to a live region, so the documented pattern is to start with an empty live region and then, in a separate step, change the content inside it. A toast that appears fully formed in one operation is often silent.
The second is announcing too much. aria-atomic controls whether the whole region is presented even when only part changes, and defaults to false. aria-relevant controls which change types matter, with possible values of additions, removals, text or all, and a default of additions text. Getting these wrong turns a status area into a stream of fragments.
The third is treating a toast that disappears as a notification. If a message vanishes after four seconds, anyone who was not looking has lost it, and anyone using a screen reader may not have finished hearing it. Anything that matters needs a place it persists. Our notes on loading and empty states cover the same principle for transient UI.
Lead with what happened and to what, then who did it, then what you want. Sarah commented on the Q3 proposal is a useful sentence. New activity in your workspace is not, because it forces the user to open the product to learn whether they cared.
Name the object every time. Most notification failures are not tone problems, they are missing nouns. If the user has forty documents, a message about your document is a riddle rather than an alert.
Then make the action explicit and singular. One notification, one thing to do. The general rules for this are the same ones in our piece on microcopy, and they matter more here because the reader is interrupted rather than browsing.
Track the mute rate per notification type, not overall engagement. Overall numbers hide the specific message that is driving people to the settings screen, and there is almost always one specific message.
The second metric is action rate. If a notification type is opened often and acted on rarely, it is curiosity bait rather than a useful alert, and it is spending trust you will want later. That is a candidate for demotion to a passive channel.
The third is the unsubscribe cascade. When someone mutes one type, watch whether they mute everything within the next month. A single bad notification type often takes the whole channel down with it, which is the strongest argument for cutting rather than tuning.
Audit every notification your system can send, put each one through the three priority questions, and demote everything that fails. In our experience that alone removes a meaningful share of them, and nobody misses the ones that go.
Then fix the duplicates, so one event produces one message. Then, and only then, look at copy and timing. Doing it in the other order is how teams spend a quarter polishing messages that should not exist.
If you would like help running that audit, or a review of how your notifications behave for someone using a screen reader, we are glad to take a look. You can reach our team at phoenix.studio, and our piece on SaaS onboarding flows covers the moment most notification permissions are won or lost.
Tell us where you want to go. We'll tell you how we'd get you there.