CASE STUDY
CASE STUDY
CASE STUDY
CarGurus
CarGurus
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
About the project and my role
CarGurus is one of the largest online automotive marketplaces in the US. The platform connects millions of car buyers with dealers nationwide and operates across web, iOS, and Android. At the scale CarGurus operates, design decisions affect millions of users across two very different audiences: consumers shopping for cars and dealers running their business. I joined in August 2023 as Senior Experience Designer. My primary responsibility was the design system: building and owning Chassis across 8 product teams, covering token architecture, component governance, and documentation. I also worked directly on product features for both the consumer and dealer-facing sides of the platform.
Overview
About the project and my role
CarGurus is one of the largest online automotive marketplaces in the US. The platform connects millions of car buyers with dealers nationwide and operates across web, iOS, and Android. At the scale CarGurus operates, design decisions affect millions of users across two very different audiences: consumers shopping for cars and dealers running their business. I joined in August 2023 as Senior Experience Designer. My primary responsibility was the design system: building and owning Chassis across 8 product teams, covering token architecture, component governance, and documentation. I also worked directly on product features for both the consumer and dealer-facing sides of the platform.
Overview
About the project and my role
CarGurus is one of the largest online automotive marketplaces in the US. The platform connects millions of car buyers with dealers nationwide and operates across web, iOS, and Android. At the scale CarGurus operates, design decisions affect millions of users across two very different audiences: consumers shopping for cars and dealers running their business. I joined in August 2023 as Senior Experience Designer. My primary responsibility was the design system: building and owning Chassis across 8 product teams, covering token architecture, component governance, and documentation. I also worked directly on product features for both the consumer and dealer-facing sides of the platform.
THE PROBLEM
Inconsistency slowed teams down and weakened the product
CarGurus had a design system, but it had outgrown itself. Their legacy system was outdated, inconsistent, and had no shared code base. Designers and developers were working from completely different references, and the gap between Figma and production kept growing. Every team solved the same problems differently and every new feature added more inconsistency.
Developers were rebuilding the same components from scratch over and over because there was no shared foundation to pull from. No shared component library. Figma and code out of sync across every team. Design debt compounding with every feature shipped. The product was growing. The system underneath it wasn't.
THE GOAL
Create a system teams can rely on, not work around
The goal wasn't just consistency, it was clarity. Chassis needed to be a shared foundation that eliminated duplicated work, aligned design and engineering around the same references, and gave teams the confidence to move faster without second-guessing every decision. One system that worked across every product, every team, and every platform, built to scale from day one.
THE GOAL
Create a system teams can rely on, not work around
The goal wasn't just consistency, it was clarity. Chassis needed to be a shared foundation that eliminated duplicated work, aligned design and engineering around the same references, and gave teams the confidence to move faster without second-guessing every decision. One system that worked across every product, every team, and every platform, built to scale from day one.
THE GOAL
Create a system teams can rely on, not work around
The goal wasn't just consistency, it was clarity. Chassis needed to be a shared foundation that eliminated duplicated work, aligned design and engineering around the same references, and gave teams the confidence to move faster without second-guessing every decision. One system that worked across every product, every team, and every platform, built to scale from day one.
CONTEXT
Evolving the system while the product was still live
When I joined, CarGurus was in the middle of a company rebrand. That meant we weren't just building a new system from scratch. We were running two tracks at the same time: maintaining and cleaning up Concrete so existing product teams could keep shipping, while building Chassis in parallel to support an entirely new visual language. There was no pause button. Every decision had to work in both worlds until the transition was complete. Chassis had to absorb the rebrand, support legacy UI without breaking live flows, and scale across every team and platform once it was ready to take over.
CONTEXT
Evolving the system while the product was still live
When I joined, CarGurus was in the middle of a company rebrand. That meant we weren't just building a new system from scratch. We were running two tracks at the same time: maintaining and cleaning up Concrete so existing product teams could keep shipping, while building Chassis in parallel to support an entirely new visual language. There was no pause button. Every decision had to work in both worlds until the transition was complete. Chassis had to absorb the rebrand, support legacy UI without breaking live flows, and scale across every team and platform once it was ready to take over.
CONTEXT
Evolving the system while the product was still live
When I joined, CarGurus was in the middle of a company rebrand. That meant we weren't just building a new system from scratch. We were running two tracks at the same time: maintaining and cleaning up Concrete so existing product teams could keep shipping, while building Chassis in parallel to support an entirely new visual language. There was no pause button. Every decision had to work in both worlds until the transition was complete. Chassis had to absorb the rebrand, support legacy UI without breaking live flows, and scale across every team and platform once it was ready to take over.
BEFORE
Legacy Design System - Concrete
Outdated patterns, no shared code base, and inconsistent UI across every surface. Teams were constantly rediscovering decisions that had already been made somewhere else in the product.
BEFORE
Legacy Design System - Concrete
Outdated patterns, no shared code base, and inconsistent UI across every surface. Teams were constantly rediscovering decisions that had already been made somewhere else in the product.
AFTER
Updated Design System Chassis
One shared system across design and code. Consistent patterns, a unified token layer, and components built once and used everywhere. Teams ship faster because the foundation is already there.
AFTER
Updated Design System Chassis
One shared system across design and code. Consistent patterns, a unified token layer, and components built once and used everywhere. Teams ship faster because the foundation is already there.
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 touching anything new. 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 this layer right meant everything built on top of it would stay consistent without extra effort.
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 handoff.
Handoff and Iterate
I stayed embedded with engineering through implementation, reviewing builds and closing the gap between what was designed and what shipped. Every change had to work alongside the legacy system the entire time.
CONTRIBUTIONS
Aligning teams through shared systems
Adoption isn't automatic. Getting Chassis used consistently across marketing, product, and engineering required more than good components. It required a shared process for how the system grew and how decisions got made. We built a contribution model with a clear path from design to code. Design contributions fed into product, which synced directly with engineering through a shared code base. Every change moved through an approval board with representatives from all three disciplines, so nothing shipped without cross-functional sign-off. No more siloed decisions. No more gap between what lived in Figma and what got built in production.
CONTRIBUTIONS
Aligning teams through shared systems
Adoption isn't automatic. Getting Chassis used consistently across marketing, product, and engineering required more than good components. It required a shared process for how the system grew and how decisions got made. We built a contribution model with a clear path from design to code. Design contributions fed into product, which synced directly with engineering through a shared code base. Every change moved through an approval board with representatives from all three disciplines, so nothing shipped without cross-functional sign-off. No more siloed decisions. No more gap between what lived in Figma and what got built in production.
CONTRIBUTIONS
Aligning teams through shared systems
Adoption isn't automatic. Getting Chassis used consistently across marketing, product, and engineering required more than good components. It required a shared process for how the system grew and how decisions got made. We built a contribution model with a clear path from design to code. Design contributions fed into product, which synced directly with engineering through a shared code base. Every change moved through an approval board with representatives from all three disciplines, so nothing shipped without cross-functional sign-off. No more siloed decisions. No more gap between what lived in Figma and what got built in production.
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 token-first foundationBuilding Chassis: A token-first foundation
Every component in Chassis is built on a semantic token layer. Instead of hardcoding color and style values directly into components, every decision references a named token tied to its function, not its appearance. Surface, fill, and action tokens define how components behave across contexts, so when the visual language updates, the token value changes and every component that references it updates automatically. This is what made the rebrand possible without rebuilding the entire system from scratch.
Building Chassis: A token-first foundationBuilding Chassis: A token-first foundation
Every component in Chassis is built on a semantic token layer. Instead of hardcoding color and style values directly into components, every decision references a named token tied to its function, not its appearance. Surface, fill, and action tokens define how components behave across contexts, so when the visual language updates, the token value changes and every component that references it updates automatically. This is what made the rebrand possible without rebuilding the entire system from scratch.
Building Chassis: A token-first foundationBuilding Chassis: A token-first foundation
Every component in Chassis is built on a semantic token layer. Instead of hardcoding color and style values directly into components, every decision references a named token tied to its function, not its appearance. Surface, fill, and action tokens define how components behave across contexts, so when the visual language updates, the token value changes and every component that references it updates automatically. This is what made the rebrand possible without rebuilding the entire system from scratch.
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.
