Designs look perfect in Figma. Then developers build them and something is wrong.
Buttons end up the wrong shade of blue. Spacing doesn’t match. Hover states don’t exist. Mobile behavior is undefined. What the designer envisioned and what got built diverge somewhere in translation.
This gap isn’t inevitable. But it’s common enough that most teams have experienced it. Understanding where communication breaks down helps prevent the breakdowns.
Missing States
Designs show ideal scenarios. Real interfaces have many states.
Buttons exist in specs. But what about buttons when hovered? When focused? When disabled? When loading? When clicked and waiting for response?
A designer might create the default state and assume other states are obvious. A developer who doesn’t know the intended hover color picks one. Maybe they pick correctly. Maybe they don’t.
Multiplied across dozens of interactive elements, these gaps accumulate. The shipped product has interaction behavior nobody explicitly designed. Some of it works fine. Some doesn’t.
Complete state documentation prevents this. Every interactive element needs every state defined. Design tools make this tedious but tools like Figma’s component variants help. The investment in completeness pays off in implementation accuracy.
Responsive Ambiguity
Designs show desktop at 1440 pixels. What about 1200 pixels? What about tablet? What about phone?
Breakpoint behavior rarely gets fully designed. Designers create key viewport sizes and expect developers to interpolate between them. Sometimes that interpolation matches intent. Often it doesn’t.
What happens to the three-column layout at 900 pixels? Does it become two columns? Does it stack? At what point? What reflows first?
These questions have answers in the designer’s mind. If those answers aren’t communicated, developers guess. Different developers guess differently. The build doesn’t match the vision.
Explicit breakpoint documentation helps. Specify what changes at each breakpoint. Show the in-between states, not just the endpoints. Don’t leave responsive behavior to interpretation.
Animation and Interaction Details
“This slides in” is not a specification.
How fast does it slide? Linear or eased? What easing curve? Does it fade while sliding or just move? Does other content push out of the way or does this overlay?
Animation details that seem obvious to a designer often aren’t obvious to a developer implementing them. “It should feel smooth” isn’t actionable. “300ms ease-out from right to final position” is actionable.
Interaction prototypes help communicate what static mockups can’t. Even rough prototypes that demonstrate timing and movement transfer information more accurately than verbal descriptions.
Micro-interaction specifications matter too. Focus ring appearance. Loading spinner behavior. Error message entrance. Every animated moment needs enough specification to implement consistently.
Asset Format Problems
Developers need PNGs at 2x resolution. Exports arrive as 1x JPG.
Asset handoff seems straightforward but creates surprising friction. Wrong formats, insufficient resolution, missing variants. Each misalignment sends someone back to re-export.
Clear asset requirements prevent this. Document expected formats, resolution multipliers, naming conventions. Use export presets that produce correct outputs automatically.
Optimization responsibility often falls in the gap between design and development. Who compresses images? Who converts to WebP? If nobody owns this, it doesn’t happen. Assign responsibility explicitly.
Icons particularly cause problems. SVG versus PNG. Inline versus external file. Sprite sheets versus individual files. Alignment on icon delivery format saves repeated conversations.
Spacing Inconsistency
Designs show 24 pixels of padding. Developers implement 24 pixels. They measure again: the design actually shows 26 pixels.
Design tools and code don’t always align precisely. Designers work visually, adjusting until things look right. The resulting measurements may not fall on clean numbers.
Developers implement from measurements. If the design shows 26.5 pixels, what do they build? Round to 24? Round to 28? Pick 26 and accept the oddness?
Design tokens solve this systemically. Define a spacing scale: 8, 16, 24, 32, 48. Designers use only those values. Developers implement exactly those values. No ambiguity.
Without tokens, specification should override visual measurement. “The padding is 24px” stated explicitly beats measuring the Figma file and getting 23.7px.
Version Confusion
Designs changed. Developers built old versions. Now someone has to redo work.
Multi-version chaos happens when design and development timelines overlap. Design iteration continues while development implements. Nobody is sure which version is current.
Single source of truth eliminates this. One canonical design location that everyone references. Updates happen there. Everyone knows to check there.
Change communication matters too. When design updates, developers need to know. Automated notifications, regular syncs, or explicit handoff moments ensure awareness.
Naming and versioning conventions help track currency. Date stamps, version numbers, or explicit “approved” status flags distinguish work in progress from implementation-ready.
Insufficient Sync Frequency
Designer creates specifications. Developer implements. Weeks later they compare. Divergence is extensive.
Low-frequency communication allows assumptions to compound. The developer interpreted something one way. The designer meant something else. Without checkpoints, the gap widens until it’s expensive to correct.
Regular syncs catch problems early. Weekly or even daily check-ins during active development. Quick reviews of work in progress. Questions answered before wrong implementations solidify.
Async communication channels help between syncs. Slack questions get quick answers. Comment threads in Figma or code review catch issues without waiting for meetings.
Relationship matters. Designers and developers who know each other communicate more easily. Investing in relationship building pays off in smoother collaboration.
Missing Edge Cases
Designs show cards with three-word titles. Real content has thirty-word titles. Layouts break.
Content variation exceeds design coverage. Real data has extremes that designs with placeholder content don’t anticipate.
Empty states are commonly missed. What does the page look like with zero items? With one item? With one thousand items?
Error states often lack design. What happens when the API fails? When validation rejects input? When loading takes too long?
Edge case checklists help ensure coverage. What if content is very short? Very long? What if images are missing? What if the user has no data? Running through possibilities systematically surfaces gaps.
Testing designs with real content or realistic extremes reveals fragility before development begins.
Fixing the Process
Handoff problems stem from process, not people. Better processes reduce friction regardless of who’s involved.
Handoff checklists ensure completeness. Required deliverables, required states, required specifications. Nothing proceeds until the checklist is complete.
Shared design-development reviews catch issues collaboratively. Instead of designer handing off and walking away, both parties review together. Questions get answered immediately.
Design QA as a formal stage validates implementation against intent. The designer who created the specification verifies the build matches. Discrepancies get logged and addressed.
Documentation of decisions prevents recurring questions. Why is this 24px instead of 32px? If the decision is documented, nobody asks again.
FAQ
Our designers use Figma, but developers don’t check it. How do we change that?
Make Figma the required source. Stop providing assets or specifications through other channels. If the only way to get implementation details is Figma, developers will use Figma. Also ensure developers have proper access, understand how to find things, and have training on extracting what they need.
Design keeps changing during development. How do we manage this?
Establish change windows. Certain development phases accept design changes; others are frozen. Urgent changes go through an exception process with explicit acknowledgment of the rework cost. Make the cost of late changes visible so stakeholders make informed decisions about whether changes are worth the impact.
We don’t have time for complete state documentation. What’s the minimum?
Prioritize by implementation risk. States that are ambiguous or easy to get wrong need documentation. States that are obvious from convention might not. At minimum: hover, focus, disabled for interactive elements; empty, loading, error for data-dependent components; collapsed and expanded for toggleable elements.
Our team is small. Designer and developer are the same person or sit next to each other. Do we need formal handoff?
Less formal, but documentation still helps. Even for yourself, future you won’t remember current you’s decisions. Minimal documentation ensures consistency and provides reference when you forget why you made a choice. Co-located teams can rely more on conversation but shouldn’t rely entirely on memory.
Sources
InVision. Design Handoff Guide. invisionapp.com/inside-design/design-handoff
Figma. Developer Handoff. figma.com/best-practices/tips-on-developer-handoff
Smashing Magazine. Improving Designer Developer Collaboration. smashingmagazine.com
Nielsen Norman Group. Design Handoff. nngroup.com/articles/design-handoff
Zeplin. Handoff Best Practices. zeplin.io/blog/design-handoff-best-practices