Most teams have a design system. Most of those design systems are failing their developers.
Not because the designs are bad. Because the system was built for designers, not for the people who have to implement it.
A design system that lives only in Figma is not a design system. It is a reference document with a fancy name.
The Signs Your Design System Is Broken
You know your design system is failing when developers are:
- Hardcoding hex values instead of using tokens
- Creating one-off components instead of extending existing ones
- Spending more time interpreting designs than building
- Asking designers for clarification on the same things repeatedly
- Maintaining two sources of truth - the Figma file and the codebase
If any of these sound familiar, the problem is almost certainly in how the system was built, not how it is being used.
The Root Cause
Most design systems fail for one of three reasons:
1. Tokens exist in Figma but not in code
If your spacing, colour, and typography tokens are defined in Figma variables but not exported to a format developers can use, every developer has to manually translate design decisions into code. This creates drift - the codebase gradually diverges from the design.
2. Components are documented, not shipped
A Figma component with a usage note is not the same as a React component developers can import. Documentation describes. Code delivers.
3. The system was built once and never maintained
Design systems are living products, not one-time deliverables. A system that is not actively maintained becomes a liability - developers stop trusting it and build around it instead.
What a Working Design System Looks Like
A design system that actually works for developers has three layers:
Layer 1 - Design Tokens in Code
Every design decision that can be abstracted - colour, spacing, typography, shadows, border radius - lives as a token in a format the codebase can consume:
// tokens/colors.js
export const colors = {
primary: '#6C63FF',
background: '#0A0A1A',
surface: '#12122A',
accent: '#00D4FF',
text: {
primary: '#F0F0FF',
secondary: 'rgba(240, 240, 255, 0.6)',
}
};
// tokens/spacing.js
export const spacing = {
xs: '4px',
sm: '8px',
md: '16px',
lg: '24px',
xl: '32px',
xxl: '48px',
};When a designer updates a colour, there is a single place to update it in code. Nothing else breaks.
Layer 2 - A Component Library Developers Can Actually Use
Components should be importable, composable, and documented with real usage examples:
// components/Button/Button.tsx
interface ButtonProps {
variant: 'primary' | 'secondary' | 'ghost';
size: 'sm' | 'md' | 'lg';
children: React.ReactNode;
disabled?: boolean;
onClick?: () => void;
}
export const Button = ({
variant = 'primary',
size = 'md',
children,
disabled = false,
onClick
}: ButtonProps) => {
return (
<button
className={`btn btn-${variant} btn-${size}`}
disabled={disabled}
onClick={onClick}
>
{children}
</button>
);
};Every component handles its own states - hover, focus, disabled, loading. Developers do not have to figure these out from a Figma file.
Layer 3 - A Handoff Process That Actually Works
The gap between Figma and code is where most design systems fall apart. A good handoff process closes that gap:
- Annotate interactions, not just layouts - What happens on hover? What is the error state? What does the empty state look like?
- Export assets in the right format - SVGs for icons, not PNGs. Design tokens as JSON if the tooling supports it.
- Flag deviations from the system - If a screen introduces a new pattern, flag it before development starts.
- Review the implementation - A developer builds it. A designer reviews it. Not just against the Figma frame - against the intent.
The Figma to Code Gap
Even with a good design system, Figma and code speak different languages. Figma uses absolute positioning. CSS uses the box model. A component that looks pixel-perfect in Figma can behave unexpectedly in a browser, especially across different screen sizes.
The translation layer matters. A developer who understands design intent - not just pixel values - will build something that holds up across contexts. A developer who is copying measurements from Figma will produce something fragile.
This is why Figma-to-code is a skill, not just a task.
How We Approach Design Systems at Velox Studio
Every project we take on starts with an audit of what exists. If there is no design system, we build one before writing a line of feature code. If there is one, we evaluate whether it is actually usable in code or just in Figma.
The output is always the same - a component library the development team can import, extend, and trust. Tokens in code that match tokens in design. A handoff process that closes the interpretation gap.
Because a design system that developers do not use is not a system. It is overhead.
Does your design system live in Figma or in your codebase? The answer tells you a lot about how fast your team is actually moving.