UX Patterns Guide
UI + UX Feedback, Status, And System State standard

Notification center

Create a durable notification center with a stable entry point, explicit unread and unseen semantics, chronological and filterable items, direct routes to related work, preference controls, predictable cleanup, and escalation rules for messages that need immediate in-context treatment.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Users receive multiple asynchronous updates across objects, jobs, collaborators, approvals, or reminders.
  • Users need to revisit, triage, filter, or act on notifications after the initial arrival moment.
  • The product can maintain notification state, retention, preferences, and related-object cleanup rules.
  • Transient and in-context surfaces need a durable companion rather than carrying the whole message burden.

Avoid when

  • The product has only occasional current-action feedback that a toast or inline status can handle.
  • The message blocks the current task and must be visible in context now.
  • The update belongs beside one visible object or field.
  • The message is a broad system, service, workspace, or public-site notice.
  • The team cannot maintain read state, cleanup, retention, or preference behavior.

Problem it prevents

Users receive asynchronous work updates, mentions, background-job results, reminders, and system messages across many objects, but transient toasts, local alerts, or email alone make those messages easy to miss, impossible to triage, or noisy enough to ignore.

Pattern anatomy

What a strong implementation has to make clear

User need

Notifications are generated by system events, collaboration activity, background jobs, reminders, approvals, comments, assignments, or policy checks across multiple objects.

Pattern promise

Create a durable notification center with a stable entry point, explicit unread and unseen semantics, chronological and filterable items, direct routes to related work, preference controls, predictable cleanup, and escalation rules for messages that need immediate in-context treatment.

Required state

Closed entry-point state with zero, new-unseen, and unread-but-seen counts.

Recovery path

Users miss important work because expired toasts had no durable notification-center item.

Access contract

Give the entry-point control an accessible name that includes new or unread count without relying only on a red dot.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A bell opens a drawer with Unread and All filters, showing comment mentions, approval requests, export results, and background-job failures in newest-first order.
  • A notification item shows source, object name, timestamp, read state, one primary action, and a secondary mark-read control.
  • Opening the notification drawer clears the new-notification badge while unread items remain available for later triage.
  • After the user opens the mentioned pull request from another route, the matching notification is marked read or removed from actionable lists.
Weak implementation

Vague, hidden, hard to recover from

  • A red badge says 42 forever because opening the drawer, reading items, and viewing related work never update the count.
  • Expired toast messages are copied into a center with no timestamps, no source, and no route to the affected object.
  • A payment failure that blocks the current checkout is only stored in the notification center and never appears in the task.
  • Users mark all notifications read and lose the only record of an export job they still need to download.
UI guidance
  • Provide a persistent notification entry point, usually a bell or inbox control, with a count that represents new unseen notifications rather than every unread item forever.
  • Render the center as a drawer, panel, page, or tray with chronological items, clear read and unread states, filters, timestamps, source labels, and direct actions or links to the related object.
UX guidance
  • Use a notification center when users receive enough asynchronous system or collaboration updates that they need a durable place to review, triage, and act later.
  • Design the notification lifecycle deliberately: what creates an item, what increments the badge, what marks it read, what clears it after related work is viewed elsewhere, and what preferences reduce noise.
Implementation contract

What the implementation must handle

States

  • Closed entry-point state with zero, new-unseen, and unread-but-seen counts.
  • Open drawer or page state with newest-first notifications.
  • Unread, read, selected, and actioned item states.
  • Unread-only, all, source, urgency, or type filter states.

Interaction

  • The entry point opens the notification center without navigating away from the current task unless the product uses a dedicated full page.
  • Opening the center clears the unseen badge count but does not automatically mark every item read unless the product explicitly communicates that policy.
  • Each item names the source, event, related object, timestamp, current read state, and one direct destination or action.
  • Filters never delete notifications; they only change which items are visible.

Accessibility

  • Give the entry-point control an accessible name that includes new or unread count without relying only on a red dot.
  • Announce new notification arrival with status semantics when appropriate, but avoid interrupting users repeatedly for low-priority center items.
  • When the drawer opens, place focus on the panel heading or first useful control and return focus to the entry point on close.
  • Represent unread state in text and programmatic state, not only color or font weight.

Review

  • Which notification types deserve a durable center item instead of only a toast, email, inline message, or activity log entry?
  • What exact event increments the badge, and what event clears only the unseen count?
  • What makes an item read: opening the center, selecting the item, viewing the related object, or explicit mark-read action?
  • What happens when the related object is completed, deleted, archived, or no longer accessible?
Interactive lab

Inspect the states before you copy the pattern

Triage durable notifications

Open the notification center, clear the unseen badge without clearing unread items, filter unread notifications, mark one item read, suppress a toast into the center, and adjust preferences.

Notification center
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Closed entry-point state with zero, new-unseen, and unread-but-seen counts.

Keyboard / Access

Enter or Space on the notification entry point opens the center.

Avoid Generating

Treating the badge count, unread count, and total notification count as one number.
Evidence trail

Source-backed claims behind this guidance

Carbon Design System Notifications Pattern

IBM Carbon Design System - checked

Carbon describes notification panels as user-opened centers for system-generated messages and recommends chronological ordering, grouping, preferences, and avoiding repeated notifications.

Carbon Design System Notification

IBM Carbon Design System - checked

Carbon notification usage recommends notification centers when users need to revisit and act on past notifications after transient notifications disappear.

Full agent/debug reference

Problem Context

  • Notifications are generated by system events, collaboration activity, background jobs, reminders, approvals, comments, assignments, or policy checks across multiple objects.
  • Users may not be present when a notification is created and may need to inspect it later without searching email or activity logs.
  • Some notifications are useful only until the related object is viewed or resolved; others are durable evidence users may need later.
  • Users need tools to reduce noise without losing important work, such as unread filters, grouping, preferences, and mark-read controls.

