"Pixel-perfect" is in our name, so we care a lot about what happens between the final Figma file and the live product. In our experience, most visual bugs are not developer mistakes. They come from a design system that was never built to be implemented.
Why design systems break
The symptoms are familiar: five slightly different greys, buttons that change height between screens and spacing that "looks about right". The causes are usually the same three things:
- Values are picked by eye in Figma instead of from a fixed set.
- Only the happy path is designed, so developers invent empty, loading and error states on the fly.
- Designers and developers use different names for the same thing.
Start with tokens, not components
Design tokens are the named values everything else is built from: colours, type sizes, spacing, radii, shadows and motion. Define them first, as Figma variables, and export the same names to code as CSS custom properties or a theme file.
Keep the scales small. Eight spacing steps and six type sizes are plenty for most products. When a designer reaches for a value that isn't in the scale, that is a conversation, not a quick fix.
If a value doesn't have a name, it will have ten slightly different versions by launch.
Design every state
Every component needs more than its default look. For each one we document:
- Interaction states: default, hover, pressed, focused and disabled.
- Content states: empty, loading, error, very long text and missing images.
- Responsive behaviour: what wraps, what stacks and what hides on small screens.
- Accessibility: contrast, focus order and touch target sizes of at least 44px.
This feels slow at first. It is far faster than discovering these states in QA, or worse, after launch.
Share one vocabulary
A component called "Card / Large / Hover" in Figma should be <Card size="large"> in code, with the same variants and the same props. We keep a short living document that maps every Figma component to its code component, and we review new components together, designer and developer at the same table.
Finally, budget time for the system itself. A design system is a product with users (your team), and it needs an owner and a little care every sprint. Treated that way, it pays for itself on every new screen you build.
Design systems are part of every UI/UX design project we run, from the first tokens to developer handoff.
