I've sat on both sides of the handoff. Designed things and then handed them to engineers. Received designs and figured out how to build them. The friction everyone talks about — the Figma files that don't account for edge cases, the engineers who don't understand visual hierarchy — is real, but I don't think it's the actual problem.
The actual problem is a different relationship with uncertainty.
How designers think about uncertainty
Good designers are comfortable with things being unresolved for a long time. They'll hold multiple directions in parallel, explore deliberately, and stay in the problem space longer than feels productive. The value of that is real: you make better decisions when you've actually understood the space.
The artefact that comes out of that process — the design file, the prototype — looks finished. That's partly the nature of the tool. Figma doesn't have a way to say "I'm not sure about this."
How engineers think about uncertainty
Engineers want to resolve uncertainty fast, because unresolved uncertainty is a risk. If a decision is deferred, something downstream might depend on it. If a behaviour isn't specified, someone has to make a call later — usually at the worst possible time.
So engineers push to close things. What happens on mobile? What if the list is empty? What's the loading state? These aren't obstructions. They're the job.
The collision
When a designer hands off work with unresolved questions embedded in it — not intentionally, just because the visual artefact hides them — and the engineer starts building, those questions surface as blockers.
The engineer asks a clarifying question. The designer, who has moved on to the next thing, doesn't understand why this is being flagged now. The engineer wonders why these things weren't thought through. The designer wonders why the engineer can't just make a sensible call.
Neither of them is wrong. They're operating from different assumptions about what the handoff contained.
What actually helps
The most useful thing I've found is making the unknowns explicit before the handoff. Not a massive spec doc. Just a short list: here are the three things I haven't resolved, here's what I'm assuming for now, flag me if it's a problem.
That one habit has removed more friction than any process change I've seen.
The second thing: engineers need to get comfortable making small visual decisions without escalating them. If the spec doesn't say what the empty state looks like, build something sensible and show it. Don't block. The designer can react to something real faster than they can answer an abstract question.
The version I want
The teams I've seen work best aren't the ones with the best tools or the most thorough process. They're the ones where both sides have enough context about how the other thinks that they can anticipate each other's questions before they're asked.
That comes from working together, not from a better handoff format.