Most design systems don't fail because the components are bad. They fail because a design system isn't really a component problem — it's an organizational one.
I learned that scaling one across a fintech platform with many product verticals, where the real work turned out to be everything around the Figma library. Here's what stuck.
A system is a decision about how you work, not a folder of components
Before we had one system, we had several half-finished ones — scattered guides that each team had grown on its own. The instinct, when that happens, is to build a better folder: more components, tidier files. That instinct is wrong. The scattered guides weren't a file problem; they were a symptom of teams making the same decisions independently, over and over.
The fix wasn't a bigger library. It was a single source of truth with a governance model behind it — a Design Review Board where patterns get proposed, critiqued, and ratified before they spread.
The library is just the artifact. The agreement is the system.
The design–engineering gap is real, and pretending it isn't makes it worse
When our engineering team built the system into a coded component library, we did not get a 100% match between the design and the code. For a while that's uncomfortable to admit — it feels like a failure of the system. It isn't. The gap between "designed" and "built" is structural: tokens, states, and spacing rules don't always map cleanly onto what the front-end can do.
What matters is whether you name the gap or hide it. Naming it — being specific about which component, which state, which token diverged — turns a vague sense of "the system isn't working" into a punch list. The teams that pretend the gap doesn't exist are the ones whose systems quietly rot.
Adoption is a people problem, and end-to-end owners solve it
A system nobody adopts is a very expensive PDF. The thing that actually drove adoption for us wasn't a mandate — it was who was doing the work. When the people using the system are the same people who understand it end to end, from UX through UI to the front-end, adoption stops being something you enforce and becomes something people want, because the system makes their own job faster.
That's the quiet argument for collapsing the old UX/UI split into a single product-design role: end-to-end owners don't just use a system, they trust it, because they can see the whole path it's serving.
Measure the thing you promised
We claimed the system reduced design effort by around 30% — and the only reason that number means anything is that we measured it against reality: the same kind of live project, delivered with the system versus without.
A design system's value is easy to assert and hard to prove, so pick the promise you're making — speed, consistency, fewer handoffs — and measure that, on real work, not in the abstract.
What I'd do differently
Start the governance model earlier — before the library grows, not after. We built a lot of the agreement while the artifact was already spreading, which meant some of the early work was retrofitting consensus onto decisions that had already escaped. The agreement should precede the artifact rather than chase it.
Treat a design system as an operating standard and an organizational agreement, close the design-to-code gap out loud instead of quietly, put end-to-end owners at the centre, and measure the promise you actually made. The components are the easy part.