Categories that are too fine make settings themselves a burden

What it is

Types that are too fine—one switch per campaign, per topic, per internal event name—turn the settings page into a sorting job. People who cannot see the differences do not configure, then master-off when bothered. Grain is useful when it makes the trade cheap. Too fine turns the trade into cataloguing.

This is how fine is too fine. It does not deny that type switches beat a master switch, and it does not discuss whether new types should default off.

Why it happens

Each switch costs: read the name, imagine what will arrive, decide, remember the decision. Working memory holds only a few items; a long list pushes the strategy to "don't touch" or "all off." Over-fine names also cannot be recovered from an arrival: someone holding a card cannot point to which of forty switches it belongs to, so in-place unsubscribe cannot aim.

Engineering over-fineness usually dumps an internal event bus into channels. The bus's cardinality is convenient for developers, not a mental category. People's categories are roughly "someone wants me / my money and orders / security / social noise / pitches." Past that scale, merge; don't add another switch.

Studying it

Map the same arrival set onto 4, 12, and 40 switches. Measure configuration time, whether a new card can later be mapped back to the right switch, and whether people finally take master-off.

Independent variables: switch count, names from user tasks vs internal events, grouping. Dependent variables: configuration completion, mapping accuracy, abandon-to-master-off.

Lab "please set all of these" overstates patience. Harder: a primary task unrelated to notices, with settings optional. Count of switches left on is not engagement—under over-fine lists people leave defaults at random; that is inertia, not consent.

Where it stops holding

Professional ops consoles are supposed to host hundreds of rules; operators are authoring rules, not "subscribing," and consumer grain caps should not cut that. Assistive-tech users pay more to walk forty switches linearly, so over-fine becomes unreachable first. If the OS channel list is already long, an app-layer duplicate doubles the burden.

Applying it

• Fold internal events into a few types named by user tasks; if finer grain is needed, nest it under a type and don't spread the second level on the first screen.
• A switch must match an arrival sample a person can point to; if it doesn't, merge.
• Lead settings with around five primary types; expand for advanced.
• Verify by giving twenty recent real notices to someone outside the design and asking which switch would stop this card. Misses or guesses mean merge. If the settings page needs more than one viewport of scrolling to reach transactions, grain is already punishing the trade.

Related

• Within the group: H5.09.1 Subscribe by type instead of one master switch · H5.09.3 New types should default off, not join existing subscriptions · H5.09.4 Subscription state must stay in sync between the notice and settings
• Adjacent: H5.07 Push frequency · H4.02 Purpose explanation · H1.12 Abandonment and field reduction
• Search terms: channel explosion · settings overload · category grain