Every product team with separate design and engineering functions has a version of the same recurring problem. The designer finishes a screen, shares the Figma file, and considers the handoff complete. The engineer opens the file, implements what they see, and delivers something that is technically accurate and visually wrong. The designer reviews it, flags the discrepancies, and the engineer has to go back. The sprint absorbs the rework. Nobody is sure whose fault it was. And the same thing happens next sprint.
This cycle is so common that most teams have stopped questioning it. It is treated as the natural friction between two disciplines that think differently, speak differently, and measure success differently. The assumption is that some amount of rework is inevitable when design and engineering are separate functions, and that the best you can do is minimise it.
That assumption is wrong. The rework is not inevitable. It is a symptom of a specific failure in how the handoff is structured, and it is addressable with specific changes to how design and engineering collaborate within a sprint. This post is about where the handoff breaks, why it keeps breaking in the same places, and what actually fixes it rather than just managing the damage.
A Figma file is not a handoff. It is a starting point for a conversation that most teams never have because the process assumes the file is self-explanatory. It is not.
WHY THE HANDOFF KEEPS FAILING
It is treated as a moment rather than a process
The most fundamental failure is structural. Most teams treat the handoff as a single event: the designer shares the file, the engineer receives it, and implementation begins. This model assumes that everything the engineer needs to implement the design correctly is contained in the file, and that the file is unambiguous enough to produce a consistent interpretation across different engineers with different assumptions.
Neither assumption is true. A Figma file shows what something looks like in its ideal state. It does not show what it looks like when the API is slow, when the content is longer than expected, when the user is on a small screen, when the form validation fails, or when there is no data to display. All of those states require decisions. In the handoff-as-moment model, those decisions are made by the engineer, alone, under the pressure of a sprint deadline, without the context the designer has.
The result is an implementation that handles the ideal state correctly and handles every other state inconsistently, because each engineer who touches the feature makes different decisions about the states the design did not explicitly address. Over multiple features and multiple sprints, those inconsistent decisions accumulate into an interface that feels incoherent even when every individual feature was implemented correctly.
The file is the deliverable, not the understanding
When the Figma file is treated as the handoff deliverable, the measure of a successful handoff is whether the file was shared. Whether the engineer understood the intent behind the design, the interaction principles it reflects, the edge cases it accounts for, is not measured and therefore not ensured.
Designers and engineers have fundamentally different mental models for the same screen. A designer looks at a component and sees a set of visual decisions: hierarchy, spacing, colour, motion. An engineer looks at the same component and sees a set of implementation decisions: state management, data requirements, component boundaries, performance implications. Both are looking at the same file and seeing different things, and the gap between those two views is where the implementation diverges from the intent.
A handoff that bridges this gap requires both views to be made explicit before implementation begins. Not because the engineer needs to understand every design decision, but because the designer needs to understand which implementation decisions are left unspecified by the file, and address them before the engineer has to invent answers under pressure.
Engineers are brought in too late
In most team workflows, engineering involvement begins after the design is complete. The designer works through the feature, resolves the visual and interaction questions, produces a finished file, and then hands it to engineering. By this point, the design has been made without the input of the people who will implement it, which means it may include interactions that are technically expensive, layouts that do not account for real content variability, or states that are visually designed but technically undefined.
The engineer who discovers these problems during implementation has three options: implement it as designed and accept the technical cost, implement a simpler version and accept the visual deviation, or go back to the designer and accept the timeline delay. All three are worse than the alternative, which is catching the problem during design rather than during implementation.
Early engineering involvement does not mean engineers design the product. It means engineers are present during design to flag implementation concerns before they become implementation problems. The cost of that conversation during design is thirty minutes. The cost of discovering the same issue during implementation is a sprint.
The cost of an engineering concern raised during design is thirty minutes. The cost of discovering the same issue during implementation is a sprint. The handoff is where that difference is paid.
WHAT ACTUALLY FIXES IT
Design reviews with engineering before implementation begins
The single highest-return change a team can make to the handoff process is to hold a design review session with the engineering team before any implementation begins. Not after the file is shared. Before the ticket enters development.
This session has a specific agenda: the designer walks the engineer through the design, the engineer asks every question they would otherwise answer alone during implementation, and the designer either answers them or goes back and addresses the gaps. The session typically takes thirty to sixty minutes for a feature of moderate complexity. The implementation that follows is faster, more accurate, and requires less rework because the ambiguities were resolved before they became decisions made under pressure.
The sessions also produce a secondary benefit: they make the designer aware of the implementation implications of their decisions in real time, which improves the quality of subsequent designs without requiring any additional process.
Annotating the file for states, not just screens
A Figma file that shows only the ideal state of a design is an incomplete specification. A file that explicitly addresses the loading state, the empty state, the error state, the truncated content state, and the mobile layout is a file that leaves fewer decisions to the engineer.
Annotations in Figma serve this purpose. A note on a button that says "disabled during API call, re-enabled on response" removes a decision from the engineer. A note on a list component that says "maximum three items visible, expandable to full list on tap" removes another. These annotations do not need to be exhaustive. They need to cover the states that would otherwise produce inconsistent decisions across the team.
The discipline of annotating forces the designer to think through the states they have not explicitly designed, which is itself a quality check. A designer who cannot annotate the loading state for a component has not finished designing that component.
A shared component vocabulary
One of the most common sources of handoff friction is terminology. The designer calls something a "card." The engineer calls the same thing a "tile" because that is what it was called in the previous project. The design system uses a third name. When the same component has three names across three contexts, every conversation about it requires disambiguation that should not be necessary.
A shared vocabulary, maintained in the design system and referenced consistently in both Figma files and code, eliminates this friction. When the designer annotates a "card" and the engineer sees "card" in the component library, the mapping is immediate. When the names differ, the mapping requires a conversation that both parties have to remember to have.
Establishing this vocabulary is a one-time investment that pays back across every feature that follows. It is most effective when done before the first handoff rather than after terminology drift has already accumulated.
Asynchronous feedback loops before synchronous review
The traditional handoff model puts all the feedback in a single synchronous review after implementation is complete. This is the most expensive moment to find problems because changing something after implementation requires undoing work rather than redirecting it.
A more effective model inserts asynchronous feedback loops before the synchronous review. When the engineer has a question during implementation, they leave a comment in the Figma file rather than making a unilateral decision. When the designer sees the comment, they respond with the answer or update the design. This loop happens in writing, asynchronously, at the moment the question arises rather than at the end of the implementation.
The synchronous review at the end of implementation then becomes a confirmation rather than a discovery session. Most of the questions have already been answered. The remaining gaps are small enough to address in the review without affecting the sprint timeline.
Involving design in QA
Design involvement typically ends at the handoff. Engineering takes over, implements, and QA reviews for functionality. Visual and interaction quality are reviewed informally if at all, because QA is not typically staffed with people who know the design intent in sufficient detail to evaluate it.
A simple practice that closes this gap: the designer reviews the implementation against the design before the sprint review, not during it. Not as a blocker, but as a quality check that produces a short list of deviations for the engineer to address. This review takes fifteen to thirty minutes for a typical feature and catches the visual and interaction gaps that functional QA misses.
The timing matters. A deviation caught before the sprint review can be addressed before the feature is considered done. A deviation caught during the sprint review reopens a ticket that was already closed, which creates friction and erodes confidence in the sprint process.
WHAT GOOD COLLABORATION ACTUALLY LOOKS LIKE
A handoff process that works does not feel like a handoff at all. It feels like a continuous conversation between design and engineering that happens at the right moments and in the right formats.
The designer shares an early version of the design with engineering before it is finished, not to get approval, but to surface implementation concerns before the design is locked. The engineer raises a concern. The designer adjusts. The conversation happens in a day rather than a sprint.
The design review before implementation is a conversation, not a presentation. The engineer comes with questions. The designer comes with answers to the questions they anticipated. The gaps are resolved in the room.
Implementation happens against an annotated file that addresses the states the engineer would otherwise have to invent. Questions that arise during implementation go into the Figma file as comments and get answered the same day.
The designer reviews the implementation before the sprint review and produces a short list of deviations. The engineer addresses them. The feature ships in a state that matches the design intent rather than the design file.
None of this requires new tools. It requires a shared understanding between design and engineering of what the handoff actually is: not a file transfer, but a process of shared understanding that starts before the design is finished and ends after the implementation is reviewed.
CLOSING THOUGHT
The handoff between design and engineering does not break because the people involved are bad at their jobs. It breaks because the process treats a complex communication problem as a file transfer problem. The fix is not a better tool or a more detailed file. It is a different understanding of what the handoff is supposed to accomplish and where in the process that accomplishment needs to happen. Teams that make this shift stop spending sprint capacity on rework and start spending it on building.
If your team is losing sprint capacity to design and engineering friction and you are not sure where to start, that is a conversation worth having. Tell me about how your team currently works and what the friction looks like.