Design handoff is broken. Here's what we do instead.

The classic agency workflow goes like this: a designer spends three weeks in Figma, exports a file, and hands it to a developer. The developer opens the file, notices it's missing half the states, asks ten questions the designer can't answer quickly, and starts making implementation decisions that weren't in the design. The client sees the live version and says it doesn't match what they approved.

This is not a communication failure. It's a structural one. The handoff model treats design and development as sequential activities when they're actually deeply interdependent.

What breaks at handoff

Figma is good at communicating how something looks in its ideal state. It's not good at communicating how something behaves under real conditions: loading states, error messages, empty states, text overflow, touch targets on different screen sizes, component behaviour at breakpoints the designer didn't draw.

When a developer encounters an undocumented state, they make a decision. That decision is rarely wrong, but it's also rarely what the designer imagined. Multiply that across a 30-component project and you get a product that technically implements the design but feels different from it in dozens of small ways.

The other issue: design decisions that look correct in Figma can be technically expensive or impossible. A designer who doesn't think about CSS rarely knows this until a developer raises it — usually after the design has already been approved and the client is expecting that exact result.

How we work instead

We don't have a handoff because we don't separate design from development into sequential phases.

The process looks like this: we begin with rough wireframes that both the designer and developer review together — specifically looking for implementation complexity. Any component that would require unusual CSS or JavaScript gets flagged and either simplified or explicitly scoped before the visual design begins.

Visual design happens in Figma, but in parallel with working code. As design components are finalised, they go directly into the component library. The developer isn't waiting for a complete file — they're building the system in real time as decisions are made.

This means edge cases get caught during design, not during QA. When the developer builds the dropdown and discovers the hover state doesn't account for keyboard navigation, they say so immediately — not three weeks later.

What clients experience differently

The most visible difference is what we show at checkpoints. At the end of week one, clients see working browser prototypes — not Figma screens. The prototype isn't complete, but it's real. It loads. It responds. It looks and behaves the way the finished product will.

This changes the feedback dynamic. Clients stop commenting on visual details that won't matter in production and start asking questions about behaviour. That's the feedback that actually improves a product.

The practical effect on timelines: fewer revision rounds on visual decisions that seemed correct in Figma but felt wrong in the browser. We catch those problems early, when changing them costs hours, not days.

Why this isn't standard practice

It requires the designer and developer to communicate continuously, which is easy when they're the same team and difficult when they're separate contractors or separate departments. Most agencies are structured around disciplines — design teams, development teams — because that's how specialisation scales. The handoff is a consequence of organisational structure, not a technical requirement.

For a small studio working on focused projects, the separation creates more overhead than it eliminates. We maintain the integrated model because the output is consistently better and the client conversation is simpler. One team, one accountability chain, one version of the project.

---

If you're currently working with a design agency that will hand you Figma files and a separate development team, the friction you're anticipating is real. It's worth asking whether the separation is serving the project or just the agencies' workflows.