Design systems beyond Figma: components, content and code

A library can have immaculate variants, well-organised names and hundreds of components. The product may still have three ways to communicate an error, buttons that behave differently and forms that are difficult to use with a keyboard.

The gap between those two realities reveals the problem: the system exists as a file, but does not yet function as a shared agreement between people. Figma can represent decisions; the product needs those decisions to survive real content, implementation and change.

A useful design system connects what an interface shows, what it says and what it does. To build one, it helps to start with those relationships before expanding the catalogue.

The unit of work is a shared decision

Consider a button for saving changes. Its visual definition includes colour, size and spacing. But crucial questions remain: what does it say while saving? How does it prevent repeated submissions? What happens if it fails? How is the result communicated?

GOV.UK’s component documentation combines reusable elements with usage guidance and code examples. That combination offers a concrete reference for connecting design and implementation. GOV.UK: Components.

As a working approach, each component should have a small shared contract:

• Its purpose and situations in which it should be used.

• Anatomy, necessary variants and possible states.

• Content rules and realistic examples.

• Behaviour, accessibility and known limitations.

• Reference implementation, owner and version.

This does not require an endless document. It requires design, content and development to be able to answer the same questions without each interpreting a screenshot separately.

Content is part of the component too

An ambiguous label can make a visually consistent interaction confusing. “Continue” could save a draft, move to another screen or confirm an operation. If the system only controls the button’s appearance, it leaves an essential decision unresolved.

Document intent as well as length

Content guidance can define how to name actions, distinguish recoverable errors and explain empty states. Its examples should include long text, translations and less favourable cases; perfect content hides design problems.

GOV.UK recommends explaining what happened and how to fix it, relating the message to the field label and preserving answers when displaying errors. It also distinguishes validation problems from those the person cannot resolve, such as a service failure. GOV.UK: Error message.

In a hypothetical example, a form rejects a file that is too large. “Upload error” does not help someone decide what to do. “The file exceeds the 10 MB limit. Choose a smaller one” makes recovery possible, provided that is the actual limit.

The shared rule could require a reason, a next action and preservation of the other data. The team adapts the wording to the context without losing the pattern’s logic.

Tokens connect decisions, not just colours

A token gives a design value a name so that it can be reused. The practical difference emerges when the name expresses intent: “error text” explains its use better than “red 600”. Both levels can coexist, but serve different purposes.

The Design Tokens Community Group format aims to facilitate exchange between tools and supports references between tokens. It should be described accurately: the 2025.10 report is a community group specification, not a W3C standard. DTCG: Format Module.

For a team getting started, I propose three explicit decisions:

1. Where shared values are approved and versioned.

2. How they reach design tools and code.

3. How a divergence is detected and resolved.

Automating an export helps, but does not determine who can change a token or which products are affected. Before changing an error colour, review its actual combinations, states and use across different themes.

Nor should every number become an abstraction. A token deserves to exist when it represents a reusable, understandable decision.

Accessibility is checked in use

A focus variant in Figma documents an intention. It does not demonstrate that focus appears in the browser, follows an understandable path or returns to the right place after an interaction.

The WAI-ARIA patterns guide describes, for example, button activation with Space and Enter, accessible names and focus management according to the action performed. These are behavioural aspects that a visual review does not cover. WAI-ARIA APG: Button Pattern.

Test the component and its context

As an acceptance criterion, combine automated checks with manual testing of keyboard use, zoom, long content and assistive technologies. An isolated check is also no substitute for reviewing the entire flow.

Imagine an accessible button inside a form that clears all data when it fails. The component may behave correctly while the experience remains problematic. Tests therefore need to include waiting states, errors and recovery, as well as the successful path.

Governance: deciding how the system changes

Without a contribution process, two extremes emerge: a rigid library that blocks legitimate needs, or a catalogue that accumulates variants for every request.

GOV.UK’s criteria require proposals to be useful and distinct from what already exists; before publication, they are reviewed for usability, consistency and versatility. The criteria also consider research with disabled people and testing in different environments. GOV.UK: Contribution criteria.

A practical adaptation for a product team would be to ask each proposal to describe the problem, the contexts in which it appears, the alternatives evaluated and the available evidence. Then assign a joint review across design and development, involving content and accessibility as appropriate.

Exceptions need an owner and a review date. If a variant addresses a local need, it can remain within that product. If it demonstrates wider usefulness, it can become part of the system.

When a change breaks existing uses, the release should explain what changes, how to migrate and how long the previous version will be maintained.

Adopt through real problems, measure in production

There is no need to replace the entire interface at once. The USWDS maturity model proposes incremental adoption through principles, guidance and code. USWDS: Maturity model.

A reasonable starting point is to choose a frequently used flow with visible inconsistencies. A form lets the team work on fields, buttons, errors and content as a whole. Then check which decisions work in a second context.

To assess progress, I suggest tracking shared components that are actually used, outdated versions, recurring exceptions and unresolved accessibility problems. The number of published components says little if no one can adopt them without reworking them.

Checklist before publishing

• Does the component address a verified need?

• Are its states and content rules clear?

• Do design and code represent the same decision?

• Has it been tested with a keyboard and realistic content?

• Is there evidence that it works within a flow?

• Does it have an owner, a version and an upgrade path?

• Is it clear how to propose an improvement or justify an exception?

A design system starts to build trust when it removes the need to renegotiate the essentials on every screen. Its value lies in making the next decision clearer, more accessible and easier to maintain.

Sources

• GOV.UK Design System: Components

• GOV.UK Design System: Error message

• Design Tokens Community Group: Format Module 2025.10

• W3C WAI: Button Pattern

• GOV.UK Design System: Contribution criteria

• USWDS: Maturity model