[ Case study ]
Three teams had shipped three interfaces that shared a brand and nothing else — different button styles, three date pickers, and inconsistent density that made the product feel assembled. Every team rebuilt the same components slightly wrong.
CLIENT an insurtech scale-up (3 product teams) — FOCUS Audit the three products into one inventory
Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.
Three product teams — quoting, policy administration, and claims — work out of one office but have never shared a component. The company sells to mid-market brokers and has grown from one team to three in eighteen months; each team inherited a different contracting agency's front end and kept it. Design happens in three separate Figma spaces, engineering holds a small shared CSS file of variables nobody maintains, and the newest team's hires keep asking which version of a button is the real one. Nobody owns the answer.
Three teams had shipped three interfaces that shared a brand and nothing else — different button styles, three date pickers, and inconsistent density that made the product feel assembled. Every team rebuilt the same components slightly wrong.
We proposed one Figma library governed by design variables mapped one-to-one to the frontend's existing CSS custom properties, adopted team by team through real feature work rather than a migration decree. The reasoning: adoption had to be cheaper than rebuilding — if pulling a component from the library was faster than drawing a new one, the system would spread on its own. Mapping tokens to the variables engineering already maintained meant zero code changes at adoption, which removed the engineering objection entirely. Each team's next feature became the pilot: the library proved itself in their backlog before anyone asked them to trust it.
Just as important is what we ruled out, and why:
Every button, input, and pattern across the three products was catalogued and consolidated into one component inventory — with the differences named, not smoothed over.
Design Variables were mapped 1:1 to the frontend's CSS custom properties, so adopting the system changes no code — it changes what's drawn from it.
Each team adopted the shared components for their next feature, so the system proved itself in real work before anyone mandated it.
Delivered by the experience pod — 2 designers over 9 weeks, with working increments reviewed with the client every week.
Obstacle
Week six: the claims team's newest screens were built on inline hex values instead of the shared CSS variables, so the token mapping covered the older code but not the newest quarter of it.
Handled: We added an inline-style inventory to the audit, mapped the stray values back to tokens, and the senior engineer refactored the worst offenders during the claims team's pilot feature.
Obstacle
The most senior engineer reviewed the Variables structure in week six and rejected two naming decisions our mapping depended on — his constraints reshaped the token structure after it was documented.
Handled: We treated the objection as an audit finding, renamed the affected tokens, and re-published; the walkthrough cost a week but bought the engineering credibility the rollout needed.
The headline: component systems in use across the product, with per-team duplicates retired — 3 → 1, read from Figma library adoption audit. A second check: design-to-build qa defects on the first three feature builds post-adoption at −40%.
The question that used to open every design review — which version is the real one — stopped being asked, because the library file finally matched production. New designers started from components instead of screenshots, and engineers stopped rebuilding the same table three times; the argument moved from pixel differences to whether a pattern deserved to exist. The three teams still argue, but they argue in the same vocabulary now, and per-team duplicates began retiring without anyone decreeing it.
The result was read from Figma library adoption audit against the pre-engagement baseline over the stated window, with a guardrail check on design-to-build qa defects on the first three feature builds post-adoption. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.
What we would do differently
We would have included the most senior engineer from day one — his CSS-token constraints reshaped the Variables structure in week six when it should have been week one.
[ Related service ]
[ Related builds ]
[ Next step ]
Next case study
