Handoff breaks in patterns. After years of working across product teams, the failures look different on the surface but trace back to a small set of structural problems. This is not an argument that designers or engineers do bad work. Both sides usually work hard. The problem is that the current set of tools creates gaps that no individual can close through effort alone.
Here are the five patterns we see most often, what each looks like from the inside, and what teams have found that actually helps.
Pattern 1: The spec is the file, not the intent
A Figma file tells you what a component looks like in one state at one viewport. It does not tell you what the component should do when the text is twice as long, when the user's browser has a non-default font size, or when the component appears inside a container with a different background.
Engineers handle these edge cases by guessing. Sometimes the guess is right. More often, it produces a component that mostly matches the design but fails in a specific context the designer never drew because they did not think of it as a design decision.
The fix is to annotate states explicitly. Not every state needs a full frame, but every non-obvious state needs a note. Loading, empty, error, overflow, and truncation behaviors should be documented in the handoff artifact, not left to inference. Some teams use a separate documentation page in the Figma file; others use a shared component documentation system. The medium matters less than the habit of documenting states before handoff.
Pattern 2: Token names in the design file do not match variable names in code
The design system has a color called Brand/Primary/Default in Figma. The code has a variable called --color-brand-primary. These name the same value but neither system automatically knows about the other. When the designer changes the color in Figma, nothing updates in the component. When the engineer changes the CSS variable, nothing updates in the spec.
This is the token naming problem. The resolution requires agreeing on a single naming convention before creating tokens, not after. Tokens Studio's transformation config lets you define how Figma token names map to CSS variable names. Getting this mapping right at the start means the design tool and the codebase share a vocabulary.
Where this is already broken: teams have to run a reconciliation. Walk the design file token list against the codebase variable list, find the mismatches, and pick one side's naming scheme to standardize on. It is tedious but it is a one-time cost. Ongoing drift costs more.
Pattern 3: The design review is too late
Design review happens when the engineer has already made most of the structural decisions. They built a layout, chose how to handle overflow, picked an interaction pattern. The review session identifies issues. Fixing them requires undoing work that was done in good faith.
The review cycle repeats. Each cycle costs time and erodes confidence on both sides. Designers feel like their intent is not being honored. Engineers feel like they are building the same component twice.
Teams that have reduced this pattern usually do it by moving design review earlier: to the component spec stage, before implementation starts. The engineer looks at the spec, asks questions about edge cases, and either gets answers or flags the component as not ready to implement. Fifteen minutes of synchronous conversation at the start of implementation is cheaper than two review cycles after.
The async spec review approach
An alternative that works for distributed teams: a formal async spec review step. Before implementation, the designer marks a component as "ready for review." The engineer has 24 hours to leave questions in the file. The designer answers before the engineer starts building. This adds a day to the timeline upfront. It typically saves three to five days in review and rework at the back end.
Pattern 4: Component variants exist in design but not in code (or the reverse)
A Figma component has 12 variants: three sizes, two themes, two states. The React component has a size prop and a disabled prop. The mapping is not documented anywhere. The engineer built the code component to match what the application needed, not what the design system had. Now there is a design spec that references a variant the code does not support, and code that has states the design never specified.
Variant divergence starts small and compounds. The design system team adds a new color theme variant. It does not get surfaced to the engineering team. Six months later, someone designs a screen using the new variant and the engineer building it has to create a net-new code state on short notice.
The fix has two parts. First, treat variant changes as a breaking change that both sides need to approve. A new design variant requires a corresponding code implementation plan. Second, use DesignVerse or a similar tool to make the mapping explicit: the design variant names and the code prop names should come from the same source so new variants surface on both sides simultaneously.
Pattern 5: Spacing is approximated, not specified
The designer places elements in Figma using visual judgment. Two elements that should have 16px between them end up with 14px because Figma's auto-layout nudged them. The engineer inspects the spec, sees 14px, and implements 14px. The spacing token for this context is --space-md which resolves to 16px. The result is a component that has two slightly different values for the same spacing decision.
Multiply this by 200 components and you have a product where no two elements quite align, but no individual element is obviously wrong. Visual polish degrades across the board without anyone making a clearly wrong decision.
The solution is to stop inspecting pixel values from Figma and start inspecting token references. If the design system has a spacing scale, the engineer should be asking "which spacing token does this use?" not "how many pixels is this?" If the answer is not clear from the spec, that is a conversation to have before implementation.
None of these are people problems
It is worth saying clearly: these patterns do not happen because designers or engineers are careless. They happen because the tools create gaps that effort alone cannot close. A designer cannot document every edge case because they do not know what edge cases the engineer will encounter. An engineer cannot match design intent exactly when the intent is encoded in a visual file.
The teams that handle handoff well do not have better people. They have better agreements: on naming, on review timing, on how variants map to code. They also use tooling that makes the agreements enforced by default rather than requiring both sides to remember them. Most handoff failures are process failures. Fix the process and the people on both sides find their jobs get easier.