31 patterns in this category — each with its illustration, what it is, and the fields that matter when you build or review one. Part of the UX pattern catalogue; the raw, agent-readable version is ux-pattern-catalogue/notification-patterns.json.
Ephemeral, non-blocking messages that appear briefly (3-5 seconds) and auto-dismiss. Use for confirmations, success feedback, and low-priority status updates that do not require user action. Position bottom-center (mobile) or bottom-right (desktop). Never use for errors that require acknowledgment.
A persistent or dismissible strip across the top of the page for system-wide announcements — maintenance windows, new feature launches, billing alerts. Higher visibility than toasts, lower disruption than modals. Use sparingly: more than one banner creates "banner blindness" (NN/G).
Browser-level notifications delivered via the Push API + Service Worker, even when the tab is inactive. Opt-in rates average 7-12% on web. Never show the browser permission prompt on first page load — pre-prompt with a custom UI explaining the value first (Smashing Magazine). Personalize content; generic blasts see <1% CTR vs 10%+ for behavioral triggers.
Platform-native notifications via APNs (iOS) or FCM (Android). Higher engagement than web push — average opt-in rates 50-60% (iOS asks explicitly; Android opts in by default). Delay permission request until the user has experienced value (NN/G). Limit to 2-5 per day for most apps. Include rich media (images, GIFs) for 25% higher click rates.
Transactional and digest emails for events the user should not miss — order confirmations, security alerts, weekly summaries. NN/G distinguishes transactional (triggered by user action) from system-generated. Always include an unsubscribe link (legally required: CAN-SPAM, GDPR). Batch low-priority events into daily/weekly digests rather than sending individual emails.
Full-screen or modal overlays triggered by context — onboarding prompts, upgrade nudges, feature announcements. Higher engagement than banners but more disruptive. Use for high-value, low-frequency messages. Never interrupt a user mid-task. Show only when idle or at natural transition points (page navigation, task completion).
Server-to-client delivery for real-time events — new messages, status changes, live updates. WebSockets for persistent bidirectional connections; Server-Sent Events (SSE) for unidirectional server push. Use SSE for simple notification feeds; WebSockets when the client also sends data (chat, collaboration).
The universal entry point to a notification center. A bell icon in the header/masthead with a numeric or dot badge indicating unread count. Clicking toggles a notification drawer or popover. The badge color communicates urgency: blue/default for unread, red for critical. Hide the badge (not the bell) when all are read.
A dedicated panel (popover, drawer, or full page) listing all notifications in reverse chronological order. The central hub where every notification channel converges. Visually distinguish read vs unread (background color or font weight). Group by time ("Today", "This week", "Earlier") or by type. Include "Mark all as read" action.
The individual notification entry in a list. Includes: avatar/icon, title, body text (truncated), timestamp (relative: "2m ago"), and optional action buttons. Unread items have a visual indicator (dot, bold text, tinted background). Clicking navigates to the relevant resource. Swipe actions on mobile (mark read, delete).
Contextual notifications embedded within the page content, near the element they relate to — form validation results, section-specific alerts, feature deprecation warnings. Unlike toasts, they persist and are part of the page flow. Use for information that is relevant only in context.
A badge on navigation items, tabs, or icons indicating pending activity — unread messages on a chat tab, new items in a feed, pending approvals on an admin link. Source-anchored badges (Facebook-style) let users see the category of notification at a glance without opening the notification center.
Shows ongoing operation status — file uploads, data exports, background job progress. Use a toast with a progress bar for short operations (<30s). For long-running tasks, show a persistent indicator in the notification center with percentage or step count. Allow users to navigate away without losing progress.
Binary state tracking for each notification. Unread items are visually distinct (bold text, tinted background, dot indicator). Mark as read on click/navigation, or provide explicit "mark as read" action. Batch action: "Mark all as read". Allow marking items as unread for follow-up. Unread count drives the bell badge.
Collapse related notifications into a single grouped entry — "3 people liked your post", "5 new comments on Project X". Reduces notification fatigue and list length. Group by entity (same post, same thread), by type (all likes together), or by sender. Expand to show individual items on click.
Instead of delivering every event immediately, batch notifications into periodic summaries — daily digest email, hourly in-app summary. Reduces interruption frequency dramatically. Let users choose cadence: immediate, hourly, daily, weekly. Facebook and LinkedIn use gradual grouping, releasing notification blocks at appropriate intervals.
Let users temporarily dismiss a notification and have it resurface at a chosen time — "Remind me in 1 hour", "Tomorrow morning", "Next week". Prevents notification from being lost while reducing immediate noise. Common in email (Gmail snooze) and task management apps.
Actionable buttons within the notification itself — "Accept", "Decline", "Reply", "View", "Archive". Let users act without navigating away. Limit to 2-3 actions maximum. Primary action should be prominent; secondary actions in a menu. Push notifications support up to 3 action buttons on both iOS and Android.
A searchable, filterable archive of past notifications that users can revisit. Not all notifications need to persist — auto-delete ephemeral ones (toast confirmations) after 30 days. Keep important ones (security alerts, receipts) indefinitely. Provide search and filter by type, date range, and read status.
A grid of notification types (rows) vs delivery channels (columns: in-app, email, push, SMS). Users toggle each cell to control exactly which events reach them on which channel. The HubSpot pattern — research showed this matrix format helps users set preferences faster than separate pages per channel.
Let users control how often they receive notifications — immediate, hourly digest, daily digest, weekly summary, or none. Basecamp offers "Always On" and "Work Can Wait" presets. Smashing Magazine recommends offering predefined modes: "Calm" (low frequency), "Regular" (medium), and "Power User" (high) as starting points.
A schedule-based silencing mode — suppress all non-critical notifications during set hours (e.g., 10 PM - 8 AM) or specific days (weekends). Slack popularized "Do Not Disturb" mode. Queue suppressed notifications and deliver them when quiet hours end. Always allow critical notifications (security alerts) to break through.
Allow users to disable specific delivery channels entirely — "Stop all emails but keep in-app" or "Turn off push notifications". Simpler than the full preferences matrix for users who want broad control. Must include legally required email unsubscribe (CAN-SPAM, GDPR). One-click unsubscribe in email headers (RFC 8058, required by Gmail/Yahoo since 2024).
A first-run experience that helps users configure their notification preferences before the defaults kick in. Ask during onboarding or after the user has experienced value (NN/G recommends delaying). Show 2-3 simple questions: preferred channels, frequency level, quiet hours. Provide sane defaults for users who skip.
The foundation of accessible notifications. An aria-live region announces dynamic content changes to screen readers without stealing focus. Use aria-live="polite" for most notifications (waits for idle). Use aria-live="assertive" or role="alert" only for critical errors or security warnings. Never double up: role="alert" already implies assertive.
Notifications must never steal focus from the user's current task. Toasts, banners, and real-time updates should be announced via aria-live regions without moving focus. Only modal dialogs (critical alerts requiring acknowledgment) may trap focus — and must return it to the trigger element on dismissal.
Craft notification text for screen reader comprehension. Include: what happened, who triggered it, and what action (if any) is needed. Keep announcements concise — screen reader users often navigate quickly. Batch rapid-fire updates into summaries rather than announcing each one. Test with multiple screen readers.
All notification interactions must be fully keyboard-accessible. Tab to the bell icon, Enter/Space to open the center, arrow keys to navigate items, Enter to activate, Escape to close. Notification actions (mark read, delete, snooze) must be reachable without a mouse. Swipe gestures on mobile must have keyboard equivalents.
Toast slide-ins, banner animations, badge bounces, and drawer transitions must respect the user's prefers-reduced-motion setting. Replace animations with instant appearance or gentle opacity fades. Some users experience motion sickness from sliding/bouncing notification animations.
Notification sounds and vibration patterns provide additional sensory channels but must never be the sole indicator. Always pair audio/haptic with visual feedback. Provide controls to adjust or disable notification sounds independently of system volume. Haptic patterns can differentiate notification types (short buzz = message, long = alert).
Ensure notification UI meets contrast requirements in both light and dark modes and under Windows High Contrast / forced-colors mode. Notification badges, toast backgrounds, read/unread indicators, and action buttons must all maintain WCAG AA contrast ratios (4.5:1 for text, 3:1 for UI components).