From Figma to production, without the handoff gap

Most projects lose time and quality in the gap between design and code. Here's what falls into that gap, and what changes when one person owns both halves.

There's a specific place where web projects go wrong. It isn't the design, and it isn't the development. It's the seam between them.

Here's the usual shape of it. A designer produces polished mockups in Figma and hands them to a developer to build. Then the translation losses begin. Spacing drifts. A hover state nobody specified gets improvised. The design showed one screen size, so behaviour at every other size is anyone's guess. Something looks off, and now there's a round of "that's not what the design said" against "the design didn't cover this." Timelines slip in the back-and-forth. And because two people own two halves, nobody quite owns the result.

Why the gap exists

A handoff loses things because a static design file can't capture everything a live, interactive product has to do.

Mockups show a handful of fixed states. A real site has hover and focus states, loading and empty states, error messages, and edge cases where content runs longer or shorter than the example. Plus how every one of those reflows across screen sizes. Motion and transitions rarely make it into a spec at all.

All of that lives in the gap between "here's the design" and "here's the working site." Someone has to decide it. In a handoff, that someone is a developer inferring the designer's intent. And every inference is a chance for the built result to drift from what was drawn.

The alternative: decisions made once

When the same person designs and builds, that gap closes. There's no translation step, because there's nothing to translate to. The person defining how it should look is the person defining how it behaves, and those become one set of decisions made once.

Responsive behavior is handled by someone who understands why the layout is what it is. Hover states and transitions are designed and built in the same motion. Edge cases surface during the build, because the builder knows what the design was trying to do.

Nothing is lost in the handoff, because there is no handoff. What ships looks like what was drawn, not a developer's best interpretation of it.

In fairness

The handoff model exists for good reasons. On large teams and large projects, specialization is necessary. You want dedicated designers and dedicated engineers, and a well-run handoff on top of a solid design system works.

This isn't an argument that separating the two roles is always wrong. It's an argument that for a great many projects. The small-to-mid-sized ones, where a single capable person can hold the whole thing in their head. The handoff isn't a feature, It's a tax. You pay it in time and in quality, for a coordination problem you created by introducing the seam in the first place.

Feedback and testing are integral to refining a project. I gather insights from users, peers, and clients to make informed adjustments. This iterative approach ensures that the design evolves in the right direction, balancing creativity with practicality. Ultimately, the goal of exploring creative design solutions is not just to complete a project but to expand my skills, challenge assumptions, and innovate continuously. Each project I share in this blog demonstrates my commitment to thoughtful design, effective problem-solving, and delivering experiences that are visually compelling and purposeful. By documenting the process behind each design, I aim to provide insight into my approach, inspire other creatives.

The same logic, one layer out

The design-to-development seam is the one people notice. It isn't the only one.

The same gap opens between a site and the social presence running alongside it built by one team, run by another, to two different briefs. The result drifts the same way, for the same reason. Fewer people think to close that seam, which is precisely why it's worth closing.

If you're planning a project and want the design, the build, and everything running alongside it handled as one piece of work, get in touch.