Design system foundation
Agents produce most first-draft UI, so consistency cannot depend on a designer catching every screen — it has to be built into what agents consume and what CI enforces. The design system is that mechanism: DTCG-format tokens as the single styling source, plus a coded component library with accessibility behaviour baked in. A PDF of principles governs nothing; a library and a linter do.
The foundation
- DTCG-format design tokens — colour, typography, spacing, radius, elevation defined once in W3C Design Tokens Community Group format, consumed by the component library, the lint rules and the agents. Tokens are the only styling source: no raw hex, no raw px, anywhere downstream (enforced — see the design-quality toolchain).
- A coded component library — real components, not pictures of components. Accessibility behaviour is baked in per the WAI-ARIA APG: focus order, keyboard operability, labels and ARIA roles ship inside the component, so an agent that composes library components inherits accessible behaviour instead of reinventing it wrongly (accessibility standard).
- Copy rules travel with it — tone, error-message patterns and jargon rules per the content & microcopy standard, so generated UI sounds consistent as well as looking consistent.
Seed pragmatically — don't boil the ocean
The v1 library is what StudyBuddy and CXsmart screens actually need, nothing more: form inputs and validation, tables and lists, status and progress indicators, navigation, and the error/empty/loading states every screen spec must cover. Everything else is added through the component contribution workflow when a real screen demands it — the system grows from evidence, not speculation.
The GOV.UK Design System is the reference model: proven, accessible patterns for forms-heavy, high-stakes journeys — which is exactly what insurance UIs are. Adapt its patterns; don't invent parallel ones.
How agents consume it
- Every UI-producing agent session loads the design context pack — the machine-readable fragment mapping patterns to components and stating the token-only rule.
- Every screen in Design maps to named components and tokens in its screen spec, checked at the Design Review gate.
- The design-quality toolchain rejects non-token styling and unknown components at the merge gate.
Implementation depends on the design-tooling ADR: code-first, Figma-first (with token export / MCP into the agent workflow) or hybrid determines how tokens are authored and synced and where the component source of truth renders. The commitments on this page — DTCG tokens, a coded library, APG behaviour — hold under any outcome; only the authoring pipeline changes. Owner: design + engineering leads.
Standards referenced: W3C DTCG, WAI-ARIA APG, WCAG 2.2 AA (GOV.UK Design System as reference).