Carrier☉Shipped 2024

A fresh start for Air

Overview

When I joined Carrier, the design system had evolved into a fragmented mix of MUI components, custom patterns with limited parity between design and implementation, and outdated dependencies that introduced unnecessary complexity. This made the system harder to maintain, harder to scale, and less reliable for teams across design and engineering.

Scaling Air

Modern components for efficient libraries

To tackle this, I led a full modernization of the system architecture across design and development touchpoints. I audited outdated components, rebuilt them to align with current standards, reduced redundant variants, and established more predictable structures that were easier for designers to use and engineers to translate into production. I partnered with engineering to ensure component behavior, states, and naming conventions were clearer and more implementation-ready, reducing ambiguity between design intent and front-end execution. To help close the gap even further, I also made targeted updates to the coded React components myself, creating pull requests in Bitbucket to improve parity, resolve inconsistencies, and support a more reliable shared system.

Flexibility without detaching

We introduced Placeholder Slot components where appropriate to mirror the flexibility already supported in the React implementation, allowing designers to handle custom content and edge cases through Instance Swapping without detaching the parent component or pattern.

Connected tooling

I also helped establish a connected workflow around Air that linked design, engineering, documentation, and QA into a more unified system. Figma supported component design and prototyping, Storybook provided coded references and implementation guidance, Supernova centralized tokens and standards, Bitbucket supported version control and engineering collaboration, and Chromatic helped catch visual regressions before release. This ecosystem improved traceability between design decisions and front-end outputs, making it easier for teams to align on source of truth, validate changes, and scale adoption with greater confidence.

A strong first step

The result was a faster, leaner system that improved consistency, reduced technical debt, and gave teams clearer implementation guidance. By simplifying component structures and improving documentation, we made the system easier to adopt, easier to maintain, and more reliable across both design and development workflows.

Guidance

How we stopped reinventing and started sharing

While Air was maturing in design and code, it lacked a third critical pillar: documentation that could support users at multiple levels of technical depth. Without a centralized source of truth, designers relied on scattered files, engineers lacked consistent implementation guidance, and teams often recreated patterns or interpreted standards differently. As adoption grew, it became clear that the system needed more than components and code — it needed shared guidance that could align teams around how the system should be used, extended, and maintained.

Co-creating our design standards

To meet that need, I partnered closely with design and engineering to build a more comprehensive guidance model that documented component behaviors, usage patterns, states, tokens, and best practices in a way that supported both day-to-day adoption and longer-term system governance.

I also led enablement sessions for designers and engineers around workflows like Figma’s Ready for Dev Mode, helping teams strengthen design-to-development handoff and make better use of the system in practice.

Infrastructure across Carrier

What emerged was more than documentation, it was a shared design language that transformed how Carrier's design teams worked. New designers could onboard in days instead of weeks. Teams started contributing back to the system, proposing improvements based on their usage. Most importantly, designers across Carrier began seeing Air not as a constraint, but as a foundation that let them focus on solving the problems that really mattered.

Air 2.0

A rebrand and a reset

The rebrand from Fleet to Air arrived at the right time. Behind the scenes, I had already been building a backlog of system improvements, including clearer property naming, scalable sizing conventions, component demos, and stronger design principles. The rebrand gave those efforts a clear moment to come together in a more cohesive 2.0 release.

More than a visual refresh

Air 2.0 became a maturity milestone for the system. Beyond the new identity, it strengthened the shared foundation across design and engineering through clearer standards, improved guidance, and more effective demos that helped teams adopt components more confidently and consistently.

Built to scale

The release changed how teams worked with the system day to day. Designers and developers gained more standardized workflows, clearer guidance, and better onboarding support, while the component demos became practical tools for adoption. Air emerged with both the identity and operational foundation it needed to scale more effectively across Carrier’s ecosystem.

Tools to unlock efficiency

To support adoption at scale, I also built a series of custom Figma plugins that reduced repetitive work, improved consistency, and filled workflow gaps that Figma did not natively solve.