Personal Research

home-office-design-system

4 min read

Home Office Design System — operations

Research snapshot: 2026-07-30. Scope: the UK Home Office Design System. This profile is included as a federated case: the system extends GOV.UK and aims to contribute mature work upstream.

1. Governance

  • A cross-functional Design System Working Group includes interaction and content design, user research, accessibility, and front-end development. It meets every two weeks to review discussions, support contributors, assess readiness, publish or update guidance, and share decisions. (Working group)
  • The Working Group checks whether a need is already covered by GOV.UK and raises appropriate work with the GOV.UK Design System team. Home Office components and patterns are described as extensions that should be contributed upstream as they mature. (Working group, components, patterns)
  • Anyone can contribute. Decisions and updates are shared through GitHub, community email, Slack, show-and-tells, and the public documentation. (Contribute, get started)

2. Component lifecycle

  • The public site does not define a universal proposed/draft/beta/stable ladder. Its documented path is: discussion and evidence → Working Group assessment → GitHub issue and development → local publication → continued research and improvement → upstream contribution to GOV.UK when mature. (Contribute, working group, components)
  • The Working Group assesses work using the GOV.UK contribution criteria, including usefulness, uniqueness, usability, consistency, and versatility. Work already covered by GOV.UK is raised upstream instead of duplicated locally. (Contribute, GOV.UK contribution criteria)
  • Individual pages expose evidence maturity in prose. They document research completed and explicitly list what still needs improving or validating; this is a visible health signal, not a formal package status. (Alert, Status message)

3. Contribution process

  • Contributors search existing GitHub discussions, then open an idea with the user need, rationale, screenshots or examples, and research. They share it through community channels and summarize feedback in the discussion. (Contribute)
  • The Working Group reviews the discussion against GOV.UK criteria and opens or requests a GitHub issue when it is ready for development. It supports the contributor, reviews readiness, publishes or updates the system, and communicates the outcome by community email. (Contribute, working group)
  • Mature local components and patterns are candidates for upstream contribution to GOV.UK, creating an explicit extension-to-parent contribution route. (Components, patterns)

4. Versioning and release cadence

  • The public documentation does not state a formal package-wide Semantic Versioning policy or fixed release cadence for the Home Office system. It communicates dated site updates, GitHub changes, community emails, and Working Group updates. (Home Office Design System, working group)
  • Implementation is layered: public-facing services use GOV.UK Frontend, while Home Office-specific HTML/React resources extend that base. The React route is associated with NotGovUK. The public get-started page is the implementation entry point but does not publish a unified release contract for every layer. (Get started, design assets)

5. Documentation structure/templates

  • Component pages include purpose, when to use, how it works, variants, content guidance, accessibility, research, implementation examples, and a “Help us improve” section. HTML and React examples or props are included where available. (Alert, Status message)
  • Pages explicitly publish evidence gaps and link users to GitHub discussions, making documentation part of the contribution and review loop. (Alert, design assets)
  • Styles guidance distinguishes Home Office internal services from public services that should use GOV.UK presentation. (Styles)

6. Naming and token conventions

  • Home Office-specific implementation examples use a hods- BEM-style namespace, while inherited GOV.UK classes retain the govuk- namespace. This makes the extension boundary visible in code. (Alert, get started)
  • Public style guidance covers shared color and other foundations but does not publish a general multi-layer design-token taxonomy comparable to Pajamas’ DTCG naming grammar. (Colour, styles)

7. Accessibility criteria and enforcement

  • The Home Office accessibility standard is versioned and aligns to WCAG 2.2 level AA, with requirements intended for service teams and delivery processes. (Accessibility standard)
  • Accessibility expertise is represented directly in the Working Group. Contributions are assessed against GOV.UK criteria, which require research including disabled users and testing across assistive technologies, browsers, and devices before publication. (Working group, GOV.UK contribution criteria)
  • Component pages include component-specific accessibility guidance and research gaps. The public site’s accessibility statement records a historical internal audit and known issues; its stated review date is old, so it should not be read as proof of a current full-system audit. (Alert, accessibility statement)

8. Audit/review cycle

  • The Working Group’s fortnightly review is the clearest published recurring operational cycle. It reviews discussions, identifies needs already covered by GOV.UK, supports contribution work, assesses publication readiness, and updates the community. (Working group)
  • Component pages preserve research findings and “needs improving” items, allowing gaps and drift to remain visible until new evidence is contributed. GitHub discussions provide the ongoing review record. (Alert, Status message, contribute)
  • The public accessibility statement documents an internal audit but is not recent. No fixed full-library audit or deprecation interval is stated in the cited material. (Accessibility statement)

Graph View

Backlinks