How to Design Product Notifications Users Don't Turn Off

To design product notifications users don't turn off, send fewer of them and make each one earn its place: notify people only about things that involve them or something they own, that they can act on, and that they'd be annoyed to miss. Match the channel to the urgency (most things belong in an in-app inbox, a few deserve email, very few deserve a push), batch bursts into one message, never notify people about their own actions, and give them a short preferences page where they can switch off one type without losing the rest. People mute a product when it wastes their attention. Stop wasting it and the switch stays on.

Below: a four-question test, channels, copy, batching, defaults, preferences, push permission, an inventory, build vs buy, a made-up example and a 7-day plan.

Why do users turn off product notifications?

Nobody mutes a product after one bad message. Notification fatigue builds from a pattern:

• Too many. Twelve emails for twelve comments on one task. Each was "correct". Together they're noise.

• Not about them. "A new project was created in your workspace." By someone else, for something they'll never open.

• Nothing to do. Something happened, but there's no reason to click, so they learn to ignore the sender.

• Wrong channel. A push to their phone for something that could have waited until they next opened the app.

• No way to tune it. If the only control is all or nothing, people pick nothing.

Apple's Human Interface Guidelines on managing notifications make the same point: people have several ways to adjust how they receive your notifications, including turning them all off, so you build trust by accurately representing how urgent each one is.

Does this event deserve a notification at all?

Most noisy products got that way because sending a notification is one line of code. Every new event gets one, and nobody removes them. Flip the default. Before any event gets a notification, ask four questions:

1. Is it about me or something I own? I was mentioned, assigned or replied to, or it happened to a thing I created or follow.

2. Can I act on it? There's a reply to write, a review to do, a file to download.

3. Would I be upset to miss it? If I found out a week later, would I be annoyed nobody told me?

4. Is it time-sensitive? Does waiting a few hours make it worse?

My rule of thumb: an event needs a yes to question 1 plus at least one more yes to get any notification, and yes to all four to get a push. Everything else can live in an activity feed people check when they choose to. That's a log, not a notification, and logs are fine.

"Sam mentioned you" passes easily. "Your export is ready" passes. "Someone viewed your document" usually fails question 2.

Which channel should each notification use?

Once something deserves a notification, decide how hard it gets to tap someone on the shoulder. Think in urgency tiers:

Apple formalises this with interruption levels (Passive, Active, Time Sensitive and Critical) and says to use Time Sensitive only for events happening now or within an hour. That's a good bar for your "Now" tier even if you never ship an iPhone app.

Most of your in-app notifications should land in "Whenever". If "Now" holds more than two or three event types, be suspicious.

How do you write a notification people act on?

A good activity notification says who did what to which thing, offers one action, and links straight to the exact item. A pattern to start from:

{actor} {verb} {object} in {place}

So: "Priya assigned you 'Replace sash cords' in Hartley Street job." Not "You have a new notification."

• Lead with the person and name the thing. "Sam replied on 'Kitchen window survey'" beats "New reply received".

• One action. "Reply", "Review", "Download". Not five buttons.

• Deep link to the exact item, not the dashboard. If they have to search for it, the notification failed.

• Include short content. Show the comment text itself.

• Subjects that match the body. For email notifications in a SaaS product, the subject line is the notification for most people. "Priya assigned you a task" works. "Update from Sashtally" doesn't.

And keep marketing out. Apple's guidelines say not to use notifications for marketing or promotional content unless people explicitly agree to it, and Google's email sender guidelines say not to mix different types of content in one message. Once your "Sam mentioned you" email carries a promo banner, people stop trusting that channel. Product news belongs in a changelog people actually read. Onboarding emails are a different job too, covered in this guide to onboarding emails that get users to their first win.

How do you batch notifications so a busy day isn't twelve emails?

Batching is the biggest single fix for most noisy products: when several events about the same thing arrive close together, send one message about all of them.

• Collapse by item. Twelve comments on one task becomes "Priya and 2 others left 12 comments on 'Replace sash cords'." Knock's docs on batching use this exact case: if someone leaves ten comments on a page in fifteen minutes, send one notification about the ten. Group by page, so two pages produce two messages.

• Send the first, hold the rest. The first comment goes out right away; anything in the next window gets bundled.

• Cooldowns. After emailing someone about an item, don't email them about it again for a while. My rule of thumb is 30 to 60 minutes for comments.

• Digests for the "Summary" tier. One daily or weekly email listing what happened on things they follow. Let them pick daily, weekly or off.

• Quiet hours in their time zone. Store each user's time zone and hold non-urgent email and push until their morning.

Novu's docs call these a digest step (collect events per subscriber, continue once per window) and a throttle step (cap how often a workflow fires for one person). You want both.

How do you stop telling people things they already know?

Don't notify people about their own actions. If I assign a task to myself, I don't need an email saying I was assigned a task. If I comment on a thread I follow, I don't need to hear about my own comment. Remove the actor from the recipient list before sending anything.

Respect read state across channels. If someone saw the mention in your in-app inbox, don't email it ten minutes later. Put it in the inbox first, wait a short window, and send the email only if it's still unread. Novu's docs give this sequence as an example, and also suggest waiting briefly before a push in case the user has already seen it in the inbox. When they open it from any channel, mark it read everywhere. Nobody should get the same news twice.

What should your notification defaults be?

Most people never open settings, so your defaults are your notification design. Make them conservative:

• On: direct mentions, things assigned to you, replies to your comments, and results of things you asked for (your export, your report).

• In-app only: status changes on things you follow, new items in shared spaces, teammates joining.

• Off (opt-in): "all activity" on a project, every comment in a busy space, anything power users want and most people would hate.

