Overview
The problem
Design and engineering were working in parallel but not in sync. Designers were solving the same UI problems from scratch on every feature. Engineers were implementing components without a canonical reference which meant what shipped rarely matched what was designed, and edge cases were handled differently across the product.
The result was visible: design inconsistencies across screens, slow design-to-development handoff, and a product that didn't feel like one coherent experience. Every sprint carried debt from the one before it.
My role
I owned the design system end to end strategy, architecture, execution, and adoption. That meant defining the foundation layer, building the Figma component library, establishing the Storybook component catalogue, and structuring the Confluence documentation space.
I worked closely with engineers throughout, but the design system direction, structure, and quality bar were mine to set and maintain.
The foundation layer
Every design decision starts with a token. I built the full foundation layer before any components existed: color, typography, spacing, and grid, all defined as variables so a single update propagates across Figma and code simultaneously.
The color system covers a full palette: Pink, Blue, Neutral, each running from 50 to 900, plus decorative colors, semantic status colors, and a brand gradient. Typography runs from Display 1 through Caption, built on a 4px grid system with defined sizes, line heights, and weights for every level of the hierarchy. Spacing and radius follow the same token logic no hardcoded values anywhere in the library, which means a rebrand or visual refresh becomes a token update, not a rebuild.
Components built for coverage, not decoration
Components are assembled from the foundation layer, never from raw values. Buttons alone cover five sizes from extra small (24px) to extra large (56px), four visual styles, and every interactive state: default, hover, disabled in both light and dark mode. Every component was built with auto layout throughout, a breakpoint switcher for responsive preview, variants and properties for every state, and full dark and light mode support from day one. Inputs span standard fields, text areas, and verification inputs with complete error-state handling.
Patterns bring components together into reusable surface-level solutions: headers, navigation for both desktop and mobile, and footers each serving creator and studio roles without requiring separate implementations.
Storybook as the engineering bridge
Every component designed in Figma had a corresponding story in Storybook. Story-driven development meant engineers could see every state, test every variant, and implement components without needing to chase the designer for clarification. Token system integration ensured that CSS variables pulled directly from the same source as Figma no translation layer, no drift.
Documentation as a product
The Confluence space was structured from the start like a product a team would actually use. Every component page covers anatomy with labeled diagrams, usage guidelines with do's and don'ts, accessibility considerations, and responsiveness notes. New engineers and designers joining the team could get oriented and contributing without needing to ask anyone.
Key decisions
The system's durability came from a handful of early calls, choices about architecture and working practice that were harder to make than any single component, and that determined how the system would hold up as the product grew.
Tokens over hardcoded values
Hardcoding values is faster on day one and costs you every day after. Building everything on tokens made the system theme-able and resilient to change a rebrand, a new product surface, or a visual refresh becomes a token update, not a rebuild.
Dark and light mode from day one
Rather than retrofitting a dark theme after the fact, I built both modes into the component architecture from the beginning. Every component in the library works in both contexts without modification.
One unified library
I kept the Figma library consolidated rather than splitting it by product area. The short-term complexity of maintaining one larger library is worth the long-term coherence of one library every designer
works from.
Full state coverage at handoff
No component left Figma without every interactive state defined. Default, hover, focused, disabled, error, loading engineers should never need to invent a state that wasn't designed.
Outcome
The design system became what I set out to build: a single source of truth the whole team could build from. Designers stopped reinventing the wheel on every feature. Engineers had a reliable component reference they could trust. Handoff friction dropped significantly. Onboarding new team members became a structured process rather than an oral tradition.
The feedback from both designers and developers was overwhelmingly positive the team described the system as immediately valuable, and adoption continued to grow after launch.
50%
Faster work process across
design and development
90%
Reduction in design inconsistencies
across the product
100%
Improved team
collaboration
METRIC 1
50% faster work process
Measured through an internal survey of designers and engineers after the system launched. Teams reported that shared tokens and reusable components cut feature design and build time roughly in half, work that previously started from a blank canvas now starts from the library.
METRIC 2
90% reduction in design inconsistencies
From the same post-launch survey: the team assessed consistency across the product before and after adoption. With every screen assembled from one component set and every value pulled from tokens, the spacing, color, and behavior drift that defined the old product was nearly eliminated.
METRIC 3
100% of the team reported improved collaboration
Every designer and engineer surveyed reported improved collaboration between the two disciplines. Figma, Storybook, and Confluence gave both sides a shared vocabulary the same component names, the same states, the same reference, replacing interpretation with alignment.