From Figma to responsive UI: a practical handoff checklist

A design file shows how a page looks at two or three fixed widths. The browser has to handle every width in between, every font size a user might pick, and every state the data can be in. Most "it doesn’t match the design" problems come from that gap, not from the pixels themselves.

This is the checklist I work through before and while building a page from Figma.

Read the whole file before writing code

Skim every frame — desktop, tablet and mobile — before touching the editor. You are looking for repetition: the same card in three places, the same button in four colours, the same spacing between every section. Each repeated thing becomes a component or a token, and spotting them early saves rewriting later.

• Which elements repeat across pages? Those are components.
• Which values repeat — colours, radii, shadows, spacing? Those are tokens.
• What changes between the mobile and desktop frames? Those are your breakpoints.

Extract design tokens first

Before building any section, copy the colours, font sizes, radii and shadows into one place. With Tailwind CSS v4 that place is an @theme block, and every value immediately becomes a utility class.

@import 'tailwindcss';

@theme {
  --color-brand: #9270ff;
  --color-surface: #313138;
  --font-display: 'Poppins', sans-serif;
  --radius-card: 20px;
}

Now components use bg-brand and rounded-card instead of hard-coded hex values, and a colour change is a one-line edit.

Use rem, not pixels, for sizes

Figma works in pixels, but users can change their browser’s default font size. Converting sizes to rem (pixel value ÷ 16) lets the whole layout scale with that preference. Keep pixels for things that should stay fixed: 1px borders, focus outlines and hairlines.

Choose breakpoints from the content

Don’t copy breakpoints from the frame widths blindly. Resize the browser slowly and add a breakpoint where the layout actually breaks — a navigation that no longer fits, a line of text that becomes too long to read. Build mobile-first, so the base styles are the simplest layout and larger screens add complexity.

Build the states the design forgot

Static mock-ups usually show the happy path. Real interfaces also need:

• Hover and focus states — and a visible focus ring for keyboard users.
• Loading states for anything that fetches data.
• Empty states for lists with nothing in them yet.
• Error states for forms and failed requests.
• Long content — a name that wraps to three lines, a title with no spaces.

If the design doesn’t cover a state, make a reasonable choice using the existing tokens and flag it to the designer, rather than leaving it unstyled.

Compare at real widths, not just the frame widths

Finally, check the build at 320px, 375px, 768px, 1024px and a wide desktop, plus a 200% browser zoom. Most layout bugs live between the frames the designer drew.

A faithful build matches the design where the design is specific, and stays consistent with it everywhere the design is silent.