Banner

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?