Design
Ninety percent of the failures we audit are not design problems. They are distribution problems — and the fix is a versioned package.
We audit a lot of design systems. The failure mode is remarkably consistent, and it is almost never a design failure. The components are good. The documentation is thorough. The Figma file is immaculate. And engineers are still building buttons by hand.
The problem is distribution.
Most struggling systems are treated as a deliverable: designed, published, announced, and then handed over. Successful ones are treated as an internal product with a roadmap, a release cycle, a changelog and someone whose job is adoption rather than design.
That reframing changes the questions you ask. Not “is the component library complete?” but “what stopped the last three features from using it?”
The single strongest predictor of adoption we have found: whether the system exists as an installable, semantically versioned package that an engineer can add in one command.
A Figma library plus a documentation site is a specification. Engineers implementing a specification will diverge — not from carelessness, but because implementation requires a hundred decisions the specification did not make. A package makes those decisions once.
Components will always be incomplete. There will always be a screen that needs something the library does not have. What must be complete is the token layer — colour, spacing, typography, radius, elevation, motion.
When tokens are the contract, a one-off component built outside the library still looks like it belongs. When components are the contract, anything outside the library looks foreign, so teams either fight the system or abandon it.
Give people a good way to do the unusual thing. Otherwise they will invent a bad one.
Adoption is an ergonomics problem. In every system we have seen succeed, using the library was strictly less work than not using it:
Track the percentage of UI rendered through system components, per team, and publish it. Not to shame anyone — to find where the system is failing. A team with low adoption is usually telling you something true about a missing component or an awkward API.
On our largest system engagement we replaced 640 divergent components with 74 token-driven primitives across four products. Feature design time dropped 46%. But the change that actually moved adoption was not the consolidation — it was publishing the package to the internal registry with codemods for every breaking change. Adoption went from 30% to over 90% in two quarters, and the design work had been finished before any of that happened.
Keep reading
Most breaches trace back to a design decision, not a coding mistake. Here is the two-hour session we run at the start of every build — and the template we use.
We rebuilt six sites this year. The same four fixes accounted for most of the gain every time — and image budgets were not the biggest one.
Demos are easy. Evaluation harnesses, grounding, injection defence and cost ceilings are what separate a prototype from a product.
Need this done, not just read?
If any of the above sounds like a problem you have, a thirty-minute call with the engineer who wrote it is free.
