Introduction
When I first joined, our “design system” was little more than a cluttered file. Components were half-finished, styles were inconsistent, and documentation didn’t exist. Developers spent more time fixing broken elements than building new features.
I knew this wasn’t sustainable. Partnering with a dev team lead, I pitched leadership on the cost of continuing as-is and the benefits of starting fresh. With their approval, Drift was born — not just a library, but a foundation for how we design and build.
The Problem
Our old system had become a liability:
No structure — no documentation or standards.
Inconsistent usage — styles applied differently across projects.
Developer headaches — outdated components caused more issues than they solved.
Lack of scalability — tools weren’t built for modern needs.
It was clear: we couldn’t patch the old system. We had to rebuild from the ground up.
The Vision
We set out to create more than components. We wanted a shared language and foundation that unified design and development.
Mission: Build a scalable, consistent system that empowers teams.
Vision: Foster collaboration and efficiency across the company.
Guiding Principles
Innovation for the future
Consistency across all products
Seamless collaboration
Gaining Approval
The first hurdle was getting approval. A project of this scale wasn’t going to move forward without leadership on board, so I built a detailed roadmap and backed it with examples from systems like Salesforce Lightning, Shopify Polaris, and IBM Carbon. The message was clear: we were burning hours fixing problems that shouldn’t exist, and we needed a real system to scale. Once leadership saw how much efficiency we were losing, they gave us the green light.
Building the Foundation
With approval in hand, I focused on building a solid framework for the design system. Colors came first. Instead of a messy palette, I created semantic tokens like “Default,” “Hover,” and “Disabled,” so there was never a question about which color to use. Typography followed the same principle — naming conventions like “Heading,” “Subtitle,” and “Body” tied to consistent sizes, weights, and line heights. To make layouts predictable across teams, I locked in an 8px grid system and paired it with standardized spacing, radii, and shadows.
Documentation & Guidelines
For components, I knew we needed something scalable from the start. We chose Material UI as a base and applied atomic design principles, building atoms first, then molecules, and finally organisms. This method gave us a library that was modular, consistent, and ready to grow with future needs.
The Important Matters
QA Process
Of course, components are only as strong as the documentation that supports them. To make Drift approachable, I built out Storybook as our single source of truth. Every component had clear instructions, examples, and context, but I didn’t stop there. I added a dedicated section explaining why Drift existed — not just for designers and developers, but for leadership too. It was important that everyone understood the value of the system, not just how to use it.
Conclusion
Drift began as a fix for chaos and grew into the backbone of our product ecosystem. It sped up development, aligned design and engineering, and earned the trust of both teams and leadership. Today, I manage Drift as its owner — ensuring it continues to scale with our business and shape how we build the future.
