It usually starts the same way. A designer pitches it. Leadership approves it. The team is excited. Finally, one place for everything. Consistent components. Designers and engineers speaking the same language. No more reinventing the same button for the fifth time.
Then week eight arrives.
The Figma file doesn't match what's in the code. Someone built a slightly different version of the card component to handle an edge case. The designer who drove the whole thing is on leave. Nobody scheduled the governance meeting. Nobody's sure who owns the inconsistencies.
By month four, teams are working around the design system instead of with it.
This is not a design problem. It's a sequencing problem. And it happens to most teams.
The mistake almost every team makes first
They build the components before they define the tokens.
Tokens are the foundation, the values that everything else is built from. Colors. Font sizes. Spacing. Elevation. When your designer writes 'text-primary' in Figma and your engineer writes 'text-primary' in code, they're speaking the same language.
When your Figma file has #111111 and your codebase has #0D0D0D and the dark mode version is hardcoded somewhere entirely different, that's a token problem. And it compounds with every new component you build.
Get tokens right first and every future change is one line. Rebrand? Update the value. Add dark mode? Map the tokens. The components don't move. The values do.
A component library is not a design system. A design system is a component library built on tokens. The order matters.
Why the Figma handoff keeps breaking
Here's what happens. The designer finishes the component. It looks great. They hand it to the engineer.
The engineer opens Figma and immediately hits questions nobody answered. What does the button look like when it's disabled? What's the error state on the form field? How does the modal resize on mobile?
These aren't edge cases. They're standard states every component needs. When they're missing from the design, the engineer makes a call. And every engineer makes a slightly different one.
The fix is simple but requires discipline:
Design every state; default, hover, focus, active, disabled, error, loading, before handoff
Specify responsive behavior explicitly. 'Looks good on mobile' is not a specification
Document accessibility requirements at component level and not as a separate audit later
Storybook closes the gap. Engineers build components directly into it. Designers review them there. Problems surface in Storybook, not in production.
Accessibility: the thing everyone retrofits and nobody should
WCAG AA is the baseline for accessible web products. Colour contrast above 4.5:1. Everything navigable by keyboard. Screen reader labels on anything without visible text.
Built into the component spec, it takes an hour per component. Retrofitted after an accessibility audit, it's a sprint-destroying refactor.
The teams who treat accessibility as a component-level requirement, not a compliance checkbox, end up with better products for everyone. High contrast is easier to read in sunlight. Keyboard navigation helps power users. Good focus management just makes the interface feel right.
The real reason design systems die
It's not the technology. It's not even the design.
It's that nobody's job is to maintain it.
Not 'part of someone's job alongside four other priorities.' Not 'whoever has bandwidth this sprint.' Someone's actual, documented responsibility.
Without that, the system drifts. Components in Figma stop matching components in code. New patterns get invented instead of added properly. The whole thing quietly becomes a document nobody trusts.
The governance model doesn't need to be complicated:
One owner with real time allocated not just goodwill
A clear process for how teams contribute new components
A deprecation policy; components are retired with a migration path, not just deleted
A quarterly check on what's actually being used and what's drifted
Is it worth it?
Yes. Consistently.
Teams with a healthy design system report 30–50% faster UI delivery after the first six months. The payback on the initial investment is usually under a year.
But the number that doesn't show up in a sprint report: how many fewer design review cycles catch the same problem over and over, because the constraints are in the system now, not just in someone's head.
A design system is infrastructure. Nobody notices it when it's working. Everyone notices when it isn't.