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

Banner

Place one scoped banner at the top of the related interface, state the broad condition and next step, persist it across affected routes, allow safe dismissal by message version, and retire or replace it when the condition changes.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • The message applies across several pages, routes, sections, records, or sessions.
  • Users need broad context before interpreting the affected content.
  • A non-modal top-of-interface message can explain the condition and next step without blocking work.
  • The product can manage scope, priority, lifecycle, and dismissal state.

Avoid when

  • The message affects only one field, object, row, panel, or local task section.
  • The message is a transient confirmation after one action.
  • The condition is an urgent current-task risk that must be noticed immediately.
  • The content region failed and needs recovery controls.
  • Several unrelated messages would need separate banners in the same scope.
  • The message has no expiry, owner, audience, or dismissal policy.

Problem it prevents

Users need to know broad product, service, account, section, or trust information before interpreting several related pages, but task-local messages, toasts, or dialogs would either detach the message from scope or over-interrupt work.

Pattern anatomy

What a strong implementation has to make clear

User need

A message applies to a whole product, service, workspace, account, section, or official site identity rather than one object or one immediate task.

Pattern promise

Place one scoped banner at the top of the related interface, state the broad condition and next step, persist it across affected routes, allow safe dismissal by message version, and retire or replace it when the condition changes.

Required state

No-banner state when no broad-scope message applies.

Recovery path

Users miss broad maintenance or policy context because it is hidden in a toast or local card.

Access contract

Use a labelled region or landmark when the banner is persistent page content that users may want to navigate to.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A billing workspace shows Scheduled maintenance Saturday directly below the product header across all billing pages, with View schedule and Dismiss when safe.
  • An official service identity banner sits above the service header on every page with consistent trust text and a disclosure for domain and HTTPS details.
  • A user moves from Overview to Invoices and still sees the same maintenance banner because the outage affects the whole billing workspace.
  • After a user dismisses a noncritical rollout banner, it stays hidden until a new message version or audience rule applies.
Weak implementation

Vague, hidden, hard to recover from

  • Three unrelated banners stack above the page heading and push the account task below the fold.
  • A banner floats sticky over Save and Continue controls while users scroll the form.
  • A field validation error appears in a banner, forcing users to hunt for the failing input.
  • A resolved service-delay banner remains visible and keeps users from trusting current processing times.
UI guidance
  • Render the banner at the top of the interface or content area it governs, below required global chrome and before the page content that should be interpreted with that message.
  • Keep the banner concise, visually distinct, and scoped to one broad product, service, account, section, or trust message, with at most one primary action or link and a dismiss control only when hiding it is safe.
UX guidance
  • Use banners when users need broad context before continuing across several pages or sections, such as maintenance, service delay, account setup, rollout, policy, or official-site identity information.
  • Manage banner lifecycle deliberately: define audience, start and end conditions, route scope, priority against other messages, dismissal memory, and what replaces the banner when the issue resolves.
Implementation contract

What the implementation must handle

States

  • No-banner state when no broad-scope message applies.
  • Informational product or service banner at the top of the related interface.
  • Warning or error-tone banner for broad service impact that does not block the current task.
  • Official identity or trust banner that stays consistent across every page in its scope.

Interaction

  • The banner appears before users encounter content affected by the message.
  • The banner title names the broad condition, audience, or trust claim rather than a severity label alone.
  • A banner persists while users move among affected sections and disappears outside its defined scope.
  • Details, links, and actions are optional, concise, and clearly tied to the broad condition.

Accessibility

  • Use a labelled region or landmark when the banner is persistent page content that users may want to navigate to.
  • Use status or alert semantics only for dynamic messages whose urgency justifies announcement without focus movement.
  • Keep the banner in reading order before the content it qualifies.
  • Do not rely on color, icon, or placement alone; include text that names the scope and condition.

Review

  • What exact product, service, account, section, or site scope does this banner govern?
  • Should users see this before the page heading, below service navigation, or only inside one task area?
  • Is this broad enough for a banner, or should it be an alert, inline message, toast, error summary, or error state?
  • What is the single highest-priority banner for this scope right now?
Interactive lab

Inspect the states before you copy the pattern

Manage broad interface messaging

Switch banner scope, move between workspace sections, reveal schedule details, dismiss a safe rollout message, and verify the banner persists only where its scope applies.

Banner
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

No-banner state when no broad-scope message applies.

Keyboard / Access

Tab reaches banner links, detail toggles, and dismiss controls in reading order before affected content.

Avoid Generating

Using a banner for one field error, one row warning, or one card status.
Evidence trail

Source-backed claims behind this guidance

Carbon Design System Notifications Pattern

IBM Carbon Design System - checked

Carbon distinguishes banners as product or system-level messages that sit at the top of the related content area, persist until dismissed, and should not cover content.

GOV.UK Design System Notification Banner

GOV.UK Design System - checked

GOV.UK describes notification banners for broad service problems, personal deadlines, and previous-page outcomes, with placement before the page heading and sparing use.

Full agent/debug reference

