| 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. | Use notification banners sparingly for information users need before interpreting the page but that is not the main task content on that page. | 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 validation error appears in a notification banner at the top of the page with no links to the invalid fields. | The emergency message appears only on the home page, so users who land on Apply or Help do not see it. |
| 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 | Users give feedback but the link drops them on a generic contact page with no route context. | 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. | Users dismiss a critical emergency alert once and never see a later update because dismissal is not versioned. |
| 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 message should be encountered before the page H1 but is not the page's main task content. | Urgent public, safety, operating-status, outage, closure, or availability information applies to the whole site or service. |
| Avoid when | The service is live and no longer needs a pre-live phase label. | 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 | No phase banner state for live or phase-not-applicable services. | No-banner state when no broad-scope message applies. | No-banner state when no service-context notice or previous-page outcome applies. | No-site-alert state when no urgent sitewide condition applies. |
| 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. |