Every few years, someone reinvents the handoff. Redlines became specs, specs became inspectable files, inspectable files became generated code: better tools, one after another, in the industry's longest-running game of whack-a-mole, and not one of them fixed what it was sold as fixing.
That is worth sitting with, because it suggests the problem was never the format. If a decade of steadily better artefacts has not removed the friction, the friction is not in the artefact.
What the handoff is actually hiding
A design file is a set of decisions with the reasoning stripped out. It shows sixteen pixels of padding but not that sixteen was chosen because twenty-four broke the layout at the smallest supported width. It shows an empty state but not that the empty state matters more than the populated one because most accounts will never populate it.
When an engineer implements from a file, they are reconstructing intent from evidence, and they are doing it while holding constraints the designer may not have known about. Most implementation disagreements are not disagreements at all. They are two people making reasonable inferences from incomplete information about each other's problem.
A more detailed file does not fix this. It adds evidence, which helps at the margin, and it does nothing about the reasoning, which is where the value was.
The questions that never get asked
The clearest symptom is the question an engineer decides not to ask. Something in the design does not quite work with how the data arrives, and it would take a conversation to sort out, and the designer is in another timezone or another project or simply hard to interrupt. So a reasonable guess gets made.
That guess ships. It is usually fine. Occasionally it is the thing that quietly makes the feature worse than it should have been, and nobody ever finds out, because the guess was never surfaced as a decision.
Multiply that by every screen in a release and you have the real cost of a handoff culture, which is not rework. It is a long tail of small unexamined choices.
What has worked instead
I do not have a process to sell here. What I have is a set of habits that consistently reduced how much a handoff had to carry.
Bring the engineer in before the design is good. Not at the review, at the point where there are three sketches and no decision. The constraints that matter arrive in that conversation, and they arrive cheaply. An engineer who saw the alternatives understands the choice, and an engineer who understands the choice can adapt it correctly when reality intervenes.
Design the states you cannot see. Loading, empty, error, too-long, offline, partial. These are where implementations diverge most, because they are where the file is usually silent and the engineer has to invent. Every one you specify is a guess you have prevented.
Write down the why for anything non-obvious. Not a document. A sentence next to the frame. "Sixteen, because twenty-four wraps at 320." It takes ten seconds and it survives you leaving the project, which the reasoning in your head does not.
Review the built thing together, on a real device, early. Not to catch defects, though you will. To rebuild shared context while it is still cheap to change something. A ten minute call at fifty percent done is worth more than an hour of comments at ninety-five.
The cost is asymmetric, and that is the whole problem
A designer interrupting an engineer costs the engineer a chunk of focus, and everybody knows it. An engineer interrupting a designer costs roughly the same and nobody counts it, because design work is assumed to be interruptible.
The result is a quiet economy where the cheapest move for either side is to guess rather than ask, and the guesses are invisible until they ship. Teams that work well have usually made asking cheap in some specific way: a channel where a half-formed question is normal, a standing fifteen minutes nobody has to book, a habit of answering in a thread rather than a meeting.
None of that is a process. It is a set of small agreements that lower the price of the question, and lowering that price does more for implementation quality than any specification format ever has.
Fidelity is a negotiation, not a standard
A recurring argument is how finished a design should be before it is handed over. The honest answer is that it depends entirely on the pair of people involved, and that pretending otherwise is what makes the argument recur.
An engineer who has worked with you for two years and knows the system needs a sketch and a conversation. A contractor joining for six weeks on an unfamiliar codebase needs something much closer to complete, because they have no context to fill the gaps with and no relationship that makes asking easy.
Teams get into trouble by setting one standard for both. Either the experienced pair is slowed down by ceremony that adds nothing, or the new person is handed a sketch and left to guess, and their guesses are worse because they are new. Neither is a fidelity problem. Both are a failure to notice that fidelity is a function of shared context.
The reviewer trap
There is a version of this that looks collaborative and is not: the designer reviews every build and files every difference as a defect.
It is exhausting, it is adversarial, and it optimises the wrong thing. Most of what turns up in that review is a two pixel difference nobody outside the team will ever see, and the time spent on it is time not spent on the one screen that genuinely came out confusing.
The version that works is to be specific about what actually matters on a given feature, and say so up front. Sometimes it is the spacing rhythm, because the feature is a dense table. Sometimes spacing is irrelevant and the whole thing rests on what the empty state says. An engineer told which axis matters will protect it; an engineer handed a list of forty comments will work through them in order and run out of time before the important ones.
The design system changes the shape of this
This is where component libraries earn their keep, and it is not the reason usually given for them.
The common argument is consistency. The better argument is that a shared system removes most of the handoff surface entirely. If a button is a component both people already understand, nobody has to specify it, inspect it, or discuss it. The conversation moves up to what the screen is trying to do, which is the conversation worth having.
The corollary is that a design system with poor coverage makes handoff worse, not better. Every screen becomes a mix of components that need no explanation and one-offs that need a lot, and the mix is not marked. The engineer cannot tell which is which without asking, which is exactly the ask they were avoiding.
Distributed teams do not get to skip this
The obvious objection is that everything above assumes proximity, and plenty of teams do not have it. Fair. But the answer to distance is not a better document, which is the assumption that got us here.
The answer is to make the reasoning durable and findable, because a conversation across timezones cannot be spontaneous. A short recorded walkthrough of a flow, three minutes, talking through why rather than what, is worth more than any amount of annotation. It can be watched at the point of implementation, which is when the questions actually arrive, rather than at a review that happened before they did.
The same goes for decisions. A thread where the trade-off was argued out is more useful six months later than a tidy summary, because the summary has the alternatives removed, and the alternatives are what someone needs when the constraint changes.
What to write down anyway
None of this is an argument for writing nothing. It is an argument for writing the things that a conversation cannot carry.
Worth writing: the reason behind a decision that looks arbitrary, the states that have no visual, the constraint that made an obvious approach wrong, the thing that must not change even if everything around it does.
Not worth writing: measurements a component already encodes, descriptions of what a screen visibly looks like, or a specification of behaviour that will be obvious the first time anyone runs it.
The test I use is whether the note would still be useful in six months to somebody who was not there. Reasoning passes that test. Redlines never have.
The thing to stop doing
Stop treating the moment of handoff as the point where responsibility transfers. That framing is the whole problem. It creates a before and an after, it puts a document at the boundary, and it makes the document responsible for carrying everything that was in two people's heads.
The feature is not designed when the file is done. It is designed when it is in front of people and working, and everything between those two points is design work whether or not it happens in a design tool. Teams that believe this do not have a handoff problem. They have a normal amount of implementation friction, handled in conversation, which is what it always should have been.