← Work

Accelerating a Unified UX with Adobe’s Spectrum Design System

Overview How I led Adobe's internal developer platform through a migration from our homegrown design system, Stardust, to Adobe Spectrum, and how that decision scaled our frontend org from 3 people to a team of 8 servicing 100+ engineers.

Impact Deprecated 70% of legacy UIs before pivoting to a unified developer portal, consolidated four separate web apps into a single developer portal, and grew the frontend team to ~8 people while enabling multiple backend teams to build and ship full UIs completely independently.

Role Senior Engineering Manager — Developer Experience (led UX & frontend development) Team ~8-person frontend team servicing an org of ~100 engineers

The Context

In 2019, I had been at Adobe two years and the homegrown design system I’d built to scale our design, Stardust, had proven its value and the value of using design systems in our team’s product work. Backend engineers were shipping UIs independently and the platform felt more consistent. But maintaining a design system, even a small one, isn’t free.

So when Adobe announced Spectrum, the company’s official customer-facing design system, we had a decision to make. I gave a talk about this work, “Gatekeepers to Gardeners”, at Øredev in Sweden in 2022.

Me presenting "Gatekeepers to Gardeners" at Oredev in Sweden, 2022
Figure 1: Me presenting "Gatekeepers to Gardeners" at Oredev in Sweden, 2022

Stardust got us far. It gave us structured CSS, a Sketch component library, a CDN-hosted stylesheet, and a PHP documentation site, all built quickly and pragmatically by a small team. But it was ours to maintain. Every accessibility improvement, every new component, every design token update was our responsibility, and it diverted resources away from the feature work.

Spectrum was a full design system built and maintained by a dedicated Adobe team, with comprehensive principles and guidelines, a thorough Figma UI toolkit with hundreds of component variations, a complete React implementation (React Spectrum), a CSS library (Spectrum CSS), web components, detailed documentation, and an open source contribution model.

The comparison wasn’t close.

The Decision

We chose Spectrum for the same reasons we built Stardust in the first place:

  • Stop duplicating work: Maintaining a parallel system when a better one existed was replicating work.
  • Become contributors to something bigger: Our efforts would have more impact contributing to Spectrum than maintaining Stardust in isolation.
  • Expand past Adobe: Spectrum is open source, meaning our contributions benefited the wider design system community.

The harder question wasn’t whether to migrate. It was how to manage the transition without disrupting the teams that had built workflows around Stardust.

The Migration

The first step was deciding that from that moment on, everything we released would be in React Spectrum. This meant that we might have a few mismatched UIs during the migration, part Stardust and part Spectrum, but we accepted that as a necessary drawback.

For existing UIs, we took a phased approach. Rather than a disruptive big-bang migration, we deprecated legacy views as we built replacements in Spectrum, and used each rebuild as an opportunity to also improve the UX.

OrCA onboarding UI, before consolidation into Ethos Home
Figure 2: OrCA onboarding — one of the standalone apps later consolidated into Ethos Home — with outdated elements and confusing UI

We also used the migration as a forcing function to consolidate. Our platform had been four separate web apps with four separate login experiences. With Spectrum as the new foundation, we consolidated them into a single developer portal with a unified navigation, a consistent visual language, and one login.

Ethos Home onboarding view rebuilt in Spectrum, mid-progress
Figure 3: Rebuilt in Spectrum with consistent nav and cleaner layout
Ethos Home onboarding view showing the completed state
Figure 4: Completed onboarding also rebuilt with Spectrum

Growing the Org

The Spectrum migration coincided with significant team growth. With a robust, well-documented system, we could onboard new frontend engineers faster and direct their energy toward product work rather than infrastructure maintenance.

The frontend team grew from 3 to 8 people at its largest. But more importantly, the org we served grew to over 100 engineers, and a meaningful portion of them were shipping UIs independently, without our team’s involvement. We also tracked:

  • 70% of legacy UIs deprecated and replaced with Spectrum before pivoting to a unified developer portal
  • 8 backend teams shipping full UIs independently
  • Multiple active contributions made back to the Spectrum open source project
  • Four separate web apps consolidated into a single developer portal
Adobe Catalog — 10,000+ services registered across the platform
Figure 5: The Adobe Catalog: 10,000+ services registered across the platform, unified in a single portal built on Spectrum.

Lessons Learned

The decision to stop investing in Stardust was the right call, but it wasn’t automatic. We’d built something we were proud of, and there was real attachment to it, among the frontend team and also the developers we were working with.

What made it easier was going back to first principles: the goal was never to have a design system. The goal was to let our team’s engineers ship good UIs without being blocked. Spectrum served that goal better than anything we could build ourselves.

The broader lesson: knowing when to stop building your own thing is as important as knowing how to build it. The best tools for your team aren’t always the ones you made.