The design system supporting 100M+ students and teachers

Transforming 8 years of tech debt into a scalable foundation for Code.org's learning platform, AI tools, and marketing ecosystem.

Role
Senior Product Designer
Timeline
2023–Present
Scope
Core platform, AI tools, marketing sites

Context

Eight years of rapid growth had produced wildly inconsistent code, no design-to-production parity, and accessibility gaps across a platform serving millions. Designers couldn't design consistently, and a backend-heavy engineering team struggled to ship experiences that matched specs.

A functioning design system wasn't a nice-to-have—it was infrastructure for learning tools, teacher dashboards, and marketing sites across multiple brands.

Approach

1/4

Audit first, then evangelize

I started by cataloging existing usages and mapping future needs. Only after understanding the landscape did I shift to evangelism and building support structures to drive adoption.

A simpler variable architecture

We built a semantic layer over primitives in three categories: surfaces, text, and borders. More flexible than component-driven systems, it enables brand-tailored experiences from one foundation.

Making contribution easy

Adoption required more than documentation. I empowered designers to use components correctly, helped engineers implement with parity, and opened the system to contributions from the wider team.

The MUI pivot

When our ground-up approach hit limits, we refactored onto MUI’s unstyled components. We de-risked by testing in a secondary brand first, now progressively migrating the core platform.

Impact

Component usage grew from roughly 50–100 instances to thousands, and the system is now used by 40+ engineers across the organization. It became the shared foundation for the core learning platform, new AI tools like Web Lab 2, and the CMS-powered marketing ecosystem—closing accessibility gaps and establishing design-to-production parity for the first time.

Work

1/4

Work image 1 of 4: The DSCO component library—built for consistency, designed for flexibility.

The DSCO component library—built for consistency, designed for flexibility.

Learnings

  • Buy-in comes from demonstration, not enforcement—showing working components earned more adoption than any mandate.
  • Robustness doesn't require complexity—a three-category semantic layer scaled further than a rigid component taxonomy.
  • Accessibility isn't a feature—it's a foundation that has to be baked into the system from day one.