I build design systems from zero and get them adopted. Orbit, the system I built at ENGIE Impact, is what 6 product teams across 8 countries now ship on.
Read the Orbit case studyWhen I joined ENGIE Impact there was no design system. Not an outdated one, not a neglected one. Nothing. Before building anything, I made the case for one in three steps.
A cross-team component audit surfaced what everyone already suspected: 30+ button variants in production, no shared tokens, and no clear owner.
The audit became the pitch. I translated duplicated design and engineering work into a cost leadership could weigh against headcount.
0
Est. hours of duplicated work per year
0.0
Est. headcount equivalent
An 18-month build plan with clear milestones, so leadership could see exactly what they were funding and who owned each phase.
Foundation
M1–6
Design-led
Scale
M7–12
Joint ownership
Govern
M13–18
Org-owned
The commitment I made, and held to: Orbit would reduce engineering work, not add to it.
30+ to 1
Button variants eliminated
200+
Components shipped
18 months
Zero to 200+ components
Leadership required Orbit across all six product teams. That got us compliance. Trust, contribution, and ownership had to be earned team by team.
Diagram: six product teams circle the Orbit core. Over 12 months all six adopt Orbit, then four of the six start contributing components back into it.
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 where Orbit wasn't serving them, then fix the component or open a new candidate.
Teams could propose missing components instead of building their own outside the system. Without a pathway, a mandated system breeds resentment. With one, teams feel invested in it.
Adoption rates by team, shared in quarterly reviews. Not a performance report, but a signal of where the system needed to grow. Teams saw their contributions prioritized in the next Orbit cycle.
12 months
To full adoption across all 6 teams
4 of 6
Teams contributing components back
50%
Design team size needed to ship major updates, vs. previous cycles
Every Orbit component had a readiness state, clear criteria for moving between them, and a fixed path for retiring. That structure got its real test before Orbit was even fully adopted.
Component lifecycle: Exploratory, proposed and under evaluation. Candidate, in review and seeking adoption. Stable, production-ready and governed. Deprecated, with a 90-day migration window before the old version is retired.
“Can we just keep both?”
Six months into the build, two teams flagged that year-old production components were being deprecated. The replacements were better, but migration meant unplanned engineering work.
We made migration as easy as possible. We didn't make it optional.
Every team made it.
And the pattern held: no deprecated component ever came back.
The moment you allow parallel tracks, the system stops being a system. It becomes a suggestion.
Built together
Token naming. The first working sessions on token semantics were joint, with designer and engineer building the conventions together before a single component was specced.
Every Orbit component shipped with every interaction state, token references, usage guidelines, and accessibility notes. The bar: if a designer couldn't use a component correctly without asking anyone, the documentation wasn't done.
State
Showing the Default state.
Tokens
color.border.defaultcolor.text.primaryradius.controlWCAG 2.1 AA in this state
Figma library
Storybook
TextInputComponent<TextInput />state = errorStatestate="error"size = mdSizesize="md"Component, prop, and state names matched across design and code. One source of truth, not two that drift.
Five beliefs, each one tested on Orbit. Every one links back to where you saw it on this page.
The audit became the pitch. A system nobody funded is a side project.
Seen in 01 · FoundationA 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.
Seen in 03 · GovernanceMandate gets you adoption numbers. Trust gets you contribution. The systems that last are the ones teams feel invested in.
Seen in 02 · AdoptionTokens are the handshake between design and code. If engineers didn't help name them, they'll work around them.
Seen in 03 · GovernanceA component that isn't fully documented isn't done. Full stop.
Seen in 04 · DocumentationThe Orbit case study covers the audit, the pitch, the governance decisions, and what I'd do differently.
Read the Orbit case study