Aurora — Design System Rebuild

The brief

Aurora’s design system was, by 2023, 4 years old. It had grown organically alongside the product and was now showing the structural strain — three different button components, six border-radius scales in active use, components named things like Card2 and CardLegacy. The design and engineering teams were spending an estimated 11–14 hours/week each just navigating the system.

I was brought on to lead the rebuild as an independent. The remit was: take 9 months, work with the staff design + engineering leads, replace it without a re-platform.

The approach

The non-negotiable was that we couldn’t pause feature work for 9 months while the system caught up. Every incremental improvement had to ship behind a feature flag, with the old system continuing to work in parallel. We also had to keep both systems in lockstep on tokens (colors, type, spacing) so a component swap was never visually disruptive.

The architecture work itself was, in retrospect, the easy part. The hard part was the politics — getting 12 designers and 60 engineers to agree on which system was the correct one to use, which components were primitives versus compositions, and what the deprecation timeline looked like.

What I’m most proud of

The deprecation pattern. We never told anyone “don’t use the old component” — we just stopped iterating on it. Every PR that touched a deprecated component got a friendly bot comment with the new equivalent. Adoption happened naturally as people picked up tickets that touched legacy code. Twelve weeks in we had 60% adoption with zero mandates.

What I would do differently

Started the documentation site three months earlier. The system was usable from week 6, but the docs lagged until week 14, which created an avoidable trough where adoption was higher than understanding. Lesson: docs are not downstream of system work, they’re the system.