A component library isn't a design system.
How we took a fragmented component library to a fully documented, adopted design system in four months.
My role
Contributions: Component audit and rebuild, documentation site, design spec standardization, engineering relationship building, director-level mandate for design system scope
The starting point
The component library existed. That was about it. Figma components that may or may not have matched what was in Storybook. No usage documentation. No governance. No dedicated engineering resources. No product support. And 30 designers across five journey teams who were largely unaware the system existed. 😬
The hardest part wasn't building it. It was making it everyone's problem.
First we needed to know what we had
Before we could build anything new, we needed to know what we had. I created a backlog for every existing component with user stories covering three things:
whether the Figma component was functioning correctly and built to current best practices,
whether it was in sync with the Storybook component
whether usage guidelines existed anywhere.
Then we got to work… 🏗️
70+ components across 5 distinct product journeys and 6 engineering pods. Many needed to be rebuilt entirely. We worked through them systematically: Figma first, then documented the delta with engineering so dev parity stories could be added to the backlog. In parallel we stood up a full documentation site covering foundations, components, and voice and tone guidelines. Four months from audit to launched, six weeks ahead of schedule. The documentation site is live at design.driveway.com.
Fully rebuilt Figma design system including type styles, color variables, and components.
Brand spankin’ new design system documentation site.
Getting into the room with engineering
With no dedicated design system engineers, adoption wasn't going to happen through documentation alone. I reached out to the engineers who had stood up the Storybook instance and asked them to add our design system debt stories to the Engineering Driven Initiatives backlog. Then I got our team invited to the twice-weekly Frontend League ceremony - a standing meeting across all engineering journey teams - where we were given the first few minutes of every session to cover design system updates and answer questions. That ceremony became our most effective adoption tool.
Our component naming scheme made it easy to spot design system components and see whether they had parity with their coded counterpart.
Added a card to the design spec for easy access to developer resources.
The spec and the review gate
Awareness wasn't enough. I needed to know the design system was actually being used in production. I interviewed one frontend engineer from each journey team to understand what they needed in a design spec to build confidently. I synthesized the findings and developed a standardized spec with a review gate - no handoff without DS team sign-off. Every Sequoia component was clearly labeled so engineers could identify them at a glance. I also built a video tutorial walking engineers through DevMode and how to recognize design system elements in a spec.
Within weeks, 30 designers and 60+ engineers were building with Sequoia.
The biggest win
The hardest problem was sustainability. With no dedicated engineering resources, design system work kept getting descoped when projects got tight. I spent a couple of months in conversations with product managers making the case. Finally, the right moment arrived: two projects in sequence where one was creating debt the other would immediately inherit. I took it to the director. Design system work became mandatory scope on any feature that touched it.
That changed everything.
Within weeks of launching, 30 designers and 60+ engineers were building with Sequoia. The design spec standard made it inevitable: no new work shipped without it. The system stopped being something we were pushing and became something everyone just used.
Today, the Sequoia design system is deeply integrated in Driveway.com. In 2025, it was extended to the internal apps team with multi-brand support, and that team shipped 4 net new applications in 2025, more than any prior year. The system wasn't just adopted. It became the foundation that made shipping at that pace possible company wide.