Design handoff
March 31, 2026

What designers can do when implementations don't match

Specific feedback resolves faster than feedback that describes impressions.

A tool adjusts a slightly misaligned object, correcting it to match the intended structure.

What designers can do when implementations don't match

When a developer's implementation does not reflect the design, the designer is typically the one who notices first. What they do next determines whether the issue gets fixed efficiently or becomes a prolonged back-and-forth. Most of the friction in this situation comes not from the implementation being wrong but from how the gap is surfaced and communicated.

The problem with subjective feedback

The most common form of design feedback is also the least efficient: "this spacing feels off", "the text looks a bit light", "something about this doesn't match the design." These descriptions require the developer to interpret what is meant, decide what to change, implement a fix, and return to the designer for confirmation. If the fix is close but not exact, the loop runs again.

When reviewing by eye, a designer is often working from intuition rather than measured values. They can see that something is wrong before they can articulate what or by how much.

Making feedback specific and measurable

Feedback that references specific values resolves faster than feedback that describes impressions. "The heading font weight is 400, the design specifies 500" gives the developer exactly what to change. "The gap between the card and the label is 12px, the design specifies 16px" does the same.

Getting to that level of specificity requires comparing the rendered implementation against the design with enough precision to identify the actual values involved. This can be done by inspecting the rendered element in browser developer tools and comparing the values against what the Figma file specifies, though that process is time-consuming on any page with many components.

When the gap is described in measurable terms from the start, the developer knows exactly what to fix and the designer can verify it quickly.

Choosing what to raise and what to accept

Not every deviation from the design is worth raising. A 2px spacing difference on a responsive layout may be a browser rounding artefact that is not worth the engineering time to address. A heading that is a full weight lighter than designed across every page in the product is worth raising because it affects the visual hierarchy throughout.

The distinction is between deviations that affect design intent and deviations that are within the natural tolerance of the medium. Pixel-perfect matching is not achievable in responsive environments, and pursuing it creates friction without improving the user experience. What is worth pursuing is the set of differences that change how the design reads: hierarchy, rhythm, proportion, and the visual relationships that the designer was trying to achieve.

Keeping a record

When visual differences are found across an implementation, keeping a record of what was flagged, what was fixed, and what was accepted makes the process more consistent over time. It also creates a shared reference for the designer and developer that replaces subjective memory with a documented history.

The value is not the record itself but the discipline of translating visual impressions into specific observations before raising them.

Ready to get started?
Sign in with your Figma account today!

Image CTA Ready To Get Started? Create An Account Today New Clients - Techstar XWebflow TemplateRecent Invoices - Techstar Webflow Template