ISSUE_042 SUMMER 2026 A_JOURNAL_OF_APP_STUDIOS SHIPPED_WEEKLY
← back_to_teardowns
teardown · notifications7 min read05 June 2026

A push-notification settings screen worth stealing from.

One small productivity app, three thoughtful choices, almost no copy. A short look at a notification settings screen that has, in our view, quietly solved a problem most apps still get wrong.

Push notification settings

The notification settings screen, as a category, is one of the more consistently disappointing surfaces in contemporary mobile design. Most apps default to one of two patterns. The first is the long list of granular toggles — twelve or fifteen options, each with a piece of copy explaining what it does, none of which the user actually reads. The second is the single master toggle: notifications on or off, take it or leave it. Both patterns share the same failure mode: the user does not know what they want, the screen does not help them figure it out, and the user either accepts the defaults or turns everything off.

The screen I want to look at today, from a small productivity app launched in late 2024, does something different. It has three options, none of them a granular toggle. It has perhaps thirty words of copy on the whole screen. It does the job better than any of the long-list screens I have reviewed in the past year. The decisions worth examining are small in isolation and collectively very interesting.

The three options

The screen presents three radio buttons, stacked vertically. They are labelled, in the app's own copy:

Quiet. "We will only notify you when something is overdue."
Helpful. "We will notify you about the things you have asked us to keep track of, when they matter."
All of it. "We will notify you about everything we think you might want to know."

That is the entire screen. There is a "Done" button at the bottom. There is, importantly, no way to access more granular settings from this screen. The user picks one of three options, the app remembers the choice, and the system that delivers notifications is configured accordingly under the hood.

Why this works

The conventional argument for granular notification settings is that users want control. They want to be able to turn on the notifications they care about and turn off the ones they do not. The team that built this app told us, in conversation, that they had been persuaded of this argument for the first eighteen months of the product's life. They had, accordingly, built a notification settings screen with thirteen separate toggles.

The data they collected from the granular screen told them, over time, that the conventional argument was wrong. The vast majority of users did not change the defaults. Of the users who did change something, the changes clustered into three distinct patterns: users who wanted no notifications except urgent ones, users who wanted moderate notifications about the things they had explicitly engaged with, and users who wanted everything the app might plausibly notify them about. The three patterns covered, on the team's analysis, about 94 per cent of users who interacted with the settings at all.

"Most settings screens are a confession that the team has not made a decision. The user is being asked to make the decision instead. If you can make the decision, on the user's behalf, into a choice between three plain-English options — most users would prefer that."

Why the copy matters

The labels on the three options — Quiet, Helpful, All of it — do an unusual amount of work for their length. They communicate the trade-off the user is being asked to make without ever using the word "notifications," without listing any examples of what the user will or will not receive, and without invoking any of the standard hedging language that settings screens typically rely on.

This is not, the team told us, accidental. The copy was rewritten three times. The original version had labels of the kind I might have written first: "Critical only," "Recommended," "Everything." These tested badly. Users found them either intimidating ("what's critical?") or vague ("recommended by whom?"). The current labels are shorter, more colloquial, and — by the team's own user-testing — much easier for users to parse on a first reading.

What this implies for the rest of us

I want to be careful about generalising from a single screen in a single small app. The pattern I have described above will not work for every product. An app with genuinely diverse notification needs — a multi-product platform, for instance — would not be able to collapse its notification settings into three options without losing real functionality.

What the pattern does suggest, however, is that the "give the user granular control" position deserves more scrutiny than it usually gets. Granular control is, in many contexts, a way of avoiding the harder design work of figuring out what the user actually wants. The settings screen as a category is full of examples of this avoidance. The screen I have just described is a small example of what happens when a team chooses to do the harder work instead.

The "three options, plain English, no escape hatch" pattern is, in our view, worth experimenting with in any product where the underlying behaviour the user is configuring can be reasonably summarised in three or four distinct modes. The pattern will not always succeed. When it does, however, it tends to produce settings screens that users actually engage with, rather than the long lists of toggles that everyone agrees should be there but that nobody actually reads.

// END