Example
Work / Healthcare software
One library, two teams.
Two products from the same vendor had drifted into two interface kits, two sets of rules and one argument that came back every sprint.
An illustrative example. No client is named here until we have their written consent.
- Client
- A healthcare software vendor
- Sector
- Healthcare software
- Team shape
- A designer and an engineer, embedded
- Engagement
- Audit, then a staged rollout with adoption support
The work
How the library came together
A design system is a governance problem wearing a component library's clothes. This is how we treated it.
The vendor ran two clinical products with separate front-end teams, separate release trains and, by the time we arrived, two interface kits that agreed on almost nothing. Neither team was wrong. Each had solved its own problems in isolation, and the cost only became visible when a shared screen had to be built twice.
The challenge
The brief we were given was to unify the components. The brief we accepted was narrower and harder: agree what a component is allowed to decide, and what belongs to the product using it. Without that line, one library becomes a place where two teams keep arguing, only now in code review.
The audit turned up the usual pattern behind the drift — several near-identical buttons, form fields that handled validation differently in each product, and spacing values that had been rounded by hand until no two screens shared a rhythm. Documentation existed for both kits and matched neither.
The approach
We started from tokens rather than components, because a shared vocabulary is what makes a shared component reviewable. Colour, type, space, radius and motion were defined once, published for both design and code from a single source, and mapped onto each product's existing screens before anything was rebuilt.
- One token source, published to Figma and to the front-end packages from the same file.
- Components built in the open, each with its states, its accessibility notes and its usage boundary written down.
- A contribution route, so a team that needs a variant proposes it instead of forking it.
- Migration done screen by screen, with the old kit left working until the last screen moved.
The library shipped as a versioned package in the vendor's own registry, with the review rights held by their engineers. A system nobody outside the client can release is a dependency, not a system.
Where it landed
Both products now build new screens from the same parts, and a change to a token reaches them in one release rather than two hand-written patches. The documentation is the library's own site, generated from the components, so it goes stale only when the code does.
The more useful change is quieter. Design review moved off the details the system already answers and onto the questions it cannot — what a clinician needs to see first, and what the screen should refuse to let them do.
The library
Every part documented where it is used.
Component documentation, generated from the source.
The problem
Two kits, one product family
We began by putting both interfaces side by side, screen for screen, and counting the places where they made the same decision differently. It is an unglamorous exercise and it settles arguments quickly, because the disagreement stops being a matter of taste.
What the audit showed was not carelessness. It was two teams paying, separately, for a decision nobody had been asked to make.
- A screen both products needed, designed and built twice.
- A release held while the other kit caught up.
- Review time spent on taste rather than on the product.
The approach
Tokens first, components second
Tokens gave both teams a shared vocabulary before either had to give up a component. Once colour, type and spacing meant the same thing in Figma and in the packages, the component review became a short conversation instead of a negotiation.
We rebuilt in the order the products needed, not in the order the library looked tidiest, and left the old kit running until the last screen had moved.
- The library owns how a part behaves; the product owns when to use it.
- Every variant has a named owner, or it does not ship.
- Wording, page layout and clinical language stayed product-side.
In their words
Two teams stopped arguing about buttons and started arguing about the product again, which is the argument worth having.
An illustrative quote. We publish a client's words only with their written consent.
Details
Three pieces of the system
Token scales, before they became components. Form fields, states and error messages in one place. The migration board, screen by screen.
This case study is an illustrative example. The client, the quote and every image on this page stand in for real work we cannot publish yet, and no client is named without written consent.Ask us about comparable work