Overview
The gap between design and code — closed
Most design systems live in Figma. They document intent: what a button should look like, what spacing should be, how a modal should behave. But they exist in a parallel universe from the codebase. Engineers look at a Figma frame, approximate it in CSS, and the designer spends the next sprint in QA review cycles pointing out every pixel that's off.
I built a different kind of design system: one that lives in the code. Aspire's design system is implemented directly in Storybook using React. It's the same components engineers import into the product — not a documentation layer, not a reference, but the actual source of truth.
The Problem
Design drift and QA debt
Before the design system, every engineer had their own interpretation of a component. Button padding, border radius, color values, shadow — these varied subtly across components built by different people, creating a product that looked slightly off in ways that were hard to pinpoint but easy to feel.
- 1.Each engineer had their own interpretation: Small inconsistencies in spacing, color, and interactive states accumulated across the product. The term 'primary button' meant different things in different parts of the codebase.
- 2.Design QA was a recurring tax: Every sprint, some portion of design review time was dedicated to implementation corrections. This was time that should have been spent on new design work — and it was demoralizing for both sides.
- 3.No shared vocabulary: When a designer said 'use the primary button,' engineers had to look at the Figma file, find the closest match, and guess at the exact styles.
Architecture
Built in layers: primitives → components → themes → layouts
Layer 1: Primitives
Design tokens — color scales, typography, spacing, border radius, shadows, z-index. Every component is built exclusively from these tokens. No hardcoded values anywhere in the system.
Layer 2: Shared Components
Buttons, inputs, selects, modals, tooltips, badges, avatars, tables, and ~40 other UI components — each implemented in React with full prop documentation and interactive Storybook stories.
Layer 3: Themes
Tokens are mapped to semantic themes — light mode, dark mode (future-proofed), and brand-specific overrides. Engineers can change the entire visual language by swapping a theme, not rewriting components.
Layer 4: Layouts
Page shells, sidebar layouts, two-column layouts, modal scaffolding — shared layout components that ensure consistent page structure. New pages start from a layout, not a blank canvas.
Implementation
I built it. In code.
This is the part that makes this design system unusual: I implemented it. Not in collaboration with a frontend engineer — I wrote the React components, defined the prop interfaces, authored the Storybook stories, and wrote the documentation. My manager's assessment captures it: “pretty proficient in UI development also.”
My background building a full-stack B2B platform at Yehlo Solutions (React, Node, MongoDB) meant I could bridge the design-engineering gap from both sides. I understood the constraints engineers work with, which meant my components were designed to be actually usable — not just visually correct.
Building the design system in code rather than just Figma meant engineers didn't have to translate — they just imported. A component documented in Storybook is the same component that appears in the product. No interpretation required.
Process
Adoption: from parallel universe to single source of truth
Building the system was only half the challenge. Getting 18+ engineers to use it as their default starting point required a deliberate adoption strategy.
- ↳Seeded with the highest-frequency components first: Buttons, inputs, and form elements are used on nearly every screen. By making these the first and most polished components, engineers had an immediate reason to use the system for every new feature.
- ↳Ran bi-weekly design deep dives company-wide: I walked through the system, explained decisions, and showed how to use components correctly. These sessions built shared understanding and surfaced component gaps I hadn't anticipated.
- ↳Made it easier than doing it yourself: Each component is documented with usage guidelines, accessibility notes, and common anti-patterns. Using the system is genuinely less work than building from scratch — and that's what drives adoption.
Impact
The end of the Figma ≠ built UI cycle
The design system became the single most-referenced artifact in Aspire's engineering workflow. When a new feature is built, engineers start from the system. When a designer reviews an implementation, they're comparing against shared components they authored — not a Figma file that lives somewhere else.
Designers who can implement their own systems have a structural advantage. You design better constraints when you understand the engineering reality, and you build better systems when you've lived both sides.