CASE STUDY
CASE STUDY
CASE STUDY
CarGurus
CarGurus
Chassis: The design system that changed how CarGurus ships
Chassis: The design system that changed how CarGurus ships
I led the creation of Chassis, a unified design system that reduced design debt, improved consistency, and helped product teams ship faster.
I led the creation of Chassis, a unified design system that reduced design debt, improved consistency, and helped product teams ship faster.
Design Systems
Product Design
Lead Designer
Year
Year
2025
2025
Industry
Industry
Automotive/Technology
Automotive/Technology
Space of work
Space of work
Design System
Design System
Timeline
Timeline
18 months
18 months
Overview
Building Chassis: A system that changed how teams build
CarGurus was growing fast but the product wasn't scaling with it. I led the creation of Chassis, a design system built from the ground up to reduce design debt, align teams, and support a full rebrand while still maintaining the legacy product. This work didn't just improve the UI. It changed how teams design and ship.
Overview
Building Chassis: A system that changed how teams build
CarGurus was growing fast but the product wasn't scaling with it. I led the creation of Chassis, a design system built from the ground up to reduce design debt, align teams, and support a full rebrand while still maintaining the legacy product. This work didn't just improve the UI. It changed how teams design and ship.
Overview
Building Chassis: A system that changed how teams build
CarGurus was growing fast but the product wasn't scaling with it. I led the creation of Chassis, a design system built from the ground up to reduce design debt, align teams, and support a full rebrand while still maintaining the legacy product. This work didn't just improve the UI. It changed how teams design and ship.
THE PROBLEM
Inconsistency slowed teams down and weakened the product
As CarGurus scaled, teams were building in parallel without a shared system. The same interactions got solved differently across products, which created inconsistent experiences and duplicated work across every team I was working with. This wasn't just a design issue. It affected how the whole organization operated: • Teams rebuilt the same components multiple times • Patterns changed depending on where you were in the product • Development slowed because there were no shared standards • Design debt kept growing with every new feature shipped What should have been simple became unpredictable.
THE PROBLEM
Inconsistency slowed teams down and weakened the product
As CarGurus scaled, teams were building in parallel without a shared system. The same interactions got solved differently across products, which created inconsistent experiences and duplicated work across every team I was working with. This wasn't just a design issue. It affected how the whole organization operated: • Teams rebuilt the same components multiple times • Patterns changed depending on where you were in the product • Development slowed because there were no shared standards • Design debt kept growing with every new feature shipped What should have been simple became unpredictable.
THE PROBLEM
Inconsistency slowed teams down and weakened the product
As CarGurus scaled, teams were building in parallel without a shared system. The same interactions got solved differently across products, which created inconsistent experiences and duplicated work across every team I was working with. This wasn't just a design issue. It affected how the whole organization operated: • Teams rebuilt the same components multiple times • Patterns changed depending on where you were in the product • Development slowed because there were no shared standards • Design debt kept growing with every new feature shipped What should have been simple became unpredictable.
THE GOAL
Create a system teams can rely on, not work around
The goal wasn't just consistency, it was clarity. I needed to build a shared foundation that eliminated duplicated work, aligned design and engineering, enabled faster and more confident decisions, and scaled across products and teams. • We needed a shared foundation that: • Eliminates duplicated work • Aligns design and engineering • Enables faster, more confident decisions • Scales across products and teams
THE GOAL
Create a system teams can rely on, not work around
The goal wasn't just consistency, it was clarity. I needed to build a shared foundation that eliminated duplicated work, aligned design and engineering, enabled faster and more confident decisions, and scaled across products and teams. • We needed a shared foundation that: • Eliminates duplicated work • Aligns design and engineering • Enables faster, more confident decisions • Scales across products and teams
THE GOAL
Create a system teams can rely on, not work around
The goal wasn't just consistency, it was clarity. I needed to build a shared foundation that eliminated duplicated work, aligned design and engineering, enabled faster and more confident decisions, and scaled across products and teams. • We needed a shared foundation that: • Eliminates duplicated work • Aligns design and engineering • Enables faster, more confident decisions • Scales across products and teams
CONTEXT
Evolving the system while the product was still live
Before Chassis, there was an early system—Concrete—but it lacked the structure needed to scale. At the same time, the company was preparing for a rebrand. We couldn’t start from scratch. We needed to build a new system that could: Support legacy UI without breaking existing flows Introduce a new visual language Scale across teams, products, and platforms
CONTEXT
Evolving the system while the product was still live
Before Chassis, there was an early system—Concrete—but it lacked the structure needed to scale. At the same time, the company was preparing for a rebrand. We couldn’t start from scratch. We needed to build a new system that could: Support legacy UI without breaking existing flows Introduce a new visual language Scale across teams, products, and platforms
CONTEXT
Evolving the system while the product was still live
Before Chassis, there was an early system—Concrete—but it lacked the structure needed to scale. At the same time, the company was preparing for a rebrand. We couldn’t start from scratch. We needed to build a new system that could: Support legacy UI without breaking existing flows Introduce a new visual language Scale across teams, products, and platforms
BEFORE
Legacy Design System - Concrete
Fragmented UI, inconsistent patterns, slower builds. Every new feature meant rediscovering decisions that had already been made.
BEFORE
Legacy Design System - Concrete
Fragmented UI, inconsistent patterns, slower builds. Every new feature meant rediscovering decisions that had already been made.
AFTER
Updated Design System Chassis
Unified system, consistent experience, faster development. Teams ship faster because the decisions are already made.
AFTER
Updated Design System Chassis
Unified system, consistent experience, faster development. Teams ship faster because the decisions are already made.
THE PROCESS
How I approached building Chassis
I broke the work into clear phases, each designed to reduce ambiguity, build shared foundations, and move teams toward a system they could actually use.
THE PROCESS
How I approached building Chassis
I broke the work into clear phases, each designed to reduce ambiguity, build shared foundations, and move teams toward a system they could actually use.
Audit & Align
I catalogued every component, pattern, and token across the existing system. Before anything was redesigned, I needed to know exactly what existed, what was duplicated, and what was already breaking.
Foundations
Token architecture and naming conventions came before any components. Getting the foundation right meant everything built on top of it would stay consistent automatically.
Build
I rebuilt the component library on top of the token foundation, one component at a time. Every variant, every state, every breakpoint accounted for before it was handed off.
Handoff and Iterate
I stayed embedded with engineering through implementation, reviewing builds and resolving edge cases. The hardest part was that the product was live the entire time, so every change had to work alongside the legacy system in parallel.
CONTRIBUTIONS
Aligning teams through shared systems
Adoption isn't automatic. We created onboarding documentation, ran cross-team workshops, and established naming conventions that both design and engineering agreed on. The system came with a shared vocabulary—so there was no gap in translation between a Figma file and a production build.
CONTRIBUTIONS
Aligning teams through shared systems
Adoption isn't automatic. We created onboarding documentation, ran cross-team workshops, and established naming conventions that both design and engineering agreed on. The system came with a shared vocabulary—so there was no gap in translation between a Figma file and a production build.
CONTRIBUTIONS
Aligning teams through shared systems
Adoption isn't automatic. We created onboarding documentation, ran cross-team workshops, and established naming conventions that both design and engineering agreed on. The system came with a shared vocabulary—so there was no gap in translation between a Figma file and a production build.
FOUNDATIONS
The foundation everything else is built on
Before components, I established the token layer. Semantic color tokens, a refined type scale using Rund Display and Graphik, and a structured color system covering primary, secondary, and pricing states. Getting this right first meant every component built on top of it stayed consistent automatically.
FOUNDATIONS
The foundation everything else is built on
Before components, I established the token layer. Semantic color tokens, a refined type scale using Rund Display and Graphik, and a structured color system covering primary, secondary, and pricing states. Getting this right first meant every component built on top of it stayed consistent automatically.
FOUNDATIONS
The foundation everything else is built on
Before components, I established the token layer. Semantic color tokens, a refined type scale using Rund Display and Graphik, and a structured color system covering primary, secondary, and pricing states. Getting this right first meant every component built on top of it stayed consistent automatically.
Building Chassis: A system that changed how teams build
CarGurus was growing fast—but the product wasn’t scaling with it. I led the creation of Chassis, a design system built from the ground up to reduce design debt, align teams, and support a full rebrand—while still maintaining the legacy product.
This work didn’t just improve UI—it transformed how teams design and ship.
Building Chassis: A system that changed how teams build
CarGurus was growing fast—but the product wasn’t scaling with it. I led the creation of Chassis, a design system built from the ground up to reduce design debt, align teams, and support a full rebrand—while still maintaining the legacy product.
This work didn’t just improve UI—it transformed how teams design and ship.
Building Chassis: A system that changed how teams build
CarGurus was growing fast—but the product wasn’t scaling with it. I led the creation of Chassis, a design system built from the ground up to reduce design debt, align teams, and support a full rebrand—while still maintaining the legacy product.
This work didn’t just improve UI—it transformed how teams design and ship.
COMPONENTS
Reusable components that scale across the platform
Built on top of the token foundation, every component was accessible by default, fully documented, and tested across breakpoints before it shipped. I built each one with every variant and state accounted for, so teams could use them without having to work around edge cases.
COMPONENTS
Reusable components that scale across the platform
Built on top of the token foundation, every component was accessible by default, fully documented, and tested across breakpoints before it shipped. I built each one with every variant and state accounted for, so teams could use them without having to work around edge cases.
COMPONENTS
Reusable components that scale across the platform
Built on top of the token foundation, every component was accessible by default, fully documented, and tested across breakpoints before it shipped. I built each one with every variant and state accounted for, so teams could use them without having to work around edge cases.
CHASSIS AT WORK
Built once. Used everywhere.
Chassis wasn't built to sit in a Figma file. I worked directly with product teams to apply it across the consumer-facing search and listing experiences, the dealer tools, and the mobile app. Each application stress-tested different parts of the system and surfaced edge cases that fed back into the component library.
CHASSIS AT WORK
Built once. Used everywhere.
Chassis wasn't built to sit in a Figma file. I worked directly with product teams to apply it across the consumer-facing search and listing experiences, the dealer tools, and the mobile app. Each application stress-tested different parts of the system and surfaced edge cases that fed back into the component library.
CHASSIS AT WORK
Built once. Used everywhere.
Chassis wasn't built to sit in a Figma file. I worked directly with product teams to apply it across the consumer-facing search and listing experiences, the dealer tools, and the mobile app. Each application stress-tested different parts of the system and surfaced edge cases that fed back into the component library.
GOVERNANCE
Designing for long-term scale
A design system without governance is a library with an expiration date. I built Chassis with a clear contribution model: how teams propose new components, how decisions get reviewed, and how the system evolves without fragmenting.
GOVERNANCE
Designing for long-term scale
A design system without governance is a library with an expiration date. I built Chassis with a clear contribution model: how teams propose new components, how decisions get reviewed, and how the system evolves without fragmenting.
01
Contribution model
Clear process for teams to propose, review, and ship new components into the system.
02
Versioning + changelog
Every update was tracked, communicated, and documented. Teams always knew what changed and why.
03
Maintenance ownership
Designated system owners with defined responsibilities. No single point of failure, no ambiguity.
04
Deprecation process
Old patterns retired gracefully—with migration guides and timelines that teams could actually follow.
THE IMPACT
A system that improved both speed and quality
Measurable results across design, engineering, and product teams.
THE IMPACT
A system that improved both speed and quality
Measurable results across design, engineering, and product teams.
0%
0%
REDUCTION IN DESIGN INCONSISTENCIES
0%
0%
FASTER DESIGN TO DEV HANDOFF
0+
0+
PRODUCT TEAMS ON ONE SYSTEM
0+
0+
COMPONENTS IN THE LIBRARY
DESIGN THINKING
The impact wasn't just the system. It was how teams worked differently.
Chassis changed more than what ships on screen. It changed how decisions get made, how design and engineering collaborate, and how quickly teams can move with confidence. When teams share a foundation, conversations shift. Less time debating whether a component exists. More time building features that matter. Less friction in handoff. More trust between disciplines. That's what a good design system actually does. It doesn't just make the product better. It makes the team better.
DESIGN THINKING
The impact wasn't just the system. It was how teams worked differently.
Chassis changed more than what ships on screen. It changed how decisions get made, how design and engineering collaborate, and how quickly teams can move with confidence. When teams share a foundation, conversations shift. Less time debating whether a component exists. More time building features that matter. Less friction in handoff. More trust between disciplines. That's what a good design system actually does. It doesn't just make the product better. It makes the team better.
DESIGN THINKING
The impact wasn't just the system. It was how teams worked differently.
Chassis changed more than what ships on screen. It changed how decisions get made, how design and engineering collaborate, and how quickly teams can move with confidence. When teams share a foundation, conversations shift. Less time debating whether a component exists. More time building features that matter. Less friction in handoff. More trust between disciplines. That's what a good design system actually does. It doesn't just make the product better. It makes the team better.
What building a system at scale taught me
CarGurus was growing fast—but the product wasn’t scaling with it. I led the creation of Chassis, a design system built from the ground up to reduce design debt, align teams, and support a full rebrand—while still maintaining the legacy product.
This work didn’t just improve UI—it transformed how teams design and ship.
What building a system at scale taught me
CarGurus was growing fast—but the product wasn’t scaling with it. I led the creation of Chassis, a design system built from the ground up to reduce design debt, align teams, and support a full rebrand—while still maintaining the legacy product.
This work didn’t just improve UI—it transformed how teams design and ship.
Systems > Screens
Strong foundations create better products. You can redesign a screen in a day. Rebuilding a system takes months. Get the foundation right.
Alignment is the hardest part
Getting teams to agree on naming, process, and ownership is more difficult than building any component. Do it first, not last.
Simplicity scales
The simpler the system, the easier it grows. Every unnecessary decision is a decision everyone downstream has to carry.
Documentation is the product
A component without documentation doesn't exist for most teams. The system is only as good as how well teams can understand and use it.
