The Product-Obsessed’s Guide To: Badging
Here at Cord, we love thinking of, talking about, and mapping the patterns of product UX in a LOT of detail. It’s a hobby of reflecting, refining, and polishing… an obsessive interest in the nitty gritty details of product design. This blog is part one of a series about the different components that make up most of our digital experiences, why they matter so much, and what good (and bad) looks like.
In a previous post, we talked about notifications, and why they’re so tricky to build. The toughest part involves answering the all-important (but difficult-to-answer) question: how and when should we notify users?
Once that’s mapped out, it’s up to badges - the ubiquitous dots and circles with numbers that live at the top of our social media feeds, to the left of our chats on Slack, and all over our smartphone homescreens - to help users navigate to all the places that need their attention.
Why is badging so important?
Badging might be a small UI element, but it shouldn’t be an afterthought. It’s an essential cue that leads users to the most important thing they need to do.
There are two states your users can be in: proactive mode and reactive mode.
In proactive mode, they’re actively and independently seeking to accomplish something in your product. They have a specific task, and they’re looking for the quickest path to complete it. It could be adding an employee to an HR system, launching a marketing campaign, or changing a setting in a DevOps tool.
In reactive mode, users are collaborating with, or being guided by, a system or another user to complete a task, or series of tasks. It could be a reminder to approve a holiday request an employee has logged in an HR system, an alert in a marketing tool that an ad budget has been spent, or a comment from a developer asking for help understanding something in a particular log.
When users are in reactive mode, badges are essential cues. They’re breadcrumbs that tap into human’s psychological urge to ‘clear’ them and get to the blissful zero. A clean, zen state, that helps nudge people to complete the tasks on their to-do lists 🧘🏽♂️
But badges are very easy to get wrong, with terrible, subtle consequences for users.
When products get badging wrong
When badges are misused, implemented incorrectly, or thrown in as an afterthought, users learn to ignore them. The red dots that are meant to be beacons - red being such a stark, rarely used color in digital UIs - instead become noise that the eye learns to filter, and the user ignores.
This happens more often than you might think.
Badges might be too simple or small. They might notify you of the wrong things. They might make the path to the notification itself unclear.
A good, popular example of terrible badging is LinkedIn. Specifically, LinkedIn’s extended suite of products like LinkedIn Sales Navigator and LinkedIn Recruiter. Let’s see how LinkedIn Sales Navigator screws up badging in every possible aspect.
In LinkedIn Sales Navigator, badges don’t lead you to a path that tells you what to do to clear them. Here, LinkedIn tells me my Sales Nav has 8 notifications.
But clicking the Sales Nav icon brings me to a page with just two red dots, with no numbers. It’s not clear what items are unread and contributing to the 8 notifications I was alerted of in the Sales Navigator, nor is there any visual difference between the items in ‘All alerts’ that are new vs ones that are old.
While I (now) know that the “Home” tab is connected to “All Alerts”, there’s nothing to stop me from thinking it’s connected to the other seven elements on the Home page: Bookmarked alerts, Book of business, Personas, My priority Accounts, or all the way down at the bottom, the “Coach”.
Which of these was meant to contain the promised 8 items that needed my attention?
The eagle-eyed amongst you will notice that, in that last screenshot, there’s no longer a badge on “Home”. That’s because once I click anywhere out of Home, it disappears. I’ve unknowingly cleared some (or all!?) of the 8 notifications I was alerted of. But I didn’t even scroll down the page. How do I know which ones I have and haven’t seen?
Inconsistently, the opposite behavior happens with the Messaging badge in Sales Navigator.
Again, it’s clear I have messages, but the un-numbered red dot gives me no signal as to how many, nor does it make it clear which messages are counted towards the badge. While you’d certainly think it’s unread messages…it’s not.
You can see I have no unread message (I got to the blissful zero!) but the badge doesn’t update, even if I click out and into the Messaging tab again. So much for a clean, zen state ❌🧘🏽♂️. This frustrating experience isn’t a rare bug. The product launched years ago, and the badging behavior hasn’t been fixed.
But it’s not just the UI. It’s also what they notify me about. (Remember: the toughest part about notifications is deciding how and when to notify users!)
Typical of a product that is confused about its role as a social media tool driven by advertising, and a work tool paid for per seat, it sometimes badges the notifications section to tell me about a new feature or promotion they are running. This, combined with everything else I detailed above makes me distrust and - worse - ignore their badging.
Unfortunately, LinkedIn’s huge asset - its network and exceptionally strong network effects - means that it likely won’t care about fixing the product’s many UX shortcomings, even in a surface like Sales Navigator that’s paid for as a subscription (costing many multiples of what, say, a Slack or Notion subscription costs). But that’s a topic for another rant.
On the topic of Notion, though…
When products get badging right
Notion have justifiably built themselves a trusted, beloved brand well-known for sweating the small stuff (in a good way!). Like us at Cord, they obsess about tiny user interaction details and work hard to ensure the experience is bug-free and high-quality. It is a productivity tool, after all.
Their badging is a great example of that.
Notion starts by telling me I have 14 notifications.
When I click the “hamburger” menu button, it immediately shows me what exactly feeds into the number 14.
There’s 1 hiding behind the “WaystarRoyco” org selector, and 13 more in Updates. When I click the WaystarRoyco selector, this behavior continues like a Matryoshka doll 🪆.
The 1 extra notification comes from the “Shiv’s Notion”. (Can you tell I’m a Sucession fan?) That’s the ‘breadcrumbing’ of notifications I was talking about, leading me to the right place, where there’s something for me worth paying attention to.
Second (and unlike LinkedIn) it’s crystal clear which items need to be cleared, and how to clear them.
The blue badge next to the highlighted items tells me that particular notification contributes to the 13 unread items, whereas the ones without the blue dot don’t. There’s a consistency at play here - blue dots without a number represent one item. The sum of the blue dots equals the number on the badge. And when I mark an item as read, Notion instantly updates counts everywhere.
Notion goes above and beyond and even lets users ‘unclear’ items, using an ‘explicit’ clearing behavior that treats these notifications as work items to be addressed one by one.
On both badges, the number 13 instantly updates to 14 when I click “Mark this notification as unread”, and drops down to 12 when I read or reply to an item. This might not seem like much, but it certainly is compared to LinkedIn where I have no unread messages and the “Messaging” tab still refuses to clear the badge, even as I go back and forth between the “Home” and “Messaging” tab in the product. I told you we humans have an undeniable psychological urge to ‘clear’ notifications…
One last small, admirable detail about Notion. The product team and engineers know it’s a work tool. So while new features like their AI bot or new Projects tool will get pushed heavily in-product, they won’t interfere with badging, and they won’t use the notifications surface to tell me about them.
Coming from years in Facebook’s Growth team, I’m all too familiar with the allure of using surfaces like notifications - which are hotspots for user attention - to promote a new feature to ‘juice’ metrics. But it’s a slippery slope that could easily backfire, and cause users to distrust and ignore notifications and, ultimately, disengage with your product.
How can I build a great badging experience in my product?
Want to consolidate the musings I’ve shared about Notion and LinkedIn and make a better badging experience for your users? There are four fundamental questions you have to answer.
1. What does the badge count?
This sounds simple enough. But in practice, there are a lot of options.
Imagine someone has made changes to a document on Google Docs or a page in Notion, and you want to alert a user of the changes. What do you count? You could count all edits to a page, or you could count the document or page as a single item that has changed, and instead tally how many documents have changed. What about comments? You could count individual comments in the doc, or count comment threads instead. You could only count comments that mention the user…
Maybe you should just count “notifications”. After all, if you’re at the point of exploring badging you should have already done the hard work of figuring out when to notify users. But what if a single message gets 6 replies, or 10 ”likes” 👍? Does the badge increase by 1, 6, or 10?
These questions are hard to answer correctly, and easy to get wrong.
It’s very tempting to count different things in different surfaces, like counting unread notifications in a Notification bell, counting threads in an in-product Inbox, and counting changes to individual documents in a separate navigation. But don’t do it! Each of these counts will update differently as a user navigates to a page with a comment and reads it, and consistency is key when building a great badging experience.
The best products choose a single unit and notify users about that unit. A “dirty” little secret of Notion’s is that they suffered from the same issue. A previous iteration had both a count of page changes and a count of comments. This was before they settled on using badging just for comments. Now, they track page updates separately in the “All” tab of their “Updates” section, without a badging behavior or a count.
Once you’ve decided what the badge counts, please, please, please make sure your badge counts sum up correctly when navigating a complex hierarchy.
It’s incredibly frustrating to find you have “2” notifications, that turn out to be 8 in one page and 3 in another, which means after you’ve dealt with 3 items, you might still have a badge of 2, or 1, depending on which ones you cleared.
This happens a lot with products where you can take the role of multiple users or organizational contexts (like an email client with multiple inboxes), where the badge for the overall app is not a sum of the badges of all the underlying ‘inboxes’. Superhuman email suffers from this. Slack does not. The overall app badge count is the sum of all badges in all of your Slack Workspaces.
2. What happens when users click on the badge?
Badges are meant to lead us somewhere in the app where there’s an action for us to take or information to read. That means that every click on a badged item must immediately show, somewhere on the screen, the next thing that’s badged. (Remember the Notion example? When I clicked the ‘hamburger’ menu button, I immediately saw what exactly was feeding into the number 14 on the badge.)
It’s like a weird game of Where’s Wally, and it’s very frustrating when Wally isn’t even on the page or above the fold.
Just like a good notification experience deep links and scrolls you to the context the notification is referring to, a good badging experience has the badge appear in the main view (or in an always-visible menu), and every click leads to another evident badge until you get to the individual items to clear, which themselves should be badged, usually with just a ‘dot’ rather than a ‘1’, to indicate there’s no further drill-down to do.
3. What’s the clearing behavior for your badges?
There are two approaches here: explicit clearing and implicit clearing. Explicit clearing means the user needs to take an action like “mark as read”, “resolve” or “archive” for the item to be marked off and disappear from the badging counter.
Implicit clearing means the item is marked off and the badging counter is updated automatically after a user has engaged with it. There are several ways to do this, one of which is simply checking if the item was on the screen and in focus long enough for the user to read it, and clearing the badge accordingly.
Regardless of whether you use explicit or implicit clearing, it’s often best to create more than one path to clear a badge. (But be careful. This can get messy, especially with sloppy implementations.)
For example, imagine a user is tagged in a comment. Does replying to the comment clear it? What about “liking” it? Deleting it? It should - so make sure your code considers all of these cases. But what if a whole document is deleted? The comments in that document should be removed from a notification list and badge counter, right? What if the badge doesn’t clear? Users would forever be haunted by a bright red badge, with no way to access the items they’re being notified about. The horror (seriously)! That means there either has to be some way to clear the badge, even if the items no longer exist, or you need to ensure your code paths on badging are water-tight on all of these cases.
Of course, you can’t discuss clearing without talking about how to change something that’s previously been marked ‘read’ back to ‘unread’. Especially in the context of products people use at work, it’s often an important feature because it gives people a way to keep track of tasks and information and stay on top of their to-dos. It’s actually a mark of a great badging system if people use your ‘Mark as unread’ feature as a reliable source of truth for their tasks.
4. How do I build and maintain stable badging infra?
Finally – more on the code side, but no less important – there are subtle challenges in actually building web products with the kind of live, real-time badging behavior that’s required for a great experience.
Not only do people expect badges to clear in real-time after they’ve interacted with the items (recall Notion’s instant updates vs. LinkedIn’s obstinate Messaging badge) but they also naturally expect them to be cleared based on other people’s actions. For example, a co-worker sending and deleting a message, deleting a document containing comments, or dealing with an issue that was badged as a system notification.
So, how do you do it? You need to keep a live-updating websocket hooked up to all the badges that appear on the screen, and make sure that it updates as soon as users return to focus, even if the browser tab was inactive long enough for the websockets to disconnect. This requires writing the code in a way that asks for a full update - not just listens to incremental state updates - upon connecting.
There you have it! A comprehensive guide to designing your badging behavior across your app, from one product-obsessed person to another.
One last thing before you go (shameless plug!) the team here at Cord have spent hundreds of hours sweating over the details to build the best APIs and infra for best-in-class badging experiences. Check out our Notification List Launcher for badging out-of-the-box, or explore our live hooks to easily create your own badges.