Selection Rules

  • Choose notification center when messages must be revisitable after toast, push, email, or inline surfaces have disappeared.
  • Use it for asynchronous cross-object events such as mentions, review requests, assignment changes, export-ready notices, background-job failures, scheduled reminders, and policy acknowledgements.
  • Use toast notification instead for short current-action feedback that can disappear because a durable record is not needed or exists in a job history.
  • Use alert instead for urgent current-task conditions that must remain visible until resolved, such as session expiry, unsynced work, or payment hold.
  • Use inline message instead when the notification belongs beside one visible object, row, field group, or panel.
  • Use banner or site alert instead when the message applies broadly to a product, workspace, service, or public site rather than the user's notification history.
  • Separate unseen count from unread state so opening the center can clear the badge without destroying triage state.
  • Remove, collapse, or mark notifications read when users view the related object elsewhere, according to the product's cleanup policy.

Required States

  • Closed entry-point state with zero, new-unseen, and unread-but-seen counts.
  • Open drawer or page state with newest-first notifications.
  • Unread, read, selected, and actioned item states.
  • Unread-only, all, source, urgency, or type filter states.
  • Empty state for no notifications and no unread notifications.
  • Suppressed-to-center state where a low-disruption notification arrives without a toast.
  • Mark-one-read and mark-all-read states.
  • Related-object-viewed cleanup state where stale notifications disappear or become read.
  • Preference state for muting noisy sources or changing delivery channels.
  • Error or offline state where the center cannot refresh but preserved items remain visible.

Interaction Contract

  • The entry point opens the notification center without navigating away from the current task unless the product uses a dedicated full page.
  • Opening the center clears the unseen badge count but does not automatically mark every item read unless the product explicitly communicates that policy.
  • Each item names the source, event, related object, timestamp, current read state, and one direct destination or action.
  • Filters never delete notifications; they only change which items are visible.
  • Marking an item read, marking all read, archiving, or clearing a notification has immediate visible feedback and can be understood from the current filter.
  • Selecting a notification opens the related object in context and updates notification state predictably.
  • Muted sources, suppressed delivery, and channel preferences reduce interruptions without hiding critical current-task blockers.

Implementation Checklist

  • Define notification types, sources, recipients, delivery channels, retention period, and whether each type increments unseen count.
  • Model unseen, unread, read, actioned, archived, suppressed, stale, and expired states separately.
  • Design badge behavior for closed center, first open, subsequent opens, and cross-device viewing.
  • Sort notifications newest-first by received time and add source, object, timestamp, and urgency metadata.
  • Provide filters for unread and high-value sources before adding bulk actions.
  • Implement mark one read, mark all read, and optional archive or clear actions with reversible or understandable effects.
  • Synchronize notification state when the related object is viewed, resolved, deleted, permission-revoked, or completed elsewhere.
  • Provide preferences for noisy sources, delivery channels, digest frequency, and quiet modes while preserving critical in-context alerts.
  • Test keyboard opening, focus containment or return, screen-reader labels for badge counts, virtualized long lists, empty filters, offline refresh, and mobile drawer behavior.

Common Generated-UI Mistakes

  • Treating the badge count, unread count, and total notification count as one number.
  • Clearing all unread items just because the drawer opened.
  • Deleting notifications when a filter is applied.
  • Using the center as the only surface for critical current-task blockers.
  • Repeating the same notification every few minutes when the user has not interacted with it.
  • Leaving resolved or inaccessible notifications actionable.
  • Offering no notification preferences in products that generate frequent asynchronous messages.
  • Letting old notifications accumulate without retention, grouping, search, or cleanup rules.

Critique Questions

  • Which notification types deserve a durable center item instead of only a toast, email, inline message, or activity log entry?
  • What exact event increments the badge, and what event clears only the unseen count?
  • What makes an item read: opening the center, selecting the item, viewing the related object, or explicit mark-read action?
  • What happens when the related object is completed, deleted, archived, or no longer accessible?
  • Which sources can users mute, and which critical conditions must still surface in context?
  • How long should notifications remain, and where can users find older proof if it expires from the center?
Accessibility
  • Give the entry-point control an accessible name that includes new or unread count without relying only on a red dot.
  • Announce new notification arrival with status semantics when appropriate, but avoid interrupting users repeatedly for low-priority center items.
  • When the drawer opens, place focus on the panel heading or first useful control and return focus to the entry point on close.
  • Represent unread state in text and programmatic state, not only color or font weight.
  • Make filters, mark-read controls, item actions, and preferences keyboard reachable with visible focus.
  • Use headings, list semantics, timestamps, and source labels so screen-reader users can scan long notification sets.
  • Avoid automatically moving focus into the center for suppressed notifications.
Keyboard Behavior
  • Enter or Space on the notification entry point opens the center.
  • Escape closes a drawer-style center and returns focus to the entry point.
  • Tab moves through filters, bulk actions, notification items, per-item actions, preferences, and close control in a predictable order.
  • Arrow-key shortcuts may move within a list only when documented by native list or menu semantics; Tab remains sufficient.
  • Mark-read and filter changes update the visible list without moving focus to a hidden or removed item.
  • Selecting an item opens the related object and updates read state before navigation or focus transfer.
Variants
  • Bell drawer
  • Notification page
  • Unread filter
  • Grouped notification center
  • Actionable notification item
  • Suppressed notification center item
  • Preference-managed notification center
  • Archived notification history

Verification

Last verified: