How to build a design system that scales — from design tokens and Figma components to Tailwind CSS with CVA and Radix UI
Design Systems Are Not Component Libraries
A component library is a collection of buttons, inputs, and cards. A design system is a shared language that governs how an entire product looks, feels, and behaves. The library is an implementation detail — the system is the thinking behind it.
At The Beyond Horizon, every client project starts with design before code. Not wireframes tossed over a wall to developers — a collaborative design process that produces a system both designers and engineers share ownership of.
Why Design Systems Matter for Startups
Startups move fast. Without a design system, every new feature is designed from scratch. Developer A builds a modal with 16px padding. Developer B builds one with 24px. Designer A uses 14px body text. Designer B uses 16px. Six months later, the product looks like it was built by six different teams — because functionally, it was.
A design system prevents this by codifying decisions:
Spacing scale: 4, 8, 12, 16, 24, 32, 48, 64px. Nothing else.
Color palette: Primary, secondary, neutral, success, warning, error — each with defined shades from 50 to 950.
Typography scale: Defined sizes from xs (12px) to 4xl (36px) with corresponding line heights.
Component patterns: How buttons, inputs, cards, modals, and navigation work — including all states (default, hover, focus, disabled, loading, error).
Our Figma-First Workflow
Step 1: Token Definition
We start by defining design tokens — the atomic values that drive every visual decision. Colors, spacing, typography, border radii, shadows, and breakpoints are documented in a Figma page called “Foundations.”
These same tokens are exported to Tailwind CSS configuration. The Figma source and the code source reference identical values. When a designer says “use space-4,” the developer knows it means 16px because their Tailwind config defines it identically.
Step 2: Component Design
Every component is designed with all its variants and states:
Button: Primary, secondary, outline, ghost, destructive. Sizes: sm, md, lg. States: default, hover, focus, active, disabled, loading.
Input: Text, email, password, search, textarea. States: default, focus, error, disabled. With and without labels, helper text, and validation messages.
Card: Default, interactive (hoverable), selected, loading skeleton.
Write on Medium
Each variant is a Figma component variant, so designers swap between them instantly. No recreating a button every time.
Step 3: Page Templates
With components built, we compose them into page-level templates. Homepage, product page, dashboard, settings — each is a Figma frame using only components from the system. This is where we catch inconsistencies before development starts.
Step 4: Developer Handoff
We use Figma Dev Mode for precise specifications. Developers see exact spacing values, color tokens, and typography — not pixel measurements from a flat mockup. Combined with our Tailwind token integration, the gap between design and implementation approaches zero.
Building Components in Code
Our code component library uses:
React + TypeScript: Type-safe props prevent incorrect usage at compile time
Tailwind CSS + CVA (Class Variance Authority): Variant management without CSS-in-JS runtime overhead
Radix UI primitives: Accessible, unstyled primitives for complex components (dropdowns, dialogs, tooltips)
Storybook: Visual documentation and testing for every component variant
CVA is particularly powerful. Define your button variants once — each combination of size, color, and state maps to specific Tailwind classes. The component accepts variant props and CVA resolves the correct classes. No conditional className logic scattered through components.
Dark Mode Is Not Optional
Users expect dark mode. Implementing it retroactively is painful — every hardcoded color must be found and replaced. Design systems handle this from day one.
Our approach uses CSS custom properties mapped to Tailwind:
Light mode: — background: 0 0% 100% (white)
Dark mode: — background: 222 47% 11% (dark navy)
Components reference semantic tokens (bg-background, text-foreground) that automatically resolve based on the active theme. Adding dark mode to a page built with the system is zero additional work.
Responsive Design Breakpoints
We design for five breakpoints:
320px: Smallest supported mobile (iPhone SE)
375px: Standard mobile
768px: Tablet
1024px: Small desktop / landscape tablet
1280px: Standard desktop
Every component and layout is tested at all five. We do not design “mobile” and “desktop” separately — we design a fluid system that adapts.
Want a design system that scales with your product? Let us build it together.