Design system migration across two products

The problem

A US translation-management company sold its offering through two core frontend products. Both had grown the way products grow under delivery pressure: color values written inline at the point of use, spacing and type decided per screen, and more than one UI library in the dependency tree.

The cost was not aesthetic. It was that no change to the shared visual language had a single place to happen. Adjusting one color meant finding every literal that meant that color, across two codebases, and being confident you had found them all. Every team building on the platform paid that tax, and the platform team paid it twice.

What made it hard

Three constraints shaped everything that followed.

Two products, not one. Anything I built had to work for the newer product and the legacy one, which had different conventions and different tolerance for churn.

Multiple UI libraries. Consolidating onto a single library would have been a rewrite. The system had to present one coherent interface over components that were not all the same underneath.

Delivery could not stop. Nobody was going to freeze the roadmap for a foundations project. The migration had to be something teams moved through while they shipped, not instead of shipping.

My role

I became lead developer within the platform foundations team and drove the internal design system: the technical direction, the component work, and the part that actually decides whether a design system survives — getting it adopted.

The decision that shaped the project

The tempting version of this project is a clean new system, built properly, living alongside the products until they are ready for it. It stays consistent, it demos well, and it is a far nicer codebase to work in.

I went the other way and treated adoption as the deliverable rather than the system. A design system nobody has migrated onto is a second source of truth, and a second source of truth is worse than the mess it replaced: now there are two answers to what the color is.

That choice made the work harder and the outcome real. Foundations had to land in a form the legacy product could actually consume. Components had to be adoptable one at a time rather than as a version bump. And progress got measured in what was rendering from shared foundations in production, not in what existed in the library.

How the migration ran

• Foundations first. I reworked the color system into a shared foundation, then migrated hardcoded and inconsistently used values onto it. Color is the highest-leverage layer to unify first: the values most often duplicated, and the ones most visibly wrong when they drift.
• Components standardized in place. Dozens of reusable components brought under one coherent interface across the UI libraries in play, so consumers wrote against the system rather than against whichever library sat underneath.
• Adoption, product by product. I led the rollout across both core products, including carrying the legacy one toward the unified implementation.
• Down the stack where it mattered. Where the migration changed product behavior rather than product appearance, I worked across frontend and backend to land it.

Where it landed

Both core products build on the system, and it became the shared standard behind the company's offering. A change to the shared visual language now has one place to happen.

What I took from it

The component work was the smaller half. What decided the outcome was sequencing: choosing which layer to unify first, keeping each step small enough that a product team could absorb it inside normal delivery, and accepting that the system had to be less elegant than it wanted to be in order to reach code that already existed.

Client details are limited by confidentiality. The migration strategy, the trade-offs, and what I would do differently are all fair game in an interview.