P3.06.6Notification granularitydesign

Permission granularity determines whether users can refuse in part

Aliases: notification channels · permission granularity

What it is

The granularity of notification permissions is how finely the user can refuse: app-level all-or-nothing, per-category (social / recommendations / marketing), per-event-property (mentions vs. group chatter), or per-time-window. Granularity determines whether partial refusal is possible — it is the practical shape notification governance takes in the user's hands.

Why it happens

Coarse granularity forces an all-or-nothing choice. When the only option is disabling everything, the user is no longer deciding "do I want this category" but "do I want this app's notifications at all," and most choose to endure — endurance becomes the statistical default, and low-value notifications ride freely alongside high-value ones. Bundling is precisely why frequency inflates under coarse granularity: marketing recall shares one switch with friend messages, so the sender has no reason for restraint. Fine granularity turns refusal into a composable local decision — users can express real preferences (messages yes, feeds no) — and forces every category to stand alone under value scrutiny.

Where it stops holding

Granularity has comprehension costs: too many poorly named categories are themselves a usability burden, and some users retreat to all-off out of setting fatigue — excessive granularity punishes exactly those who wanted nuance, so category count and naming clarity are real constraints. System-level grouping (OS notification channels) and in-app customization have separate jurisdictions, and inconsistent mappings break each other (off in the system, re-on in the app). A few urgent categories (safety alerts) are legitimate exceptions, but must be explicit and tiny in scope.

Applying it

Divide categories by event nature, not internal product structure — start with from-people / from-system / marketing-recall — each with its own switch and frequency cap. When first requesting notification permission, show a preview (what each category looks like, how often by default) so consent is informed; new notification types must be re-negotiated, never silently grandfathered into existing grants. The naming test: users can guess the category's contents without explanation. Verification: track the opt-out distribution under fine granularity — a category heavily refused individually while global opt-out stays low proves granularity is absorbing dissatisfaction; if users still go all-off, check first whether the category scheme itself is wrong.

Related

  • Same group: P3.06.1 Notifications can manufacture sessions the user never initiated · P3.06.2 Recall unrelated to user goals is attention taking · P3.06.3 Frequency judged by user value, not retention · P3.06.4 The cost of interruption lands on task resumption · P3.06.5 Badges are content-free recall signals · P3.06.7 Timing more than frequency decides whether notifications read as harassment
  • Adjacent: P3.05.1 Mute, unsubscribe, and delete must be equally reachable · P3.06.3 Frequency budgets
  • Search terms: notification granularity · notification channels · permission granularity

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/P3.06.6