Problem Context

  • A message applies to a whole product, service, workspace, account, section, or official site identity rather than one object or one immediate task.
  • Users may enter affected pages from deep links and need context before reading the page heading or starting work.
  • The message may need to persist across routes, sessions, or audiences until a release, maintenance window, identity requirement, or account condition changes.
  • The message can be understood from a short title and sentence, with optional details or a link for more information.

Selection Rules

  • Choose banner when the message scope spans multiple pages, sections, records, or sessions in the same product, service, account, or workspace.
  • Place product or system banners below the main product header or navigation and above the content area they affect.
  • Place service or page-flow banners immediately before the page heading when users need the message before interpreting the page.
  • Use alert instead when an urgent condition affects the current task now and requires immediate notice.
  • Use inline message instead when the message belongs beside one visible object, row, panel, field group, or form section.
  • Use toast notification instead when the message is low-consequence feedback that can safely expire.
  • Use service navigation or header patterns for identity and movement; use a banner only for the message layered onto that structure.
  • Show one highest-priority banner per scope and combine closely related broad messages instead of stacking them.
  • Remember dismissal by message version, audience, and scope so users are not forced to close the same noncritical banner on every route.

Required States

  • No-banner state when no broad-scope message applies.
  • Informational product or service banner at the top of the related interface.
  • Warning or error-tone banner for broad service impact that does not block the current task.
  • Official identity or trust banner that stays consistent across every page in its scope.
  • Expanded detail state for schedule, domain, policy, or rollout explanation.
  • Dismissed state for safe noncritical banners, scoped to message version and audience.
  • Resolved or expired state after the underlying broad condition ends.
  • Priority state where a higher-impact banner replaces lower-priority messages instead of stacking.

Interaction Contract

  • The banner appears before users encounter content affected by the message.
  • The banner title names the broad condition, audience, or trust claim rather than a severity label alone.
  • A banner persists while users move among affected sections and disappears outside its defined scope.
  • Details, links, and actions are optional, concise, and clearly tied to the broad condition.
  • Dismissing a banner hides only safe, noncritical messages and can be reversed through an obvious route when needed.
  • The banner does not cover content, trap focus, or stay sticky over primary controls unless that behavior is explicitly required and tested.
  • When multiple broad messages compete, the product chooses one visible banner by priority or combines closely related messages.

Implementation Checklist

  • Define the banner's scope: product, service, workspace, account, section, official identity, or page-flow.
  • Decide whether the banner belongs above global navigation, below global navigation, below service navigation, or immediately before the page heading.
  • Write short copy that explains what is happening, who is affected, when it applies, and what users can do next.
  • Limit the banner to one link or action unless the message is a formal identity disclosure.
  • Store dismissal state by message id, version, audience, and scope rather than a single global hidden flag.
  • Set start, expiry, and resolved states so stale banners do not remain after maintenance, rollout, or policy windows end.
  • Choose landmark, region, status, or alert semantics according to urgency and whether the banner appears dynamically.
  • Test routing, deep links, mobile wrapping, zoom, scroll, dismissal, reappearance after version changes, and interactions with skip links and service navigation.

Common Generated-UI Mistakes

  • Using a banner for one field error, one row warning, or one card status.
  • Stacking several unrelated banners above the page content.
  • Making a banner sticky so it covers navigation, headings, form actions, or reading content.
  • Using a banner for a current-task emergency that needs an alert or blocking recovery.
  • Letting users dismiss a critical unresolved condition with no later access.
  • Showing the same dismissed banner on every route because dismissal is not versioned.
  • Keeping an outage, rollout, or deadline banner visible after the condition has ended.
  • Customizing official identity banner text until it no longer provides a recognizable trust signal.

Critique Questions

  • What exact product, service, account, section, or site scope does this banner govern?
  • Should users see this before the page heading, below service navigation, or only inside one task area?
  • Is this broad enough for a banner, or should it be an alert, inline message, toast, error summary, or error state?
  • What is the single highest-priority banner for this scope right now?
  • Can users dismiss it safely, and what message version should make it reappear?
  • What event, date, release, or system state removes or replaces the banner?
Accessibility
  • Use a labelled region or landmark when the banner is persistent page content that users may want to navigate to.
  • Use status or alert semantics only for dynamic messages whose urgency justifies announcement without focus movement.
  • Keep the banner in reading order before the content it qualifies.
  • Do not rely on color, icon, or placement alone; include text that names the scope and condition.
  • Make dismiss and detail controls keyboard reachable and give dismiss controls names that include the banner subject.
  • Keep skip-link and service-navigation order coherent when banners appear above page content.
  • Avoid sticky banners that obscure content at high zoom or while keyboard focus moves.
Keyboard Behavior
  • Tab reaches banner links, detail toggles, and dismiss controls in reading order before affected content.
  • Enter or Space activates the detail toggle and updates expanded state.
  • A dismiss control removes the banner without moving focus to a hidden element.
  • If dismissal reveals the page heading or service navigation, focus moves to the next meaningful control or remains on a stable nearby element.
  • Route changes preserve banner state across affected pages and do not reset focus into the banner unless the user requested it.
Variants
  • Product banner
  • Service banner
  • Account banner
  • Section banner
  • Maintenance banner
  • Feature rollout banner
  • Official identity banner
  • Dismissible banner
  • Expandable banner detail

Verification

Last verified: