Context & Scope
As the senior UX designer responsible for Drift, I owned the evolution of our design system as it grew from a single internal tool into a shared foundation across multiple products. When I stepped into the project, Drift existed largely as an overextended Figma file. Components had been added quickly to support immediate needs, but documentation was limited, standards were loosely defined, and alignment with engineering was inconsistent.
My role was to turn Drift into something teams could rely on. I set out to establish clear patterns, documentation, and a design-side practice for critique and iteration, while working closely with engineering to ensure the system translated cleanly into production. Drift continues to evolve today as a shared system that helps design and engineering move faster together.
Drift’s original system had become a liability rather than an accelerator.
No shared standards or documentation
Inconsistent usage across products
Components that slowed development instead of supporting it
Incremental fixes weren’t enough. The system needed to be rebuilt with scale in mind.
Design System Priorities
Rather than designing for flexibility at all costs, we optimized Drift around a small set of non-negotiables.
◇ Consistency
Shared patterns across products to reduce cognitive load, eliminate rework, and create a more predictable experience for both users and teams.
◇ Velocity
Clear standards and reusable components that allow design and engineering to move faster without sacrificing quality or alignment.
◇ Scalability
A system designed to support multiple products, teams, and platforms as the organization and its surface area continue to grow.
These priorities shaped every decision in Drift’s evolution, and their impact was felt quickly across teams.
As Drift expanded across the organization, these outcomes reflect improvements in speed, consistency, and collaboration.
Framing the system work in terms of speed, consistency, and long-term cost.
Guidelines focused on intent and usage, not just listing what exists.
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. Everyone needed to understand 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. My goal is to ensure it continues to scale with our business and shape how we build the future.
The Important Matters
A type system designed for clarity and reuse across multiple products.
A simple articulation of what Drift needed to support as it scaled.
A color foundation built for consistency, accessibility, and growth.
A standardized hierarchy to remove ambiguity and enforce consistency.