Use a phase or beta banner to label a service's maturity and collect feedback while it is still being worked on; use banner for broad operational context, notification banner for before-heading page-flow notices, and site alert for urgent sitewide status.
Use a phase or beta banner to label a service's maturity and collect feedback while it is still being worked on; use banner for broad operational context, notification banner for before-heading page-flow notices, and site alert for urgent sitewide status.
Practice the judgment: Imagine this situation: An alpha service is publicly exposed as if it were production-ready, so users trust an experiment as a live service. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Phase / beta banner | Banner | Notification banner | Site alert |
|---|---|---|---|---|
| UI or UX | UI + UX - Service phase and feedback marker | UI + UX - Top-of-interface broad-scope message | UI + UX - Page-flow service notification before the H1 | UI + UX - Urgent full-width sitewide alert near the top of every page |
| UI guidance | Render a compact phase tag such as Alpha or Beta with a short sentence and feedback link in the service header area, directly after service navigation or the primary header. | 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. | Render one notification banner in the page content column immediately before the page H1, using the same width as the surrounding service content. | Render the site alert as a full-width message near the top of the site, before ordinary navigation or page content users might otherwise start from. |
| UX guidance | Use a phase banner to set expectations that a service is still being worked on and to invite feedback that helps the team improve it. | 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. | Reserve the pattern for service-wide problems, personal deadlines or obligations elsewhere in the service, and outcomes from a previous page when the journey continues rather than ends. | Use a site alert when urgent public or servicewide information must be obvious and findable from any page, including deep links, refreshes, and routes outside the home page. |
| Good UI | A private beta benefits service shows a Beta tag directly below service navigation with Help us improve this service and a feedback link that preserves the current route. | A billing workspace shows Scheduled maintenance Saturday directly below the product header across all billing pages, with View schedule and Dismiss when safe. | A case-management page shows an Important notification banner immediately before Manage evidence, saying evidence upload may be delayed and linking to service status. | A public benefits site shows Emergency office closures at the very top of every page, with affected offices, updated time, and a link to alternate service channels. |
| Bad UI | A bright sticky Beta pill floats over the form submit button and competes with validation. | Three unrelated banners stack above the page heading and push the account task below the fold. | A success toast appears in the corner after redirect and disappears before the user can verify which evidence was uploaded. | Three large red alerts stack above the header, mixing closure, newsletter, and one form error. |
| Good UX | A user in public beta sees the service is still improving, reports a problem from the current page, and returns to the same application step. | A user moves from Overview to Invoices and still sees the same maintenance banner because the outage affects the whole billing workspace. | A user lands on Evidence overview and sees the upload confirmation before the page heading, then can continue the unfinished service journey. | A user enters through a bookmarked application-status page and still sees the same closure alert before using the service. |
| Bad UX | A beta banner is hidden after the first visit, so deep-linked users miss the service maturity signal. | A field validation error appears in a banner, forcing users to hunt for the failing input. | The same upload confirmation remains on unrelated pages after the user has already reviewed the evidence record. | Deep-linked users miss critical sitewide information because the alert exists only on the home page. |
| Best fit | A service is in alpha, private beta, public beta, or another explicit pre-live phase. | The message applies across several pages, routes, sections, records, or sessions. | A service problem, deadline, overdue action, or elsewhere-in-service event affects the user's next interpretation of the page. | Urgent public, safety, operating-status, outage, closure, or availability information applies to the whole site or service. |
| Avoid when | Only one feature, experiment, or setting is in beta inside an otherwise live service. | The message affects only one field, object, row, panel, or local task section. | The message is a submitted-form validation error or field correction. | The message applies only to one product workspace, account, section, page flow, field, row, or task. |
| Required state | Alpha state for limited prototype or research-only service. | Informational product or service banner at the top of the related interface. | Neutral Important state for service problem, deadline, overdue action, or elsewhere-in-service information. | Emergency site alert visible at the top of every affected page. |
| Accessibility burden | Place the phase banner in reading order after the header or service navigation and before page-specific content. | Use a labelled region or landmark when the banner is persistent page content that users may want to navigate to. | Use a labelled region for neutral page-load notification banners so screen-reader users can navigate to the notice. | Give the site alert a descriptive aria-label or labelledby value so it appears clearly in landmark navigation. |
| Common misuse | Using Beta as a decorative badge for a feature rather than the service phase. | Using a banner for one field error, one row warning, or one card status. | Using a notification banner for field validation errors instead of an error summary and field-level messages. | Showing a sitewide emergency only on the home page. |