Design to code: reading a design file

A design tool connection lets Claude read a selected frame: its hierarchy, spacing, typography and component names. That's a genuinely hard thing to describe in words and an easy thing to read from the source, which is what makes the connection worth having.

Start with description, not implementation. Ask what's in the selected frame and check it against what you can see. This is a fast, honest calibration: if the description gets the nesting or the component names wrong, you've learned that before it's expressed as code.

Extracting tokens is where judgement enters. A frame contains colours, type styles, spacing and radii — but a value appearing once is not a design token, it's a value. The one-off 13px gap that exists because someone nudged a box is not --spacing-13. Ask for the values with their source locations and an uncertainty flag, then decide yourself which are systematic. The alternative is codifying an accident into your stylesheet, where it becomes permanent.

Before implementing anything, map the design's components onto components you already have. Three candidates, three decisions: reuse, adapt, or create. This is the step that stops an AI-assisted design handoff from quietly producing a second button component, then a third — the most common way these workflows make a codebase worse rather than better.

When you do implement one, check it two ways: read the diff, and look at it beside the design. And ask for observable mismatches rather than a fidelity claim — "the heading is 2px smaller and the card shadow is missing" is a list you can work through, while "pixel-perfect" is a claim no one has checked.

Loading your workspace…