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

Phase / beta banner

Show a service-wide phase banner with the correct alpha or beta tag, concise maturity copy, and a feedback link that preserves route context; update or remove it when access, assessment, or live status changes.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A service is in alpha, private beta, public beta, or another explicit pre-live phase.
  • Users need to understand that the service is still being worked on before they use it.
  • The team needs route-aware feedback from users during the phase.
  • The service has a header or service navigation area where the maturity marker can appear consistently.

Avoid when

  • The service is live and no longer needs a pre-live phase label.
  • Only one feature, experiment, or setting is in beta inside an otherwise live service.
  • The message is an outage, maintenance window, deadline, validation error, success outcome, or cookie consent request.
  • The service cannot preserve user progress when opening feedback.
  • The label would be used as marketing rather than an accurate delivery-phase signal.

Problem it prevents

Users need to know when a service is still being developed and teams need phase-specific feedback, but generic banners, alerts, or badges either overstate urgency, hide service maturity, or detach feedback from the user's current journey.

Pattern anatomy

What a strong implementation has to make clear

User need

The service is in alpha, private beta, public beta, or another clearly governed pre-live phase.

Pattern promise

Show a service-wide phase banner with the correct alpha or beta tag, concise maturity copy, and a feedback link that preserves route context; update or remove it when access, assessment, or live status changes.

Required state

No phase banner state for live or phase-not-applicable services.

Recovery path

Users trust an alpha prototype as a public production service.

Access contract

Place the phase banner in reading order after the header or service navigation and before page-specific content.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • 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.
  • An alpha prototype shown to invited research participants labels the service Alpha and links to a feedback form about the prototype.
  • 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 team switches from private beta to public beta only after assessment and updates the banner copy to reflect wider access.
Weak implementation

Vague, hidden, hard to recover from

  • A bright sticky Beta pill floats over the form submit button and competes with validation.
  • A service outage is announced only through a beta banner, so users miss the current operational problem.
  • Users give feedback but the link drops them on a generic contact page with no route context.
  • A beta banner is hidden after the first visit, so deep-linked users miss the service maturity signal.
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.
  • Keep the phase banner visible across all service pages while the service is in that phase, but do not style it as an urgent alert, product announcement, cookie notice, or dismissible marketing banner.
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.
  • Tie the phase label to the actual delivery stage: alpha for limited prototype testing, private beta for invited users, public beta for wider real users before live, and no phase banner once the service is live.
Implementation contract

What the implementation must handle

States

  • No phase banner state for live or phase-not-applicable services.
  • Alpha state for limited prototype or research-only service.
  • Private beta state for invited users and controlled rollout.
  • Public beta state for wider access before live.

Interaction

  • The phase banner appears consistently across all pages in the service while the phase applies.
  • The tag text, service phase, access model, and feedback copy stay synchronized with delivery status.
  • Activating the feedback link opens a feedback route or email that knows the current page, then lets users return without losing progress.
  • The banner does not dismiss permanently because users can arrive on any route and still need phase context.

Accessibility

  • Place the phase banner in reading order after the header or service navigation and before page-specific content.
  • Use a text tag and sentence; do not rely on color alone to communicate Alpha or Beta.
  • Make the feedback link keyboard reachable and specific about destination or new-tab behavior.
  • Keep the banner compact so it does not obscure focus or push critical content unpredictably at high zoom.

Review

  • What phase is the whole service actually in, and who owns changing that label?
  • Is this an alpha prototype, private beta, public beta, live service, or feature-level experiment?
  • Can users give feedback from the current page without losing their place?
  • Should this be a phase banner, broad banner, notification banner, site alert, service navigation, tag, or feedback link?
Interactive lab

Inspect the states before you copy the pattern

Label service maturity and collect feedback

Move a service phase banner through alpha, private beta, public beta, feedback, phase transition, and live removal states across service routes; compare with stale beta, public alpha, outage misuse, feature badge, route-blind feedback, and dismissible phase misuse.

Phase / beta 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 phase banner state for live or phase-not-applicable services.

Keyboard / Access

Tab order reaches header controls, service navigation, phase feedback link, and then page content in that sequence.

Avoid Generating

Using Beta as a decorative badge for a feature rather than the service phase.
Evidence trail

Source-backed claims behind this guidance

GOV.UK phase banner component

GOV.UK Design System - checked

GOV.UK documents phase banners for services still being worked on, alpha or beta tags, service.gov.uk use until live assessment, placement after service navigation or header, service-wide display, feedback links, and preserving the user's place.

GOV.UK Service Manual alpha phase guidance

GOV.UK Service Manual - checked

GOV.UK Service Manual explains alpha as limited prototype testing of risky assumptions and says alpha services should not be available for public production use.

GOV.UK Service Manual beta phase guidance

GOV.UK Service Manual - checked

GOV.UK Service Manual explains private and public beta as real service building, feedback collection, controlled scale-up, assessment, and preparation for live.

Full agent/debug reference

