Every design system fails at the same two moments: when somebody wants a component that does not exist, and when a component nobody uses will not go away. Building the library is the easy part. What makes it survive is having written down, in advance, how something gets in and how something gets out.
Two governments publish exactly that, in full, for free. The parts most worth copying are not the components, which are specific to their context. They are the admission criteria and the lifecycle statuses, which are context-free and take an afternoon to adopt.
Tokens, and why they exist at all
Before components, the layer underneath them, with a definition that explains the point better than most vendor documentation.
The definition. A design system’s “visual design is based on consistent palettes of typography, spacing units, color, and other discrete elements of style we call design tokens.”
And the rationale, which is about people rather than code. “This degree of choice can slow down design work and make communication between designer and developer unnecessarily granular. The Design System seeks to maximize design efficiency and improve communication with design tokens: the discrete palettes of values from which we base all our visual design.”
Their own metaphor is the clearest part. Tokens are like “a scale of musical notes … drawn from the spectrum of all possible frequencies. Or like the presets on a car radio, not every option, just a specific selection.”
The categories are named and finite. Color, typesetting, flex, opacity, order, shadow, spacing units, and z-index. Eight, not an open list.
With a concrete rule for the one that matters most. “USWDS spacing unit tokens are based on multiples of 8px, with additional tokens for small sizes, named tokens for large sizes, and a more limited selection of negative tokens.”
One attribution note. The term design token belongs to the US system here. The UK design system publishes a colour palette, a spacing scale and a type scale under “Styles” without using that vocabulary. If you cite the term, cite the American source.
Not every possible value, a specific selection. The stated purpose is communication between designer and developer. Source : U.S. Web Design System, design tokens (2026)
How something gets in
This is the half that keeps a system small, and the criteria are unusually blunt.
The framing. “The contents of the Design System must be of a high quality and meet user needs. To guarantee this, all components and patterns need to meet certain criteria.”
Two criteria to be accepted as a proposal. Useful: “There is evidence that this component or pattern would be useful for many teams or services. Evidence could be screenshots or links to versions of it being used in different services.” And unique: “It does not replicate something already in the Design System.”
Three more before it is published. Usable: “It has been tested in user research and shown to work with a representative sample of users, including those with disabilities.” Consistent: “It reuses existing styles and components in the Design System where relevant.” Versatile: “The implementation is versatile enough that the component or pattern can be used in a range of different services.”
And an instruction that saves the most time of all. At proposal stage, “you just need to present your idea and evidence of the user needs. You can include screenshots or links to versions of the component or pattern in use, but avoid spending time working on a specific design or writing code.”
Read that again if you have ever received a fully built component nobody wanted. Evidence first, design second. The order is the whole mechanism.
One governance detail worth stealing wholesale. Components in trial status “will move to stable status if we do not receive any negative feedback” after six months. Promotion by default, with a window to object, rather than a meeting nobody schedules.
This is the half nobody builds, and it is why design systems accumulate.
Five named statuses, each with a definition. Experimental: “released for early access. These components pass accessibility tests, and have core functionality and production-quality code, but might need additional research, testing, documentation, or features.”
Stable. “The component has an established history in production. These components must meet all USWDS requirements, have full functionality, and have complete documentation.”
Use with caution, which is the one small teams need most. “The component does not currently meet requirements and needs significant rework.” A public admission that something is wrong, without removing it.
Deprecated. “The component is removed from active support. The component is still available in the code base, but it will not receive any updates.”
Retired. “The component is removed from the code base. This is the end of the component lifecycle.”
Why five statuses beat a yes or no. Most component decisions are not binary. A team that can only say “in the system” or “delete it” will keep everything, because deletion is the only alternative and deletion breaks pages.
And a small team can adopt this in an afternoon. Add a status field to your component documentation with those five values. That is the whole implementation.
Government systems are large because their remit is. The transferable parts are small, and they are what we settle first when we build a B2B site that has to convert, because a system a team cannot maintain stops being used within a year.
Start with the tokens, not the components. Eight categories, a spacing scale on a fixed multiple, a colour palette that clears the contrast thresholds, and a type scale. That is a day of work and it removes most of the recurring arguments.
Then document only what you have used twice. The uniqueness criterion, applied inward: if a pattern appears in exactly one place, it is a page, not a component.
Write the five statuses into your documentation from day one. Adding a deprecation path later, once there are thirty components and four opinions, is much harder.
Keep the proposal step lightweight, deliberately. Evidence of repeated need first, in the form of screenshots. No code, no Figma file, until the need is agreed.
And accept the principle that governs the whole thing. From the same government’s design principles: “We should use the same language and the same design patterns wherever possible … This isn’t a straitjacket or a rule book. Every circumstance is different.”
One published claim about the payoff, with its caveat attached. A GDS blog post reports that pages built with their design system “download about twice as fast as those that haven’t, as they use about half as much code”, and that the code has been “reused over 3,300 times”. That is a blog post by a named product manager rather than documentation, and the estimate’s method is not shown. It is suggestive, not evidence.
Write the token list before anything else. Eight categories, a spacing multiple, a palette, a type scale. Put it in one file that both design and development read from.
Add a status field to every component you already document, using the five published values. Then go through the list once and mark honestly. The components that get marked “use with caution” are your actual backlog.
Adopt the two-stage admission test. Useful and unique to be considered, then usable, consistent and versatile to be published, with evidence of repeated use required before anyone opens a design tool.
And set the promotion rule so that decisions happen without meetings: a component in trial moves to stable after six months unless somebody objects.
The US Web Design System defines them as 'the discrete palettes of values from which we base all our visual design', covering typography, spacing units, colour and other elements of style.
When should we add a new component?
The GOV.UK criteria are useful and unique to be accepted, then usable, consistent and versatile before publication. Usable means tested in user research with a representative sample including disabled users.
How do we retire something?
With a named status. The US system distinguishes deprecated, meaning removed from active support but still in the code base with no further updates, from retired, meaning removed from the code base entirely.
Does a design system make a site faster?
A GDS blog post reports that pages on GOV.UK built with their design system 'download about twice as fast as those that haven't, as they use about half as much code'. Note that is a blog claim, not documentation.