The count must match actual pending work
Aliases: badge count integrity · pending-work tally · unread as queue
What it is
The number on a notification system promises how many things still need handling, not how many times something was pushed or how often the app wishes to be opened. The count should map one-to-one onto objects that can actually be processed after launch: an unread thread, a review, a charge to confirm. Counting already-read, expired, or display-only state sync turns the number from a to-do into bait.
This is unread semantics. It does not define the control vocabulary in which a dot means presence and a numeral means quantity; that is a different surface.
Why it happens
People treat the home-screen numeral as queue length. Queue length tells them whether to open now and how many glances will clear it. Mix in items that cannot be handled, and the expectation becomes "opening will not clear it" or "opening finds less work than advertised." The first trains people to ignore the number; the second trains them to read it as a click lure. Both strip real pending work of its scheduling value.
Consistency is cross-surface. If the shade says 3, the in-app inbox says 1, and the home-screen numeral says 12, nobody knows which to trust. The three figures must be projections of one pending set, not three counters.
Studying it
Put people in the loop "numeral → open app → handle" and compare the number with tappable pending objects. After the first mismatch, watch whether the numeral is still used as a scheduling signal.
Independent variables: whether the count includes already-read items, expired items, or in-app consumed state; whether surfaces share one set. Dependent variables: gap between numeral and handleable items, empty-open rate, later drop in glances or taps on the numeral.
A single lab task will not show "I stopped using the number." Repeat across days, or look at open rates for users whose numeral has been nonzero for a long stretch. Open count is not health—an inflated numeral can raise opens while destroying the numeral as a to-do.
Where it stops holding
"Unread" and "unhandled" are different sets: opened-but-unreplied mail may still be work. The product must say which it counts and use that word consistently. Shared inboxes collide person-counts with thread-counts; pick one unit and sort the post-open list by the same unit. Offline lag is allowed, but the first draw after returning to the foreground should converge—sync delay must not be presented as new work.
Applying it
- Count only objects that, after open, can be tapped and given a next step. Exclude read, expired, and display-only sync.
- Drive the home-screen numeral, the shade summary count, and the in-app unhandled list from one source.
- Name the unit: threads or items. Mixing them makes "3" mean different things on different surfaces.
- Verify by recording the numeral before open and counting truly handleable objects after. A nonzero gap means the inclusion rule is wrong, not the typeface. A week of a nonzero numeral with nothing to handle means the number has stopped being a to-do.