Phase / beta banner

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?