Notifications are a design choice

Notification design is usually treated as plumbing. Someone adds a push service, marketing asks for a re-engagement message, a product manager asks for a badge, and a year later the app buzzes eleven times a day. Nobody decided that. It accumulated. We think notifications deserve the same attention as any screen in the product, because they are the only part of the app that reaches out and takes someone's attention without being asked.

This post is about how we decide what gets to interrupt people. It is written from the point of view of a small studio that makes desktop and mobile apps, so it is opinionated and a bit strict.

Who benefits from this notification

The first question we ask about any notification is simple: if this arrives, who is better off, the person or the product?

"Your download finished" helps the person. They started something, walked away, and now they can come back. "Alex sent you a message" helps the person, because another human is waiting. "You have not opened the app in three days" helps the product. So does "See what you missed", and so does almost every notification that contains the word "new" without saying new what.

Most apps mix the two kinds on one channel, and that is where trust goes. Once someone learns that half of an app's notifications are for the app's benefit, they start ignoring all of them, including the ones they needed. Then the app sends more to compensate. It is a common loop, and it is very hard to reverse once people have switched the app off in system settings.

So the first rule is that a notification must be about something the person did, something another person did for them, or something they explicitly asked to be told about. Nothing else goes on the system notification channel.

The cost of an interruption

Interruptions are more expensive than they look. Gloria Mark's research at UC Irvine is often quoted for the figure of about 23 minutes to get back to an interrupted task. The finding we find more useful is from her 2008 study with colleagues: people who were interrupted often finished their work just as fast, but they worked faster to compensate and reported more stress and frustration. The cost moves from the task to the person.

There is a second cost that is easier to see. A notification that arrives while you are doing something else forces a decision: look now, or remember to look later. Even dismissing it takes a little attention. Multiply that by dozens a day and you get the feeling most people describe about their phones. No single alert is the problem. The day just never quite settles.

That is the picture in the hero drawing. The top line is an illustrative day with everything switched on. The bottom line is the same information, delivered differently. Nothing important was lost. Most of it just arrived later, in a group.

Batching is the default we want

Most information is not urgent. A new comment, a finished sync, a weekly report, a price change on something you are watching: all of it is fine to read an hour from now. Batching turns thirty small interruptions into three moments where you look at everything at once.

Operating systems now support this directly, which makes it a design decision rather than a technical one. On Apple platforms, apps can mark a notification with an interruption level: passive notifications appear quietly without lighting the screen or making a sound, active is the normal default, and time sensitive can break through a Focus mode if the user allows it. iOS also has a Scheduled Summary that groups non-urgent notifications and delivers them at times the user picks. Android has notification channels, so users can switch off one category of notification without losing the rest, and since Android 13 apps have to ask permission before posting notifications at all. Apple documents interruption levels in its User Notifications framework.

All of this only works if apps are honest about what they send. An app that marks every marketing message as time sensitive is technically allowed to ask for that, and it is exactly the kind of thing that makes people switch everything off.

Inside our own products, we try to batch before the operating system has to. If several things finish close together, one notification says so. If a background job produces a summary, it arrives once, not per item.

Allow-lists, badges and quiet hours

Allow-lists beat block-lists. Asking people to block the things they do not want means they have to discover each annoyance first. Asking them to pick the few people or events allowed to reach them at any time is shorter, calmer and closer to how people actually think. When we sketched the Humanly Phone concept, the quiet slider only lets through calls and texts from an allow-list of five or six people. That phone is a concept and not for sale, but the rule works for apps too.

Badges are notifications. A red number on an icon is a small, permanent interruption, and it is often used to create a feeling of debt. Our rule is that a badge counts things that need the person to act, and nothing else. Unread promotional content does not count. A number that grows while you are asleep and means nothing is a nag with a red background.

Quiet hours are for everyone. Every app that can notify should respect the system's Do Not Disturb or Focus settings without trying to get around them, and anything that sends its own scheduled messages should avoid the middle of the night in the user's time zone. This sounds obvious. A surprising number of services still send a weekly email at 3 am local time because the server runs on another continent.

The rules we follow in our apps

This is the list we use when designing or reviewing an app, ours or a client's:

1. Off until earned. We do not ask for notification permission on first launch. We ask when the person does something that makes a notification useful, such as starting a long task, so the request explains itself.
2. Only for things the person started or asked for. No re-engagement, no streaks, no "we miss you".
3. Only when they are not looking. A desktop app that is in the foreground does not need a system notification to say its task finished. The window already says so.
4. Only for things that took a while. A copy that takes forty minutes is worth a notification when it finishes. A copy that takes two seconds is not.
5. One notification per event, grouped when possible. Ten files finishing in the same minute is one message.
6. Settings by category, in the app. If a person wants errors but not completions, they should be able to say so without going through the operating system.
7. The text should be enough. A good notification tells you what happened without opening the app. "Export finished: 412 files, 3 skipped" is better than "Your export has an update".

None of these are technically hard. They mostly mean saying no to requests that would increase short-term engagement numbers. For the kind of tools we make, where the whole point is to do a job and get out of the way, that trade is easy. For an app whose business depends on daily active users, it is harder, and we understand why teams give in. We just think the long-term cost is higher than it looks on a dashboard.

Designing the quiet state

The part of notification design people forget is what the app looks like when nothing is happening. If every screen has a dot, a count or a banner, then the absence of news never feels like a finished state. We try to design a clear "all done" state for every app: nothing pending, nothing unread, nothing to check. It is usually the most boring screen in the product, and that is how you know it works.

Next time you add a notification to something you are building, try writing down who it is for before writing the text. If the honest answer is "for our retention chart", leave it in a list inside the app, where people can find it when they choose to look.