From Figma to code: how I approach a new design handoff

A new design file is tempting. You want to open your editor and start building the hero. In my experience, the fastest Figma to code builds start with twenty minutes of reading instead.

Read the design as a system first

Before writing markup, I go through the whole file and note what repeats. Colours, type sizes, spacing values, border radius, shadows. Most designs use fewer values than they appear to, and the ones that are slightly off are usually accidents.

I turn those notes into CSS custom properties straight away:

:root {
	--color-ink: #16202e;
	--color-accent: #c41f55;
	--space-md: 1rem;
	--space-lg: 1.5rem;
	--radius-sm: 4px;
}

Once tokens exist, every component pulls from the same source, and a late change to the brand colour is one line.

Find the components, not the pages

Pages are made of a smaller set of parts: buttons, cards, section headings, list rows. I list them and build them before any page. A page then becomes an arrangement of finished pieces.

Ask about the states nobody drew

Designs usually show the happy path. Before building, I ask about:

• Hover, focus and active states for every interactive element
• What happens with a long title, or no image
• Empty states and error messages
• How the layout behaves between the mobile and desktop frames

These answers are cheap during handoff and expensive after launch.

Build mobile first, check at awkward widths

I write the smallest layout first and add min-width media queries as space allows. Then I test at widths nobody designed for, like 820px or 1100px. That is where most layout bugs hide. I cover the habits that keep this manageable in mobile-first CSS that stays maintainable.

The goal

The aim is not a pixel-perfect screenshot at one width. It is a build that keeps the design's intent at every width, and that the next developer can change without fear.