Boeing Design System

The problem at scale

Boeing operates across dozens of internal product teams, mission-critical flight deck software, logistics tooling, enterprise applications, each with its own design history and front-end stack. Without a shared visual language, teams were encountering the same problems independently, shipping inconsistent experiences, and creating a design sprawl compounding until it was almost impossible to unwind.

The design system team was stood up to address this. I joined as part of the founding cohort, with responsibility spanning component design and code, standards, documentation, education, and cross-org adoption.

Component standards

Component standards work at a large enterprise isn't primarily a design problem. It's a communication problem. The harder work is establishing what "done" means in a way that multiple teams with different codebases and different definitions of quality can actually converge on. This took shape largely through the Starterkit: defining anatomy and naming conventions that could translate across frameworks, building documentation templates that surfaced usage guidance alongside visual specs, and creating the review patterns that kept component quality consistent as the library grew.

The Starterkit

Documentation tells teams how a system is supposed to work. It doesn't always show them. I built a Starterkit that gave designers and developers a single, live reference for component behavior, available options, and system standards, along with typography, patterns, and full page layouts they could copy and paste directly into a new build.

It also worked as a hub, linking out to each component's source file, documentation guide, code repository, Storybook entry, and Figma file, so anyone starting a new build had one starting point instead of hunting across five different tools to find the right source.

For designers, that meant seeing exactly how a component behaved and what variations were actually supported. For developers, it meant working code to reference and reuse directly instead of reverse-engineering intent from a Figma file or starting a page from scratch. Both groups pulled from the same source, which kept design and implementation from drifting apart as the library grew.

Adoption and coaching

A design system that isn't adopted is just documentation. The adoption work involved coaching designers on the design system team on how to structure Figma components and tokens in ways that would generate clean, predictable output, and working directly with product teams, helping them understand when to use a component versus diverge, and how to flag gaps back to the system team.

Token infrastructure

Token infrastructure only holds together when there's a clear relationship between design decisions in Figma and the tokens that implement them in code. I continually identified where that relationship was breaking down, work that fed into the design-to-engineering contracts that kept it intact.

What this work is

Enterprise design systems work is unusual because success is mostly invisible. That kind of work doesn't produce a single dramatic before/after. It produces a different trajectory.

The sign that it's working is that nothing breaks when teams move fast, that the system stays coherent as it grows, and that consuming teams feel enabled rather than constrained.