05 · Figma and screenshots to code

At a glance

Output	Shippable front-end code
Time	30 minutes to several hours
Input	A Figma export, a screenshot, or a web page
The hard part	Saying which layer you want — pixels or structure

Decide what you're asking for

"Turn this design into code" means three completely different things:

What you want	How to say it	What you get
A visual reproduction	"Reproduce this image as closely as possible"	Static HTML for checking the visuals
A base to build on	"Generate components on this structure using our tokens"	Component code you can wire in
A working prototype	"Make it clickable, with all states"	An interactive prototype

Unstated, you'll almost certainly get the first and then find you can't use it.

The prompts

Pixel reproduction

This is an interface screenshot. Produce the closest HTML reproduction
you can.

Requirements:
1. Match layout, spacing, and type sizes to the original.
2. Use actual sampled colour values.
3. Use placeholder blocks for images, labelled with what was there.
4. Single file, no framework.

Mark anything you're unsure of rather than filling it in by feel.

Components you can build on

This is our Figma export / interface screenshot.

Generate component code that fits our existing project.

Stack: [React / Vue / vanilla — be specific]
Styling: [Tailwind / CSS Modules / styled-components]
Design tokens: [paste them, or point at design-systems/your-brand/DESIGN.md]

Requirements:
1. Use tokens. No hardcoded colour or spacing literals.
2. Split into sensible components, each with one responsibility.
3. Prop naming follows our conventions: [give two real examples]
4. Cover all states: empty, loading, error, disabled.
5. Accessibility: semantic elements, keyboard reachable, necessary ARIA.
6. Don't add dependencies. If you think one is needed, ask first.

Build the component structure and one complete component first. I'll
confirm before you do the rest.

That last line matters. Ten components generated at once means reading ten before you discover the conventions are wrong. One is far cheaper.

From a live page

Extract the structure and visuals of [URL] and rebuild them in
[your stack].

Structure and visuals only — don't copy their copy. Use placeholders
where text goes, labelled with what kind of content belongs there.

Why they're written this way

"Use tokens, not literals" is the line between usable and disposable. Code full of #3B82F6 and padding: 14px is a one-off; changing the theme means starting over.

"Prop naming follows our conventions — here are two examples" beats "follow our code standards" by a mile. Given two real cases it infers the pattern.

"Don't add dependencies without asking" stops it quietly installing a date library, an icon set, and an animation library.

Acceptance

• [ ] No hardcoded colour or spacing literals
• [ ] Sensible component split, not one giant component
• [ ] Prop naming matches existing conventions
• [ ] States covered
• [ ] Semantic elements, not a pile of divs
• [ ] Keyboard operable
• [ ] No dependencies snuck in
• [ ] It actually runs in the project

Test the last one for real. Don't just read the code.

Variants

Specification instead of code

Don't generate code. Extract an implementation spec from this image:
- Size, spacing, colour, and type for each element
- The hierarchy
- How it should behave at each responsive breakpoint

Output a document engineering can build from directly.

Some front-end teams would rather write it themselves. A spec is more welcome than code.

A set of pages at once

These are 5 screenshots of the same product.

Step one: identify the components that recur across them and list each
component with its variants. Don't write code yet.

Step two (after I confirm the list): implement the base components.

Step three: assemble the 5 pages from those components.

Three steps yields a component set rather than five unrelated files.

Questions that come up

The fidelity isn't good enough.

First decide which layer you wanted. If it really is pixel fidelity, put the original beside the result and name specifics ("card gap should be 24, not 16"). That beats "closer, please".

The code style doesn't match the project.

Show it an existing file: "write in this file's style, including naming, comment density, and export pattern."

The Figma export has too much in it.

Say which layer: "look only at frame hierarchy and Auto Layout structure; ignore individual layer names."

It runs, but it's slow.

Generated code doesn't consider performance by default. Ask: "virtualise the list, lazy-load images, avoid unnecessary re-renders."

Related

• Playbook 04 · Extract a brand — tokens before code
• Go deeper / Export — handing off to engineering