GOV.UK Design System: questions, errors, and review

Evidence class: maintained public-service design guidance. Read: 2026-09-13. These patterns supply concrete implementation examples, not a universal visual style or a claim of measured uplift on every website.

Ask only what the task needs

Question pages start with one question per page, but the guidance explicitly permits related questions together when research supports it, including frequent internal work. Avoid asking for the same information again. Preserve browser Back behavior without repeating one-time effects. Source: Question pages, read 2026-09-13.

Make correction locatable

The error-summary pattern brings keyboard focus to a summary, links each error to the affected answer, and matches its wording to the field-level message. Source: Error summary, read 2026-09-13. Our transfer: error recovery needs a usable navigation path, not only red styling. This pass read the pattern but did not run its component in an application.

Review before consequential submission

The check-answers pattern gives users a review opportunity within a transaction. For large, multi-section transactions, the guidance proposes testing section-level reviews. Source: Check answers, read 2026-09-13.

Boundaries and tensions

Our proposed use is forms, onboarding, requests, and other goal-directed transactions. A high-frequency editor may need inline feedback rather than a government-style page transition for every action. Do not universally impose one-question pages, exact English button copy, or an error summary for every background event. Where questions require comparison, test a grouped presentation. Minimalist screen count is not the objective.

Labels, comparison, and validation timing

Text-input guidance requires labels, generally visible, and rejects placeholders as substitutes for labels or essential hints. Source: Text input, read 2026-09-13. The live reference example, read 2026-09-13, was opened as content, not interaction-tested. Our application is to make a filled form reviewable, not merely attractive when empty.

The table pattern supports comparisons across rows and columns; a caption helps explain the table. It is not a page-layout mechanism. Source: Table, read 2026-09-13. Reference example, read the same day. Our table-versus-card choice still depends on the task.

The validation pattern says not to validate when the user leaves a field. Wait until they try to continue or submit. It also advises against checking a field before the user has finished entering it, and allows that only when user research shows it solves more problems than it causes. The character count, which shows an error once the user goes over the limit, is an example. Source: Recover from validation errors, read 2026-10-29. This differs from Baymard's commerce guidance, which recommends checking each field when the user leaves it. Preserve the disagreement instead of combining the two as universal instructions.