I've built design systems from zero — not as a library project, but as infrastructure for how organisations design and ship. Orbit, the system I built at ENGIE Impact, is the foundation 6 global teams across 8 countries now depend on.
Read the Orbit case studyWhen I joined ENGIE Impact there was no design system — not an outdated one, not a neglected one. Nothing. I started with a cross-team component audit that surfaced what everyone already suspected: 30+ button variants in production, no shared tokens, no clear owner, and roughly 3,200 hours of duplicated design-and-engineering work per year.
The audit became the pitch. I came to leadership with three things: the findings quantified, a cost estimate that translated waste into headcount equivalent, and a phased 18-month build plan with clear milestones. The commitment I made — and held to — was that Orbit would reduce engineering work, not add to it.
30+ → 1
Button variants eliminated
200+
Components shipped
18 months
Zero to full org adoption
Leadership required Orbit adoption across all six product teams. A mandate gets you compliance — it doesn't get you trust, contribution, or a system teams feel ownership over. Those had to be earned team by team.
For the first three months of each team's adoption I ran standing weekly design reviews with their designer — not to approve their work, but to catch cases where Orbit wasn't serving their needs and either fix the component or open a new candidate.
Teams could propose missing components rather than building their own outside the system. Without a contribution pathway, a mandated system breeds resentment. With one, teams feel invested rather than subjected to it.
Component adoption rates tracked by team and shared in quarterly reviews — not as a performance report, but as a signal of where the system needed to grow. Teams saw their contributions prioritised in the next Orbit cycle.
12 months to full adoption across all 6 teams in 8 countries. 4 of 6 teams contributing components back into Orbit.
Every component in Orbit had a readiness state with clear criteria for moving between them.
Exploratory
Proposed, under evaluation
Candidate
In review, seeking adoption
Stable
Production-ready, governed
Deprecated
90-day migration window
Design owned component specification, token structure, and contribution standards. Engineering owned implementation and had a defined seat at the table on any deprecation or structural change. The first working sessions on token semantics were joint — designer and engineer building the naming conventions together before a single component was specced.
When two teams flagged that their in-production components were being deprecated, I held the line: no parallel "legacy" track. A 90-day migration window with a clear migration guide, allocated engineering support hours, and a named owner per team. Every team made it. No deprecated component ever came back.
Every Orbit component shipped with complete documentation: all interaction states, token references, usage guidelines, and accessibility notes. The bar: if a designer couldn't use the component correctly without asking anyone, the documentation wasn't done.
Default, hover, focus, error, disabled, success — every state spec'd before a component reached Stable.
Focus visibility, color contrast, label association, and error identification were part of the spec — not a checklist item at the end.
Designers and engineers saw the same token names so handoff was a non-event. No translation layer, no ambiguity.
Component names, prop names, and state names matched across design and code. One source of truth, not two that drift.
A design system is infrastructure, not a library.
The goal isn't a beautiful Figma file. It's reducing the cost of decisions made repeatedly across teams — in design, in engineering, in QA.
Governance before growth.
A system without deprecation rules is a system that will eventually have two of everything. Set the rules for how components age out before you need them.
Design systems are earned, not mandated.
Mandate gets you adoption numbers. Trust gets you contribution. The systems that last are the ones teams feel invested in.
The token layer is where systems live or die for engineering.
Tokens are the handshake between design and code. If engineers didn't help name them, they'll work around them.
Documentation is part of the component.
A component that isn't fully documented isn't done. Full stop.
The Orbit case study covers the audit, the pitch, the governance decisions, and what I'd do differently.
Read the Orbit case study