Badge

Before badges, the only way to find out whether anything new had arrived was to go and look. Open the inbox, check the top of the list, find nothing, back out — ten times a day. Wasted trips add up, and people stop checking altogether. From then on, things that did arrive sit untouched for days.

Pagedeck ran into exactly this when it shipped comments on documents. Sofia came back from a customer meeting with a complaint: the customer had left review notes and never heard anything back. The comments were there, filed against the right paragraphs. Nobody on the receiving end had a reason to reopen that document, so nobody did.

Other ways of announcing the comment existed, and each gave something up. A toast shows for about three seconds and then disappears, so anyone not looking at the screen in that window never gets the message. A banner pins to the top of the page and can't be missed, but it takes real space, and raising one for every arrival pushes the content down. Email leaves the product entirely, with no guarantee the reader comes back.

A badge fills the gap. It takes almost no space and stays until the user deals with what it points at. The trade is that it carries almost no information — one number, or one dot. It can't say what arrived, only that something did. In exchange it can sit on screen indefinitely without breaking the layout around it.

A badge is one target plus one value laid on top of it. The target is something already on screen — an icon, a menu item, an avatar — and the value is either a number or a single dot. The badge itself isn't clickable; any tap belongs to the target underneath.

The value takes one of two forms.

1. Count badge — it counts things. Three unread notifications show up as a 3.
2. Dot badge — no number, just the fact that something is there. The marker saying a new option appeared in settings works this way.

The choice comes down to whether the count changes what the user does next. If someone reads everything whether there are 2 messages or 40, counting earns nothing and a dot carries the same information. Someone whose day differs at 1 pending approval versus 12 needs the number.

Once the form is settled, four more decisions follow. Skip them and each one surfaces as a bug after launch.

1. The cap — most products count to 99 and render anything above as 99+. Print 1,284 as it is and the badge shoves the text beside it sideways, knocking the menu row out of alignment.
2. Zero — when there's nothing to count, remove the badge rather than showing a 0. A badge reading zero announces that something is waiting while saying nothing is, and the user checks anyway.
3. What clears it — decide whether the number drops when the list opens or when an individual item opens. The two produce very different results. If three comments vanish at once from someone who glanced at the list and left, those comments are hard to find again.
4. When it refreshes — recompute the count each time the screen loads, or push it from the server whenever it changes. The first is far easier to build, but anyone who leaves a tab open sits with a stale number for hours.

Because a badge conveys meaning through color and size alone, accessibility becomes a concern immediately. The same fact has to reach someone who can't distinguish the red circle, so the element carries a screen-reader label — "3 unread notifications" — spelling out what the badge says visually.

Badges land in three kinds of places.

The first is a doorway. Attach one to an app icon, a menu item in the navigation, or a tab, and it reports that there is something to handle behind that door. The whole point is carrying news from a screen the user isn't looking at.

The second is a row inside a list. Put a comment count at the end of each row in a document table and the reader sees where discussion piled up without opening anything.

The third is a status label. Instead of a count, a short word describes what this item is: "Beta" next to a plan name, "Admin" next to a person, "Expired" next to a document title. The first two press the user to deal with something; this one just classifies.

All three share one constraint: how many you put on a screen. Attach badges everywhere and the effect is the same as attaching none. When Pagedeck's sidebar was first built, Noa put a red dot on notifications, comments, and share requests alike, and all three stayed lit permanently, so none caught anyone's eye. Today only notifications carry a number.

Keeping the rules consistent across screens means registering the badge in the design system as a component. Color and size go in, and so do the cap and the zero behavior — written in one place rather than re-decided per screen.

"Can we use a dot here instead of a number? The count doesn't change what anyone does on this screen."

There's no payoff in counting, so just signal that something exists.

"The app icon badge says 3 but there's nothing inside. I think the counting is out of sync."

A bug report: the number the server computed and the number the screen computed disagree.

"That should be a chip, not a badge. It's a spot where clicking it needs to apply a filter."

Something that has to be interactive was built as a passive marker.

When Pagedeck added the unread-comment badge, each person worried about a different part. Noa pointed out that the sidebar fit only two digits and proposed capping at 99+. Theo argued against pushing the number in real time, since every open document adds another live connection, and suggested recounting every 30 seconds. Mia asked when the number goes away, and the three settled on decrementing only when an item is actually opened. One badge turned into a decision about width, refresh interval, and what counts as read.

The most common mistake is treating a badge as an attention device. People click red dots, so more dots look like more visits. The effect runs the other way. After a few taps that lead to nothing worth seeing, users learn to ignore that color. Mixing promotions and real pending work into the same badge produces a screen nobody taps within a couple of months, and leaves nothing to reach for when something urgent comes up.

The second mistake is reading a cleared badge as proof that the user read the content. The marker is gone, so the message looks delivered. What the badge reports is that the read condition was met, and that condition is mechanical: the list was opened, or the item was opened. Treat it as evidence of reading and you get a steady stream of cases where one side is certain they announced something and the other never saw it.