Sort your app's notifications before your users do it for you.
Somebody on your team added each notification for a good reason. Together they've taught your users to swipe without reading, or to switch them off. Sorting them into four piles takes an afternoon and usually ends with fewer, better interruptions.
List every notification your app can send, then sort each one. Interrupt now only when something changed that this person must act on soon. Batch what's useful but not urgent. Show the rest inside the app when they open it, and delete anything sent just because the system could. Give each pile its own channel, so muting one kind doesn't silence the alerts that matter, and name who approves new notifications.
Start with the full list
Nobody sets out to build an app that nags. It happens one reasonable request at a time. Operations wants a ping when a job is assigned. Sales wants one when a quote is viewed. Marketing wants one for the spring offer. Support wants one when a ticket is updated. Each makes sense on its own. Together, they teach people that your app's notifications are mostly noise.
People respond to that in one of two ways. They swipe everything away without reading, which means the important message gets swiped too. Or they switch notifications off, and getting that permission back is much harder than getting it the first time. Every notification spends a little of the trust that keeps the important ones switched on. Both iPhones and recent Android phones ask people before an app can send notifications at all. On Android 13 and later, it's a runtime permission, and Google's own guidance is to ask in context, when the person can see why it's useful.
So start with a list. Every notification your app can send, with four things beside it: what triggers it, who receives it, what it says, and who asked for it. Pull it from the code, not from memory. Most teams are surprised by how long it is, and by how many entries nobody can explain.
Then sort the list into four piles.
How the work moves
Three questions that sort a notification
- Did something change?
If not, it's a reminder or a promotion. In-app, email or delete.
- Must this person act?
If nobody needs to do anything, show it in the app or delete it.
- Does an hour late matter?
Yes: interrupt now. No: batch it into a summary at a sensible time.
- Can they act from the lock screen?
Write it so the message says what changed and what to do.
Pile one: interrupt now
A notification earns an interruption when three things are true. Something changed. This specific person needs to act on it. And it matters whether they act in the next few minutes rather than the next few hours.
For a field team, that's a job reassigned while someone is driving to it, a customer cancelling before the technician arrives, or a safety notice for a site. For a customer app, it might be "your driver is outside" or "your card was declined and the order is on hold."
A quick test: if the person saw this an hour late, would something go wrong? If the answer is no, it isn't pile one.
Write pile-one messages so they can be acted on from the lock screen. Say what changed and what to do. "Job 4417 moved to 2:30. Tap to confirm" is better than "You have an update."
Think about where the person is when it arrives. A technician on a roof, a driver at a junction and a nurse between patients can't read a paragraph. For them, the message should be short enough to take in at a glance, and the action should take one tap or none. If the right response is a phone call, say so and put the number one tap away.
This pile should be short. If it isn't, look again. Teams often put things here because they feel important to the person who requested them, not because the recipient needs to drop what they're doing.
Every notification spends a little of the trust that keeps the important ones switched on.
Pile two: tell me later
Plenty of notifications are useful but not urgent. Tomorrow's schedule is ready. Three new reviews came in. A teammate commented on a job. These belong in a summary at a sensible time, a badge, or a digest, not a buzz in someone's pocket the moment they happen.
Batching changes how people feel about the app. A single message at 7 a.m. that says "Tomorrow: four jobs, first at 8:00" is welcome. Four separate messages at random times the evening before are not, even if the information is identical.
Decide what "later" means for your users. A field crew may want the next day's plan at the end of the shift. An office team may want a morning summary. Quiet hours matter here too. Respect the person's local time and their working pattern, and don't send pile-two messages at night just because the job that generated them ran at night.
Pile three: show it when I open the app
Some messages only make sense when the person is already looking. Confirmation that a form they just submitted went through. A status change on something they're tracking but can't affect. A tip about a feature. These belong in an in-app inbox or on the relevant screen, where they're available without demanding attention.
The common mistake in this pile is notifying someone about the thing they just did. If a person taps "submit" and sees a success screen, a push notification saying "Your submission was received" is noise.
Promotional messages usually belong here too, or in email. If your business genuinely needs marketing pushes, give them their own category, and ask for that permission separately and honestly.
Pile four: delete it
The last pile is everything that's sent because the system could send it. Duplicates of an email the person also received. Notifications about other people's actions that require no decision. Reminders for things the person already completed. Messages whose original requester left the company two years ago.
Delete them. If someone objects, ask what they expect the recipient to do with the message. If there's no answer, the notification goes.
Sometimes the honest answer is "I want to know they saw it." That's a real need, but it's the sender's need, and a notification is a poor way to meet it. A read receipt on the job record, or a confirmation step inside the app, tells the sender what they want to know without interrupting anyone.
Decision guide
One channel for everything vs. a channel per pile
| Consideration | One channel | Channel per pile |
|---|---|---|
| Muting promotions | Silences job alerts too. | Leaves urgent alerts on. |
| Evening schedule updates | Arrive one buzz at a time. | Arrive as one summary at a set hour. |
| Adding a new message | Anyone can, so the list grows. | An owner decides which pile it joins. |
| Knowing what's working | One opt-out rate for everything. | Opt-outs per category show what annoys people. |
Write the rules down
Sorting once helps. Keeping it sorted takes a few rules.
Give each pile its own channel. Android lets people switch off an app's notification categories one at a time. On iPhone, offer the same choice in your app's own settings. Put job alerts, daily summaries and promotions in separate categories, so someone who mutes the promotions keeps the alerts that keep their day running.
Give every notification an owner and a reason. Keep the list from the first step and add a line for why each one exists. When someone wants a new one, they say which pile it belongs in and who it's for.
Name who approves additions. One person, usually in product, says yes or no to new notifications. Without that, the list grows back within a quarter.
Watch what people do. Track how often people turn off each category, and how often a pile-one message is opened. Use your own numbers. If people switch off a category, that's information about the category, not about your users.
The app should feel like a colleague who only interrupts when it matters. That's the kind of mobile application we build: designed around movement, interruptions and the decisions that have to happen on the spot. If your notification list has grown past the point anyone can explain it, send it to us and we'll help you sort it.
Related work: WorkStep.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.