Notification banner

Problem Context

• The message is important to the service journey but not directly part of the page's main task content.
• Users may arrive after a redirect from a previous page and need confirmation before continuing the journey.
• A service problem, personal deadline, overdue action, or elsewhere-in-service event affects how users interpret the page.
• The message can be handled with one short banner before the H1 rather than a modal, stacked banner set, or long status panel.

Selection Rules

• Choose notification banner when a service message should be seen immediately before the page heading and before users interpret that page.
• Use the neutral version for service problems, delays, deadlines, overdue actions, or elsewhere-in-service information that is not a direct validation or current-task error.
• Use the success version only to confirm an outcome from the previous page while the user has not finished the overall service journey.
• Use banner instead when the message must persist across a whole product, account, workspace, or multi-section interface rather than one page-flow moment.
• Use alert instead when an urgent condition dynamically affects the current task and needs immediate notice without moving users into a confirmation page.
• Use error summary instead for submitted form validation errors, including multiple field errors that need links to specific inputs.
• Use inline message or warning text instead when the information is directly about content, controls, or a task section already visible on the page.
• Show no more than one notification banner per page; combine closely related messages or show only the highest-priority one.

Required States

• No-banner state when no service-context notice or previous-page outcome applies.
• Neutral Important state for service problem, deadline, overdue action, or elsewhere-in-service information.
• Success state for an outcome from the previous page when users continue the journey.
• Linked action state where a single link or button takes users to the affected application, evidence record, payment, or status details.
• Detail state for a short explanation that clarifies why the message appears before the heading.
• Resolved state after the deadline passes, service delay ends, or the previous-page outcome has been acknowledged through the next step.
• Priority state where a validation error summary replaces the notification banner on failed submit.

Interaction Contract

• The banner appears before the page H1 and in the same content width as the heading and body text.
• The banner title communicates category or outcome, while the body names the specific service condition, deadline, or previous-page result.
• The banner does not stack with an error summary; failed-submit pages show the error summary instead.
• The neutral banner uses labelled region semantics so users can navigate to it without being interrupted.
• A success notification that appears after a user action may receive focus or alert treatment only when that helps confirm the previous-page outcome.
• Any link or action in the banner goes directly to the affected service item, status page, deadline task, or uploaded record.
• The banner disappears when the service condition, deadline relevance, or redirect-outcome reason no longer applies.

Implementation Checklist

• Define whether the notice is a service problem, personal obligation, deadline, elsewhere-in-service event, or previous-page outcome.
• Place the component immediately before the H1 in the page template, aligned to the same content grid as headings and body text.
• Select neutral or success presentation from the user consequence, not from brand color preference.
• Write copy that says what happened, who is affected, and the single next step or link if one exists.
• Suppress the notification banner when a form submission on the same page produces an error summary.
• Prevent multiple notification banners on one page by merging related content or applying explicit priority.
• Expire previous-page success banners after the landing page has been read, the linked record is opened, or the user moves outside the related flow.
• Test deep links, redirects, browser back, narrow widths, zoom, heading order, focus movement for success, and screen-reader navigation by region label.

Common Generated-UI Mistakes

• Using a notification banner for field validation errors instead of an error summary and field-level messages.
• Showing several notification banners before the same heading.
• Putting the banner after the H1, in a sidebar, or above unrelated global chrome where users cannot connect it to the page flow.
• Using it as a product-wide outage banner that needs to persist across many sections.
• Leaving a previous-page success banner visible after users navigate to unrelated pages.
• Auto-expiring a confirmation that users need to inspect after a redirect.
• Writing only Important or Success without the affected service item, date, or next step.

Critique Questions

• Does this message need to appear immediately before the page heading, or does it belong in the page content, a broader banner, an alert, or an error summary?
• Is the notice about a service problem, personal deadline, elsewhere-in-service event, or previous-page outcome?
• Would users still need this message after navigating to a different section or returning later?
• Is there already a failed-submit error summary that should replace the notification banner?
• What event removes the banner: condition resolved, deadline passed, landing page viewed, linked record opened, or flow completed?
• Does the banner contain one clear route to the affected item rather than several competing actions?