A design system is a delivery system

A design system review can fail in two opposite ways.

In the first, every request becomes a new component. The library grows, the documentation thins out and teams cannot tell which option is current. In the second, contribution is so guarded that product teams build private alternatives to meet their deadlines.

Both failures treat the system as a collection to protect. A useful design system is a route by which repeated product decisions become easier to deliver.

Promote evidence, not novelty

The GOV.UK Design System asks proposed patterns to be both useful and unique, with evidence that they apply across teams or services. Its broader standard is blunt: “The contents of the Design System must be of a high quality and meet user needs”.

That suggests a practical threshold. Before adding a component, collect:

• two or more real product contexts;
• the user need shared by those contexts;
• the existing pattern and where it breaks;
• accessibility findings;
• content constraints;
• the variation that is genuinely necessary.

One screenshot proves that a design exists. It does not prove that the decision belongs in shared infrastructure.

A contribution example: status banners

Suppose three teams have built banners for delayed processing. One says “Pending”, another “We're working on it”, and a third uses an error alert because that component already exists.

The shared need is not a yellow rectangle. It is communicating a non-terminal process state without implying failure.

A useful contribution would define:

1. When the status pattern appears.
2. Which states it can represent.
3. What information the heading and body must contain.
4. How updates are announced to assistive technology.
5. When the pattern becomes an error or confirmation instead.
6. Which visual tokens express the hierarchy.

The React component is the last expression of that decision, not the first.

Keep the public API smaller than the discussion

Product conversations are messy. Component APIs should not preserve every historical disagreement as a prop.

<ProcessingStatus
  state="delayed"
  title="Your transfer is taking longer than expected"
  updatedAt={updatedAt}
/>

This is easier to support than a generic banner with yellow, showSpinner, ariaLive, icon, dismissible, compact and bordered switches. The generic version appears flexible while exporting design and accessibility decisions to every consumer.

Tokens need the same discipline. Name them by role—surface-critical, content-measure, action-primary—rather than by a value that will become misleading after the next visual refresh.

Documentation is part of the implementation

Documentation should let someone make a decision and ship. Include:

• a realistic default example;
• permitted states and content guidance;
• keyboard and screen-reader behaviour;
• responsive constraints;
• when not to use the pattern;
• migration notes for changed APIs;
• a named support and contribution route.

GOV.UK's contribution process explicitly brings design, content, code and guidance into the same scope. That is why mature systems feel different from Storybook galleries: the artefact and the operating knowledge travel together.

Measure the work the system removes

Component count is easy to increase and difficult to interpret. Better signals include:

• duplicate patterns found in products;
• accessibility defects caused by shared components;
• time from approved design to production;
• adoption by route rather than package installation;
• consumer wrappers that repeatedly work around the API;
• upgrade time between system releases.

A component used everywhere can still be wrong. A component used in only three critical journeys can remove substantial risk.

Our web engineering and the shared UI used across this site follow the same principle: consistency is the visible result, but delivery is the reason. The system succeeds when a team can spend its attention on the product-specific decision rather than rebuilding focus handling, hierarchy and responsive behaviour.

Treat the design system as a small internal product. It has users, evidence, lifecycle states and maintenance costs. The library is merely where some of that product happens to be compiled.

Sources

• Contribution criteria — GOV.UK Design System
• Develop a component or pattern — GOV.UK Design System
• Design Tokens Format Module — Design Tokens Community Group