UX & Design8 min read
Design systems are business infrastructure
Treating a design system as a design team's internal tool is the reason most of them stall in year two.
By Product Practice, Product design & research
Design systems have a characteristic failure curve. Year one is enthusiastic: components get built, the library looks impressive, adoption climbs. Year two, the original team moves on, contributions slow, teams start forking components, and eighteen months later there are three systems, the official one, the real one and the legacy one.
This is almost never a craft problem. The components were fine. The failure is that the system was resourced as a project and not as infrastructure.
What treating it as infrastructure means
Nobody funds a CI pipeline as a one-off project with a launch date. It has an owner, a budget line, a service level and a deprecation policy, because the cost of it failing is distributed across every team. A design system is the same category of thing and is routinely funded like a redesign.
- A named owner with allocated time, not a volunteer rota
- A recurring budget line rather than a one-off project spend
- A contribution model with review standards and turnaround expectations
- A versioning and deprecation policy that teams can plan against
- Measurement that connects the system to delivery outcomes
The economics you are actually arguing
Design systems get funded when the argument is commercial rather than aesthetic. Consistency is not the pitch: consistency is a side effect. The pitch is delivery cost.
Without a system, every feature carries a fixed overhead: re-deciding spacing, re-building a table, re-specifying a date picker, re-discovering that the empty state was never designed. That overhead recurs on every team, every sprint, forever, and it is invisible because it is distributed.
| Cost centre | Without a system | With a maintained system |
|---|---|---|
| New feature design | Patterns re-decided each time | Composed from existing components |
| Engineering build | Re-implementation and drift | Consumed from a shared package |
| QA | Every state tested from scratch | Component states tested once |
| Accessibility | Audited per feature, inconsistently | Enforced at component level |
| Onboarding | Tacit knowledge, long ramp | Documented decisions |
| Rebrand or theme change | Manual sweep across the product | Token update |
Build tokens before components
The most common sequencing mistake is building a component library on hardcoded values. Components then encode decisions that cannot be changed centrally, and the first time the brand shifts, the system becomes the obstacle it was meant to remove.
Tokens are the contract between design and engineering. Publish them as something engineering consumes directly, a package, not a page in a documentation site, and a spacing decision becomes a version bump rather than a redraw.
The seven-state rule
A component is not finished when it looks right. We require seven states documented before anything enters a system.
- Default
- Hover and focus, including keyboard focus
- Active or selected
- Disabled, with the reason it is disabled
- Loading
- Empty or no-data
- Error, including what the user can do about it
Most of the inconsistency in a mature product comes from states five to seven being improvised per feature. That is also where most accessibility failures accumulate.
Measure adoption, not component count
Component count measures effort, not value. The useful measures are coverage: what proportion of production UI is composed of system components, and drift, the number of forked or one-off implementations in the codebase.
Both are countable, both trend, and both connect to a delivery argument a CFO will recognise. A system with forty well-adopted components is worth more than one with two hundred that teams route around.
A design system that nobody can contribute to becomes a bottleneck. One that anyone can contribute to without review becomes a second codebase.
The balance is a contribution model with real standards and a real turnaround commitment. Teams will follow a system that is faster than going around it. They will route around one that is slower, however good the components are.
Product Practice
Product design & research
The product practice covers discovery, research, interaction design and design systems. It writes about the structural decisions that sit underneath an interface, and what happens when they are made carelessly.