Problem Context

  • The service is in alpha, private beta, public beta, or another clearly governed pre-live phase.
  • Users may enter the service through deep links and need the phase signal before reading page-specific content.
  • The team needs to collect on-page feedback about the developing service without interrupting the task.
  • The service may have service navigation, a GOV.UK-style header, ordinary broad banners, notification banners, site alerts, and footer feedback routes that must remain semantically separate.

Selection Rules

  • Choose phase / beta banner when the whole service is in alpha, private beta, or public beta and users need a service-wide maturity signal.
  • Use Alpha when the service is a limited prototype or experiment used to test risky assumptions and is not publicly available as a production service.
  • Use Beta for private or public beta: invited users first, then wider access after assessment when the team is preparing for live.
  • Remove the phase banner when the service passes live assessment or no longer needs a pre-live maturity label.
  • Place the banner directly after service navigation or the primary header so it qualifies the service before page content.
  • Keep the feedback link short, route-aware, and able to return users to the page they were on.
  • Use banner for broad operational context such as maintenance or rollout, not maturity phase.
  • Use notification banner for one page-flow notice before the H1, not a service-wide phase marker.
  • Use site alert for urgent public status or servicewide disruption that must override normal maturity context.
  • Do not make the phase banner sticky, dismissible, modal, or visually dominant enough to obscure forms and current-task messages.

Required States

  • No phase banner state for live or phase-not-applicable services.
  • Alpha state for limited prototype or research-only service.
  • Private beta state for invited users and controlled rollout.
  • Public beta state for wider access before live.
  • Feedback link state that preserves current page or step context.
  • Route persistence state where the same phase banner appears on every service page.
  • Transition state when alpha changes to beta, private beta changes to public beta, or beta changes to live.
  • Coexistence state with service navigation, ordinary banner, notification banner, or site alert without semantic conflict.

Interaction Contract

  • The phase banner appears consistently across all pages in the service while the phase applies.
  • The tag text, service phase, access model, and feedback copy stay synchronized with delivery status.
  • Activating the feedback link opens a feedback route or email that knows the current page, then lets users return without losing progress.
  • The banner does not dismiss permanently because users can arrive on any route and still need phase context.
  • The phase banner does not replace urgent alerts, form validation, operational outage notices, or cookie consent controls.
  • When the service changes phase, the old phase banner is removed or updated in the same release that changes access and feedback handling.

Implementation Checklist

  • Confirm the service phase, access model, assessment state, and owner before publishing the banner.
  • Place the phase banner in the header area directly after service navigation, or after the primary header when service navigation is absent.
  • Write copy that says this is a new or developing service and invites feedback without over-explaining agile delivery.
  • Pass current route, service step, locale, and version metadata to the feedback form where appropriate.
  • Keep feedback safe for in-progress tasks by preserving drafts, returning to the same step, or opening in a way that does not lose state.
  • Define removal rules for moving from alpha to beta, private beta to public beta, public beta to live, and service retirement.
  • Test deep links, mobile header wrapping, keyboard order, screen-reader reading order, feedback return flow, and coexistence with urgent site alerts.

Common Generated-UI Mistakes

  • Using Beta as a decorative badge for a feature rather than the service phase.
  • Leaving a stale Beta banner on a live service.
  • Showing an alpha service to the public as if it were production ready.
  • Putting phase copy in a sticky overlay, modal, toast, notification banner, or footer-only link.
  • Using the phase banner for outage, maintenance, validation, deadline, cookie, or account-status messages.
  • Making feedback open a generic contact route that loses the current page context.
  • Letting the phase banner disappear after dismissal, so deep-linked users miss the maturity signal.

Critique Questions

  • What phase is the whole service actually in, and who owns changing that label?
  • Is this an alpha prototype, private beta, public beta, live service, or feature-level experiment?
  • Can users give feedback from the current page without losing their place?
  • Should this be a phase banner, broad banner, notification banner, site alert, service navigation, tag, or feedback link?
  • What event removes or changes this banner?
  • Does the banner appear consistently on deep-linked pages, mobile, and routes with service navigation?
Accessibility
  • Place the phase banner in reading order after the header or service navigation and before page-specific content.
  • Use a text tag and sentence; do not rely on color alone to communicate Alpha or Beta.
  • Make the feedback link keyboard reachable and specific about destination or new-tab behavior.
  • Keep the banner compact so it does not obscure focus or push critical content unpredictably at high zoom.
  • If the feedback route opens a new tab or external form, communicate that in the link text.
  • Avoid repeated assertive announcements; the phase banner is stable service context, not a dynamic alert.
Keyboard Behavior
  • Tab order reaches header controls, service navigation, phase feedback link, and then page content in that sequence.
  • Enter activates the feedback link and preserves route or task context through the feedback flow.
  • Returning from feedback restores focus to the page heading, feedback link, or next meaningful control without losing form state.
  • The banner does not trap focus, auto-open a dialog, or require dismissal before users can continue.
  • When the phase changes, route navigation should not leave focus on a removed banner element.
Variants
  • Alpha phase banner
  • Private beta phase banner
  • Public beta phase banner
  • Prototype phase banner
  • Feedback-linked phase banner
  • Header-integrated phase banner
  • Phase transition banner
  • No-phase live state

Verification

Last verified: