GOV.UK Design System
The UK Government’s design system: research-backed components and patterns for building accessible, consistent government services.
License: Open Government Licence v3.0 — https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/
Key points
Error messages + error summary: position inline after label/hint before field; use red border to connect message to field; never clear form fields; write specifically per failure mode; pair inline messages with a page-top error summary (“There is a problem”) linking to each field.
Header: consistent masthead with organization identity; service name and navigation belong in a separate service navigation component, not the header itself; use the header on every page.
Footer: contains copyright, licensing, and support links (Privacy, Accessibility, Cookies, Terms); secondary navigation only for sites where users should navigate elsewhere; avoid secondary nav in linear/transactional services.
Buttons: four types (default/primary, start, secondary, warning); one primary button per page; warning buttons pair with confirmation step; avoid disabled buttons — show errors instead; left-align in forms; sentence case labels.
Radios + checkboxes: order alphabetically (not by perceived frequency); never pre-select options; “none of the above” goes last with a divider; conditional reveals must stay simple; add “Select all that apply” hint for checkboxes.
Text input: fixed-width inputs signal expected answer length; labels above, in sentence case; avoid placeholder text (vanishes on type, fails contrast requirements); hint text is a single short sentence with no full stop.
Notification banner: two modes — neutral (blue, informational) and success (green, confirms action); position before page h1; use sparingly due to banner blindness; never for validation errors (use error summary instead).
Question pages: one-thing-per-page as default; every question page needs a back link, heading, and “Continue” button (not “Next”); pre-populate repeated information.
Validation: validate on submit, not on input; retain all user-entered values when re-displaying on error; accept format variations (a postcode with or without spaces, a name with a diacritic or apostrophe) and silently strip incidental characters rather than rejecting them; never use validation to check eligibility; turn off native browser validation (novalidate, no bare required attributes) since it can’t be restyled consistently and conflicts with the error summary/inline pairing.
Error message writing: avoid “sorry,” “please,” and blame-toned words (“forbidden,” “illegal,” “prohibited”); phrase recovery as an instruction (“Enter your first name”) rather than a system description (“First name must have an entry”); prefix each inline error with a visually-hidden “Error:” span so a screen reader announces it as a problem, not just a statement.
Breadcrumbs: start with home, end with parent section (omit current page); not for flat-structure sites or linear journeys; mobile collapse to first and last items only.
Images: only use an image where there’s a genuine user need, not by default; choose photography for lifelike representation, illustration for simplifying something complex (with a consistent, limited color palette and deliberate representation of people), and icons sparingly, paired with a text label; avoid “images of text” outside a narrow essential-text exception, and prefer HTML text overlays or vector (SVG) formats over baking text into a raster image.
Tables: never use a table for page layout, only genuinely tabular data; mark row/column headers with the scope attribute so assistive technology can tell them apart, and give every table a caption; right-align numeric columns for at-a-glance magnitude comparison; split large datasets across multiple tables or pages rather than compressing everything into one dense table.
Contact a department or service team: order contact channels (phone, email, webchat, post, social media) by what user research actually shows, keep that order consistent everywhere in a service, and list social media channels last with a caution not to share personal information there; state opening hours and any charges; and tell users how long they’ll wait for a response on every channel, including webchat specifically (“Current waiting time is 17 minutes”) — the same disclosure email response-time estimates already get.
Cited In
Patterns
- Action Buttons
- Breadcrumb Navigation
- Data Tables
- Effective Images
- Error Messages
- Form Design
- Live Chat Support
- Notifications
- Site Footer
- Site Header