I take a drifting component library and turn it into a governed system that streamlines delivery across all 10 product teams at Nextens. The method is three steps in a fixed order: consolidate, connect, govern.
When the work starts in December 2022, Nextens has two component libraries. One lives in Figma, the other in code, and they drift further apart with every release. Nobody owns them. No rule says how a component may change, so teams build around the gap.
I start with the foundations and work up to components. By Q1 2024 all 10 product teams build with the system, and a lead developer maintains Storybook together with my team. The next step makes the system readable for AI.
The old Figma library shows the problem at a glance. Button versions V1 and V2 sit side by side, next to frames marked work in progress. The secondary button is blue in one version and red in the next. In total there are 20 button variants and more than 20 dropdowns.
The code library is a separate set again, and nothing keeps the two in step. Every release widens the gap between what is designed and what ships.
Inconsistent components give inconsistent screens, in a product where clarity is a compliance matter.
Drift between design and build costs engineering time on rework and adds refinement rounds to every feature.
Nobody owns the system and no rule says how it changes, so people work around it.
I own the system end to end: the consolidation, the workflow and the governance. The hard part is adoption by teams that do not report to me. So the system has to fit the way engineers already work, or they will route around it the way they route around the old one.
Complexity has to earn its place. When a simpler version gives most of the value, the simpler version wins, because adoption is the measure.
Cut the variants down before you add a single rule.
One workflow from design to build, with an owner on each side.
A clear rule for every new component.
Three principles carry the playbook. Each one has a cost, named under it.
The first design system meeting, in December 2022, is about typography. From the foundations I work up to components. 20 button variants become 4, and more than 20 dropdowns become one configurable component. Size, state and icons turn into properties of a single component.
Trade-off: short-term disruption to work in progress, in exchange for a system small enough to govern.
Every component moves through the same workflow. The UX team takes it from task to ready, and ready means documented. A product team builds it, UX and QA review it, and it ships to Storybook and Figma at the same time. A lead developer maintains Storybook with my team.
Outcome: engineering co-owns the system, so using it is the easy path.
Before anyone builds something new, a decision tree asks three questions. Does a similar component exist? Can it be adjusted? Should the adjustment be available to everyone? A component that only one context needs stays local. Everything else goes through the workflow.
Trade-off: real governance overhead, justified by the drift it prevents.
The before and after in one picture. On the left, the variants that teams pick from in 2022. On the right, the system they build with today: four button types, one configurable dropdown, and one workflow between Figma and Storybook.
New ideas land on the UX backlog as a component. The UX team designs it, reviews it as a team and documents it before it counts as ready. Before the sprint, the delivery manager and the developers decide when it gets built. After UX review, QA and code review, the component goes live in Storybook and Figma together, and the developers hear about it in their channel.
The contribution rules decide what enters the system. Reuse comes first, then adjustment, then a new component. A component that one context needs and nobody else can reuse stays a local exception, outside the library.
Drift has one definition: a component that enters the product without going through the workflow. That definition makes drift countable. Last year there is one incident, where drift used to be routine.
What the playbook delivers at Nextens.
Delivery speeds up as teams reuse components and page layouts. Together with pre-refinement, refinement rounds on larger features drop from about 12 to about 4, and on small features from 3 to 1, by team count. The other half of that story is in the UX function case study.
In 2026 I audit both libraries again, this time to see what an AI tool can understand. Storybook holds 99 components, 97 of them active. Figma holds 87. 51 of those match Storybook one to one. 4 exist only in Figma, and 32 are uncertain.
That gap matters more now. Figma Make reuses a pattern only when it understands what the pattern is for. So the next phase is a semantic model of the system: what each component means and when to use it, before any decision about tokens. Designers validate every meaning. The AI does not decide them.
The baseline is done. The semantic model is in progress.
Governance is a human problem. The components are the easy part. The system lasts because it fits the way engineers already work, and because a developer co-owns it. Consolidate, connect, govern works in any product organisation with one component library and more than one team.
Formalise the contribution model earlier. The decision tree arrives after the first wave of components. In place from day one, it lets the system grow its maintainers as fast as its users.