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. 😬
Design systems are good for business. Period. Not just in a "nice to have" way, but in a fundamental, bottom-line impacting way.
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… 🏗️
60+ components. 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.
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.
Design system work became mandatory scope on any feature that touched it.
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.
Today, the Sequoia design system is deeply integrated in Driveway.com. In 2025, it was extended to accommodate internal apps as well with multi-brand support to boot!