Orbit Design System

When I joined ENGIE Impact, there was no design system. Not an outdated one. Not a neglected one. Nothing. Every designer, on every team, was solving the same problems in isolation: building buttons, modals, data tables, and form patterns from scratch, sprint after sprint, with no shared reference point and no reason to coordinate.

The result was organizational drag, not just inconsistency. Engineering kept rebuilding the same components slightly differently for each team. Design reviews became debates about button radius instead of user problems, and new designers spent their first weeks reverse-engineering decisions already made six times elsewhere.

The breaking point was a cross-team audit: I cataloged every component in active use and found it was worse than anyone guessed, four types of fragmentation (visual, behavioral, implementation, ownership). The visible symptom was 30+ button styles in production; the deeper issue was each one encoding different spacing, hierarchy, state, and accessibility decisions, with no shared tokens and no clear owner.

That audit became the document that changed everything, not because it surprised anyone in the room, but because it made the cost visible in a language leadership and engineering could act on.

The pitch to leadership was straightforward once I had the audit data. A design system is an infrastructure investment, and infrastructure arguments land well when you can show the compounding cost of not having it. I came to that conversation with three things: the audit findings, an estimate of duplicated design-and-engineering hours per quarter across teams, and a proposed phased build plan with clear milestones. Leadership approved a dedicated workstream.

The harder conversation was with the engineering lead.

The concern wasn't philosophical. It was practical. Build time. Maintenance burden. The fear that a centralized component library would become another thing engineering was responsible for keeping alive while shipping products.

That question shaped the entire governance model I built for Orbit. My answer: the system had to be owned jointly, or it wouldn't survive past v1.

I also made a commitment I had to keep: that Orbit would reduce engineering work, not add to it. Every component we shipped had to be more complete, more accessible, and better documented than what it replaced. That commitment became the standard I held every Orbit contribution to for the next 18 months.

Orbit's first major governance crisis came before it was even fully adopted.

Six months into the build, two teams flagged that year-old production components were being deprecated. The replacements were better (more accessible, more consistent, token-compliant), but migration meant unplanned engineering work. Their request was predictable: can we just keep both?

I chose not to support parallel tracks: keeping both would have taught teams that Orbit was optional. Instead, I set a 90-day migration path: documentation, engineering support hours, and a named owner per team. We made it as easy as possible. We didn't make it optional.

Not because the cost wasn't real, but I'd watched design systems fragment into "legacy" and "current" sections treated as equals, and teams under delivery pressure always choose the path of least resistance.

One team pushed to keep its existing form components since migration wasn't planned in the sprint. We used that case to pressure-test the model: what support did teams need, what timeline was realistic, what happened if we allowed exceptions?

Every team made it. And the pattern held: no deprecated component ever came back.

Leadership required Orbit adoption across all six product teams. I want to be honest about what that means, and what it doesn't. A mandate gets you compliance. It does not get you trust, contribution, or a system that teams feel ownership over. Those things had to be earned separately, team by team.

The v1.0 spec sheet above reads as a single reference image, but every line on it was a decision that design and engineering had to agree on together. Here's what that agreement actually covered.

I'd pull engineering into authorship earlier: specifically around token semantics and the deprecation model.

The token architecture I designed was sound, but it was designed by a designer. When we hit the first major deprecation cycle, the gaps became visible: the naming conventions I'd chosen made sense to design, but created confusion for engineers mapping tokens to implementation. We resolved it, but the resolution took weeks of back-and-forth that a collaborative authorship process at the start would have eliminated.

The lesson wasn't that designers shouldn't lead design systems. They should. It's that "lead" doesn't mean "design in isolation and hand off." The token layer is where design systems live or die for engineering teams, and that layer needs engineering's fingerprints on it from week one.

If I were building Orbit again, the first three working sessions would be joint: designer and engineer, building the token semantics together before a single component was specced. Adoption would have been faster. Deprecation would have been smoother. And the engineering lead who was the hardest person to convince at the start might have been the first advocate.

Orbit isn't the product. It's what made the products possible to build at scale.

It took 12 months to reach full adoption across all six teams. Once it did, three major product areas shipped significant feature updates with design teams that were half the size they'd been in previous cycles, because they weren't rebuilding foundations on every sprint.

That's the measure I care about. Not the component count. The question I ask about any design system is: did it make the organization faster and more coherent? For Orbit, the answer is yes.