From Figma to Code: Bridging the Gap

The handoff between design and development is where good intentions go to die. A designer spends weeks perfecting a layout, hands it to a developer, and gets back something that looks "close but not right." The spacing is off. The font weight is wrong. The animation feels different.

This gap isn't inevitable. Here's how I bridge it.

Inspect, Don't Assume

Before writing a single line of code, I spend time in Figma. Not just looking at the design — inspecting it. Every spacing value, every color, every font property. I'm building a mental model of the system the designer used.

Most designers work with consistent spacing scales and type hierarchies, even if they haven't formalized them. Identifying these patterns upfront means I can map them to utility classes or tokens rather than hardcoding pixel values.

The 8px Grid

Almost every well-designed interface sits on an 8px (or 4px) grid. Once you internalize this, you can eyeball spacing discrepancies instantly. If something looks off, it's usually because a value isn't snapping to the grid.

Tailwind CSS maps beautifully to this: p-2 is 8px, p-4 is 16px, p-6 is 24px. The translation becomes mechanical.

Typography Hierarchy

Type is where most implementations diverge from the design. The fix is simple: extract the complete type scale from Figma before you start.

I create a typography config that maps exactly to the design:

Display:   48px / 1.1  / -0.02em / Bold
Heading 1: 36px / 1.15 / -0.015em / Semibold
Heading 2: 28px / 1.2  / -0.01em / Semibold
Body:      16px / 1.6  / 0       / Regular
Caption:   13px / 1.4  / 0.01em  / Medium

This takes 10 minutes and saves hours of back-and-forth.

Animation Specification

Designers often describe animations verbally: "it should feel snappy" or "a smooth slide-in." I've learned to ask for specifics: duration, easing curve, delay, and trigger. If they're not sure, I prototype options and let them choose.

Most UI animations fall into a few categories: - Entrances: 300-500ms, ease-out - Exits: 200-300ms, ease-in - State changes: 150-200ms, ease-in-out - Hover feedback: 100-150ms, ease-out

Having these defaults means I can implement confidently and only adjust when the designer flags something.

The Review Loop

I never consider a page "done" until the designer has reviewed it in the browser — not a screenshot, the actual running page. Screens lie. Browsers tell the truth.

This review catches the things that are invisible in static mockups: how the layout responds between breakpoints, how hover states feel, how scroll-driven animations pace themselves.

The goal isn't pixel perfection for its own sake. It's respect — for the designer's craft, for the user's experience, and for the product's identity.