Define decisions, not just a style gallery
A design system is more than screenshots. It records decisions that recur: spacing between sections, the primary action treatment, how a form error works, and the language used after success or failure. USWDS describes design tokens as discrete palettes for values such as typography, spacing, color, line height, and opacity. Document the rule, purpose, approved variants, and owner. Begin with foundations and the five to eight components used most in important journeys; standardizing every page at once usually creates noise rather than clarity.
Record approved color roles, type, spacing, borders, radii, breakpoints, and motion choices that your site actually uses.
Use a pattern for a repeatable task arrangement, such as account creation or search results, rather than for a single visual flourish.
Use tokens to control repeated values
A design token is a human-readable name associated with a value. The Design Tokens Community Group describes tokens as a platform-agnostic way to express design decisions; at minimum, a token is a name and value. Use purpose names such as color-action-primary or space-section rather than scattering raw values through templates. Keep a documented mapping from purpose tokens to base values. Tokens make coordinated changes easier, but they do not guarantee contrast, branding, or good hierarchy. Validate each rendered combination and page state.
Create tokens for repeated choices, not every exception; otherwise the token list merely preserves inconsistency.
For a token used widely, list affected pages, test representative screens, and provide migration or rollback guidance when needed.
Build components with behavior and boundaries
A component is a reusable interface part with behavior, not only a visual shape. Document semantic structure, required and optional inputs, variants, responsive behavior, and all relevant states: loading, disabled, error, empty, and success. Include keyboard behavior and content guidance. Do not force every layout into a component. GOV.UK evaluates shared components for usefulness, uniqueness, usability, consistency, and versatility; that is a useful discipline for deciding what deserves shared maintenance. A broadly reused component can spread a defect broadly, so test it in the pages where people use it.
List each user-visible state and show real labels, long text, and errors so implementation limits are visible.
Mark old variants clearly, name the replacement, and remove them only after affected journeys have been reviewed.
Make accessibility a release condition
Accessibility must be built into the system because repeated choices can repeat barriers. WCAG 2.2 requires, at Level A, keyboard operation for functionality except where movement path is inherent, and requires meaningful focus order when sequence matters. Make semantic controls, visible focus, labels, logical focus movement, error identification, and non-pointer task completion part of component guidance. Use automated checks early, then manual keyboard, zoom, responsive, and page testing. USWDS cautions that accessible components do not guarantee an accessible service; custom code, copy, integrations, and context still need review.
Confirm people can reach, operate, understand, and leave controls without a mouse or a keyboard trap.
Legal duties vary by jurisdiction and contract. Seek qualified accessibility and legal review when compliance is material.
Treat content standards as interface standards
Words are component inputs, not decoration added after design. Set rules for action labels, form labels, errors, headings, links, terminology, dates, numbers, and abbreviations. GOV.UK guidance favors active voice and addressing the user as you where possible; use the principle of clear, consistent language, while adapting voice to your audience. Pair rules with a content model: state which fields are required, sensible length guidance, and what happens when information is absent. Put the guidance in component docs and CMS workflows, where editors can use it.
Say what failed, where it happened, and the next action when it is safe and useful to do so.
A limit is a signal to redesign or rewrite, not permission to remove essential meaning.
Govern the system before it grows faster than trust
Governance is the lightweight process for ownership, requests, review, releases, and retirement. Name an accountable owner and a review group that can bring design, engineering, content, and accessibility expertise. Match evidence to blast radius. A local pattern may need a problem statement and page test. A shared button or token change should include affected journeys, accessibility checks, visual comparison, migration notes, and rollback instructions. GOV.UK asks contributors to show a component is useful for many teams, not a duplicate, and tested with representative users; use that as a practical model rather than a universal rule.
Save the problem, options, decision, owner, affected version, and review date where teams can search it.
Label changes as patch, additive, or breaking so consumers know when migration and a compatibility period are needed.
Prevent regressions before release
Connect the system to delivery. Require a change to identify touched tokens and components, then test affected states and representative pages. Visual comparison, interaction tests, content review, and accessibility checks find different defects. Prioritize high-consequence journeys as well as high-traffic ones; account access and contact forms can be important even when traffic is modest. This supports Status Is UP's proactive uptime optimization and remediation work by narrowing defect scope and making an approved fix easier to verify. It is not downtime monitoring or a substitute for an incident plan.
Keep the component version, test results, findings, approvals, and any accepted risk with the release record.
Preserve the prior stable version and test written restore and verification steps during low-risk maintenance.