Design to Code

A design file shows one or a few states at one or a few widths. Production UI needs all of them, built from the components and tokens the project already has. This skill turns a design into code that matches it where the design is specific, follows the design system where it is not, and says plainly what could not be verified.

When to Use

• You have a Figma URL or frame, a screenshot, or a written handoff for a component or page
• The UI must ship in an existing app with its own design tokens and component library
• A reviewer will compare the result against the design

When NOT to Use

Prerequisites

• Read access to the design: a Figma MCP server or export, or image files of every frame
• The project's design tokens (colors, spacing, type, radius) and component library location
• A way to run the app or a component preview (Storybook, a dev route) and take screenshots

Workflow

1. Inventory the Design

List every frame you received and what it represents. For each, note:

• Breakpoints shown (for example 375, 768, 1280 px)
• States shown: default, hover, focus, disabled, loading, empty, error, long content
• Interactions the design implies but does not draw (menus opening, validation messages)

Write down the states and widths the design does not show. Those are decisions to make with the design system's conventions or to ask about — not to invent silently.

2. Map to Tokens and Components

Before writing markup, map each visual value to what the codebase already has:

Do not hardcode raw hex values or pixel sizes when a token exists. When a design value has no token, list it for the reviewer instead of adding a one-off value.

3. Implement Only the Scope

Build the component or page with the mapped pieces. Keep to the frames you received:

• Leave data fetching and backend wiring as clearly marked stubs if they are out of scope
• Do not restyle neighbouring components to make the new one fit
• Implement the required missing states from step 1 with established component behavior; ask, or mark the work blocked, when no safe convention exists

4. Compare at Every Width

Run the app or preview and capture a screenshot at each breakpoint from step 1. Compare each one to its frame and record differences item by item (spacing, alignment, type, color, truncation). Fix differences that come from the implementation; list differences that come from a token or component the design deviates from.

If you cannot run the UI or take screenshots in this environment, say so and mark visual fidelity as unverified rather than claiming a match.

Common Rationalizations

Red Flags

• New colors, font sizes, or spacing values appear in the diff that are not tokens
• A component from the library is copied and modified instead of used with props
• The change touches files unrelated to the designed component
• The pull request claims a visual match with no screenshots

Verification

• A screenshot at every breakpoint in the inventory, next to its design frame
• Every required state is implemented, or the requester explicitly agreed it is out of scope
• The project's build, lint, type check, and component tests pass
• Keyboard focus order and visible focus work; text contrast meets the project's standard (check with ux-audit if unsure)
• Design values with no matching token are listed for the reviewer

If verification shows the change broke another component, revert the unrelated part and keep the diff to the designed scope.

Tips

• With a Figma MCP server connected, read component names and token references from the frame instead of eyeballing pixel values
• Ask for the missing states before building them when a designer is available — a one-line question is cheaper than a second review round