GOV.UK service-design glossary

GOV.UK Design System

The cross-government design system maintained by the Government Digital Service. It provides accessible UI components (radios, checkboxes, date inputs, error summaries), patterns (start pages, confirmation pages, eligibility flows) and the GOV.UK Frontend CSS/JS that implements them. Every digital service on GOV.UK uses it.

GOV.UK Prototype Kit

A Node.js + Express + Nunjucks toolchain published by GDS for building clickable prototypes of GOV.UK services. It ships the GOV.UK Frontend pre-wired, so anything you generate looks and behaves like a real service. Used in discovery and alpha for user research; not for production.

GOV.UK Frontend

The CSS, JavaScript, fonts and asset bundle that implements the GOV.UK Design System. The package installed by the Prototype Kit and by production services. The visible identity — typography, the green Continue button, the yellow focus ring, the layout — comes from here.

Nunjucks

The templating language used by the GOV.UK Prototype Kit. A Jinja2-derived syntax that compiles to HTML at request time. Templates use macros (e.g. govukRadios) to render Design System components without writing the underlying HTML by hand.

Express

The Node.js HTTP framework the Prototype Kit uses for routing and middleware. Prototype routes are written as Express handlers; server-side form validation runs in middleware before the response is rendered.

Government Digital Service (GDS)

The Cabinet Office unit that publishes the GOV.UK platform, the Design System, the Prototype Kit and the service standard, and runs the service assessment process. Successor to the original GOV.UK programme that launched in 2012.

GDS service standard

The 14-point standard government services must meet to be allowed on GOV.UK. Covers user-centred design, accessibility, technology choices, team capability and sustainability. Assessed at alpha and beta gates by an independent panel.

Service assessment

The peer review process that decides whether a service can progress to the next phase (alpha → beta → live). Run by a panel of practitioners against the service standard. Failure usually means rework, not death.

Discovery

The first phase of GDS service delivery. The team learns about the user problem before committing to a solution. Outputs: user research, problem definition, agreement on whether to proceed.

Alpha

The phase after discovery. The team builds prototypes of possible solutions and tests them with real users. Outputs: a chosen design direction, evidence it works, a credible plan for beta. Gated by a service assessment.

Beta

The phase after alpha. The team builds a working service used by real users (private then public beta). The service runs on real infrastructure, with monitoring, support and an incident process.

WCAG 2.1 AA

The Web Content Accessibility Guidelines, version 2.1, conformance level AA. The accessibility standard government services must meet. Covers perceivability, operability (keyboard navigation, sufficient time), understandability and robustness. Required from alpha onwards.

Service designer

The role that owns the end-to-end shape of a service: how a user enters, what they do, what they get out, what happens behind the scenes. Distinct from interaction designer (who designs screens) and content designer (who writes the words).

Content designer

The role that owns the words on a government service. Applies GOV.UK content design rules: plain English, short sentences, active voice, no jargon. Tests wording in research and rewrites from what users say.

User research

The discipline that puts a service in front of real users and listens. Methods include usability testing (watching someone use a prototype), depth interviews and contextual research. Drives every design decision after discovery.

Error summary

The Design System component that lists every validation error at the top of a page, each linking down to the field. The canonical accessibility pattern for form errors — screen-reader users hear the summary, can navigate to each field, and know what to fix.

Sandbox

An isolated execution environment that runs a prototype. In Vibe, each project has its own per-tenant cloud sandbox with a shareable URL. Sandboxes auto-hibernate when idle and wipe any session data on shutdown.

BYOK (bring your own key)

A model where customers supply their own AI provider API key instead of paying for usage through the platform. Vibe encrypts BYOK keys at rest with AES-256-GCM and uses them only for the workspace they were entered into.

Data residency

The country in which data is physically stored and processed. Vibe runs in the UK by default; an EU region is available where a project specifically requires it. Relevant for procurement teams under the UK GDPR.

Data Protection Impact Assessment (DPIA)

A document that records what personal data a system processes, why, what risks that creates, and how the risks are mitigated. Required under UK GDPR for high-risk processing. Vibe’s DPIA is at /dpia.

AI prototyping

The practice of using a large language model to generate a prototype from a plain-language specification. In a GOV.UK context, the output is typically a Prototype Kit project — Nunjucks templates, Express routes, validation — produced in seconds rather than days.

Vibe coding

An informal term for letting an AI write code from a natural-language description, with the human guiding through conversation rather than syntax. Coined in 2025; Vibe.WithGov applies the same pattern to GOV.UK service prototypes.

Missing a term? Tell us and we’ll add it.