Notification Inbox Triage Model

Large Theory

A mature product may contain toast, inline message, banner, modal, badge, notification panel, and notification center surfaces at the same time. They carry different attention costs. If every event uses the same toast or the same red dot, users become fatigued, miss critical risk, or cannot find work to handle later. Notification inbox design is about triage: organizing messages by action required, informational update, failure/risk, system maintenance, collaboration mention, and archived state.

Small Points

1. Define event levels first: blocking, action required, warning, info, success, and ambient update. Do not give every event a red dot.
2. Badges are only supplemental counts or states on an existing entry point. Important content should be visible in the page or inbox itself.
3. Each notification needs source object, event, time, state, available action, and return path, such as project, comment, approval, billing, or security settings.
4. Read/unread, seen/unseen, archived/dismissed, snoozed, and failed/retry are different states, not one read boolean.
5. Bulk mark-read, archive, mute, and filter actions apply only to the current scope and should show count plus undo path.
6. Accessible notifications use live regions carefully. Not every state change should interrupt screen-reader users with an aggressive alert.

Design Judgment

The notification system is healthy when users can quickly tell what needs action now, what is merely recorded, where each item came from, and how state changes after triage. If a red dot creates anxiety without a triage path, it is noise.

Implementation Notes

Create a notification schema: id, sourceType, sourceId, actor, verb, object, severity, attentionLevel, createdAt, readAt, seenAt, archivedAt, snoozedUntil, primaryAction, secondaryAction, deepLink, deliveryChannel, and dedupeKey. The frontend separates toast, inline, banner, and inbox surfaces. The inbox provides tabs or filters, bulk operations, empty states, failed retry, and preferences. On mobile, do not rely only on a red dot; preserve count, latest summary, and entry path.

Counterexamples/Risks

All success messages enter the notification center, delete risks appear only as toast, one event duplicates repeatedly, badge counts have no explanation, archive means delete, bulk read has no undo, details are hover-only, and screen readers are interrupted by frequent alerts.

Case Study

Carbon's notification pattern separates inline, toast, actionable, modal, banner, notification panel, and notification center contexts. Material 3 badges show notification, count, or status on navigation items and icons. Atlassian section messages and flags cover section-specific alerts and lightweight confirmations. GOV.UK says notification banners should not replace form error summaries. The reusable lesson is that notification types should be chosen by attention cost and task scope, while the inbox is only one persistent triage pattern.

Source Links

Carbon notification pattern: https://carbondesignsystem.com/patterns/notification-pattern/ Carbon notification usage: https://carbondesignsystem.com/components/notification/usage/ Material 3 badges: https://m3.material.io/components/badges Atlassian designing messages: https://atlassian.design/foundations/content/designing-messages GOV.UK notification banner: https://design-system.service.gov.uk/components/notification-banner/