Design systems that survive contact with engineers
Most design systems are abandoned within a year. The ones that last share four properties, and none of them concern how the Figma file is organised.
The familiar arc
A design system launches with real momentum. There is a component library, a documentation site, a launch presentation. Six months later engineers are copying components out of it and modifying them locally. Twelve months later there are three button implementations and the documentation site describes none of them.
The usual diagnosis is discipline — the team did not enforce it. That is almost never the real cause. Systems get abandoned because using them became slower than not using them, and people are rational.
One: the system ships as code, not as pictures
If the source of truth is a design file and engineers translate it by hand into components, drift is guaranteed. Every translation is an opportunity for interpretation, and there is no mechanism that ever pulls them back together.
Systems that last have design tokens defined once, in a format both sides consume. Colour, spacing, type scale, radii and motion durations live in one file that generates both the design tool variables and the CSS custom properties. When a token changes, it changes everywhere, and nobody has to notice.
Two: it has an escape hatch
This is the one that surprises people. Systems that forbid deviation get abandoned fastest, because the first genuinely novel requirement leaves the engineer with no legitimate option but to work around the system entirely — and once they are outside it, they stay outside.
A good system makes the common case effortless and the unusual case possible. Components accept style overrides at defined extension points. There is a documented way to build something the system does not cover, using the system's primitives. The deviation stays inside the family rather than becoming a fork.
A design system's job is not to prevent exceptions. It is to make the exceptions cost something visible, so they get made on purpose.
Three: accessibility is built in, not documented
Systems that put accessibility in the documentation get accessible components roughly as often as the documentation gets read. Systems that build it into the component get it every time.
Focus management, keyboard interaction, ARIA relationships and contrast-checked token pairings belong inside the component, where they cannot be forgotten. If a developer has to read a guidance page to use your modal correctly, your modal is not finished.
- Focus trapping and restoration handled by the component, not the consumer
- Token pairings pre-validated for contrast, so no valid combination fails WCAG
- Keyboard interaction implemented once, tested once
- Automated accessibility checks in CI, failing the build rather than filing a ticket
Four: someone owns it, with time allocated
A design system maintained in the gaps between project work decays at exactly the rate you would expect. It does not need a large team — one engineer and one designer with a genuine, protected allocation is usually enough — but it needs the allocation to be real and defended when deadlines arrive.
The signal to watch is response time on contribution requests. When a product team needs a new variant and the system team takes three weeks to respond, the product team builds it themselves. Do that four or five times and the system is effectively finished, whatever the documentation site still claims.
Tell us what you are building
A short call, an honest read on whether we are the right fit, and a clear next step either way. No pitch deck.
Replies within one working day