H5.05.2uncleareable notification badges are ignoreddesignresearch

A badge that cannot reach zero is ignored

Aliases: stuck unread · ghost badge · signal extinction

What it is

An unread numeral is a signal that handling can turn off. After the work is done, it should return to zero. If replies, reads, and dismissed notices leave it burning—ghost threads, items with no detail, sync errors, a permanent "there's an update"—the signal is learned as ignorable, and that ignoring generalizes to later, genuine nonzeros.

This is unread-as-closable-signal in the notification system. It is not the visual spec that an uncleareable red dot on a control gets ignored, though they share a root: what breaks is the sense that "I can turn this off."

Why it happens

A cue is used for scheduling only if it can close. Closure teaches zero = clear, nonzero = work. When it cannot close, nonzero becomes a lamp that is always on, and attention demotes it from change to wallpaper. Once it is wallpaper, a later jump from 0 to 3 no longer wins change detection—the baseline is already lit.

Uncleareable counts usually come from a set that cannot close, not from lazy users: objects with no detail page, someone else's unread, a marketing slot the product wants to keep "alive." People try opening the app on luck a few times, then stop.

Studying it

Leave a numeral nonzero after every visible item is handled. Over following days, watch glances at the home-screen numeral, taps, and in-app searches for "unread."

Independent variables: cause of residue (ghost / no detail / cross-account leak), whether "mark all done" exists, size of the residue. Dependent variables: attempts to zero and the point of giving up, later delay in opening real new arrivals, migration to other channels (mail, asking a colleague).

Annoyance in one session is not permanent ignoring. Ignoring is learning and needs repeated failure. On the product side, compare later open rates for users whose numeral stays >0 with no in-session unread versus users who can return to zero. Opening the app is not a successful zero—if the numeral survives the open, learning continues.

Where it stops holding

Some people treat the numeral as decoration that the app exists and never chase zero; their habit does not excuse residue. On shared accounts, "someone else's unread" is not a ghost, but the current operator still cannot clear it—the experience matches a ghost and needs identity filtering. Assistive-tech users who rely on the numeral as the only "is there work?" cue experience a stuck nonzero as a permanent alarm, worse than for sighted users. Legally retained closed tickets can live in history; they must not occupy the pending count.

Applying it

  • Provide a completable path to zero: handle every visible item, or an explicit "mark all done."
  • Drop items that cannot be opened, were deleted, or have expired, immediately—not at the next full sync.
  • If the corresponding objects cannot be found, do not leave the numeral as nagging; fix the set, and if needed admit it and offer a zero.
  • Verify by handling every list item and looking at the home screen. If it is not zero, list the IDs the counter still holds and delete those without a detail view. Then send a new arrival and watch 0 → 1 → 0. If that loop cannot complete, the signal is already dead.

Related

  • Within the group: H5.05.1 The count must match actual pending work · H5.05.3 Badges must not count marketing
  • Adjacent: E6.11 Badges and dots · H5.04 Notification bundling · H5.03 Do not disturb and focus
  • Search terms: stuck badge · uncleareable unread · signal extinction

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/H5.05.2