A Design System is a Product
Most design systems start as a design team side project and then stall. How do you get an entire product organization to adopt one and keep investing in it?
My role: Product leadership, design leadership
Outcome: A design system run like a product, with its own team, roadmap, and release cycle, adopted across the product organization and integrated into how teams build features.
The Problem
I joined just as my team at United Airlines was building the foundation for the design system. The goal was ambitious: scale it quickly and get the entire product development organization to adopt it. This was also in the middle of three other major initiatives: consolidating back-end code-bases from 3 to 1, a front-end upgrade to React and a complete brand redesign.
The risk was familiar. A design system built and owned only by designers will be seen as the design team's project, and other teams will treat it as optional. But we had 27 different styles of buttons across our web and mobile applications. Teams were spending time they didn’t have solving the same problems over and over again.
The Approach
To scale quickly, I built a product team around the design system and ran it with the same rigor as any other product.
As with any product, the first step was articulating the vision and the value clearly enough to win stakeholder and leadership support. The team was staffed like any other product team. It was a full-stack team with a product owner, designers and front -end developers. And the team ran the same way as every other product team: a roadmap and backlog, consistent release cycles, and Agile ceremonies.
Built to Last
It mattered that the system wasn't seen as the design team's property. It belonged to everyone in the organization. And it was built with full WCAG accessibility compliance to ensure accessible components across both the web and mobile applications. Now 7 years later, the system is still in use by over 40 designers and just supported another brand redesign.