• Push: off until asked, in context (see below).

Getting someone to turn one more on is easy. Winning back someone who turned everything off is not.

What should a notification preferences page include?

A short grid: notification types down the side, channels across the top, a toggle in each cell. Group types so it stays under ten rows:

• Link to it from every notification email footer, straight to the grid.

• One-click unsubscribe that turns off only that type. If someone unsubscribes from "Teammate joined" emails, switch off that one cell and say so: "You won't get teammate-joined emails anymore. Mentions and assignments are still on." Turning off everything from one link is how you lose the mentions they wanted.

• Quiet hours and time zone on the same page.

• Keep it findable: Settings, then Notifications.

A short note on email rules (not legal advice). Google's email sender guidelines require senders of more than 5,000 messages a day to Gmail accounts to support one-click unsubscribe for marketing and subscribed messages. The FTC's CAN-SPAM compliance guide treats "transactional or relationship" messages as exempt from most of the Act's provisions, but says those categories are read narrowly and that mixing in promotional content can make an email commercial. Plain activity notifications are the safer side of that line; if unsure, ask someone qualified.

When should you ask for push notification permission?

Not on the first visit. Matt Gaunt's Permission UX guide for web push calls asking as soon as someone lands the worst thing you can do: they have no context, the prompt blocks what they came to do, and blocking out of frustration is common. Once a user blocks the browser prompt, your app can't ask again.

• Ask when the benefit is obvious. Right after someone gets their first assignment: "Want a push when someone replies to you?"

• Double permission. Show your own small dialog first and trigger the real browser prompt only if they say yes. A "not now" on your dialog costs nothing. A "Block" on the browser's costs you that person for good.

• A settings toggle, so people can turn push on when they're ready.

• A way out. Explain how to turn push off. If you don't, the guide warns, people take the nuclear option and block permission.

Apple's guidelines agree: get permission before sending any notification, and provide an in-app settings screen where people can change their choice.

How do you keep a notification inventory?

List every notification your product sends today. Search your code for every call to your email provider and every write to a notifications table; you'll find a few you forgot. One row per type:

The "Owner" column looks silly when you're solo. Keep it anyway. One rule goes at the top: no new notification type ships without a row here and a pass on the four questions.

Should you build notifications yourself or use a tool?

For a small product, homegrown works for a long time. You need a notifications table, a function that decides who gets what, and the email provider you already use:

create table notifications (id, user_id, type, actor_id, object_id, created_at, read_at, emailed_at)

That gives you an in-app inbox (unread rows), read state (read_at), "email only if unread" (a scheduled job that checks read_at before sending) and a place to hang batching later. Add a preferences table keyed by user, type and channel and you've covered most of this article.

A tool makes sense when you want several channels, digests, an inbox component and a preferences UI without maintaining them. Four vendors' own pages, checked Oct 20 2026:

Usage is counted differently: Knock counts one message per user per channel, and MagicBell adds up every channel a user receives a notification on. Plans change, so check on the day you decide. And no tool will tell you which notifications to delete.

How do you know your notifications are healthy?

Keep this light. A few numbers per notification type, once a month:

• Opt-out rate per type. A type that keeps getting switched off is telling you something.

• Click-through to the item. Low click-through on a "Today" type usually means it belongs in "Whenever".

• Mute and unsubscribe spikes. A jump right after you ship a new notification points at the new one.

• Replies to notification emails. "Please stop sending me these" is the most honest feedback you'll get.

Small numbers are prompts to talk to people, like the product metrics that matter before your first 100 users.

A made-up example: Sashtally trims its notification list

Everything in this example is made up: the product, the maker and every number. Sashtally is a job tracker for small window-restoration crews: jobs, tasks, photos and comments. Its maker, Tomas, noticed a few crew leads had turned off email entirely and were missing assignments. He built the inventory, ran each row through the four questions, and changed this:

He also added a five-row preferences grid and per-type unsubscribe links. In this made-up story, a typical crew lead went from about 30 Sashtally emails on a busy day to 4 or 5, and two leads who had turned email off switched mentions and assignments back on. Every row in the "after" column is boring, and boring is what people keep switched on.

What notification traps should you avoid?

• Notifying on every event because it's easy. Easy to add, hard to undo.

• Marketing through the activity channel. It teaches people the whole stream is skippable.

• Emailing what they already saw. Check read state before every email and push.

• No batching. A burst should be one message.

• Buried or all-or-nothing preferences. If people can't turn off one type, they turn off all of them.

• The push prompt on the first visit. You get one real chance with the browser prompt.

• Sending at 3am in the user's time zone. Your server's clock isn't their clock.

• Notifying people about their own actions. Filter out the actor.

A 7-day plan to fix your product notifications

Those times are rough rules of thumb, not a benchmark.

FAQ

Should notifications be on by default or opt-in?

On for things directly about the person (mentions, assignments, replies, results they asked for). Opt-in for broad activity. Push stays off until they say yes in context.

Do I need an in-app inbox if I already send emails?

For most products, yes, and build it first. It's where "Whenever" notifications live, and it lets you skip emails for things people have already seen.

Can I add product news to activity emails?

Keep them separate. Apple says marketing notifications need explicit permission, Google says not to mix content types in one message, and the FTC guide says mixed messages can count as commercial email. Send product news separately, to people who opted in.

Keep the notifications people would miss

Good notification design is mostly deleting. Keep the messages people would be upset to miss, put them in the quietest channel that works, bundle the bursts, and let people turn off one thing without turning off everything. If you want honest outside eyes on it, list your product on MakerHunt and ask other makers which of your notifications they'd turn off first. Their answer is usually the first row to cut.