Design Handoff

For a long time, giving designs to engineering meant sending a file. The trouble is that a design file almost always contains one screen where everything went well. There's a list holding twelve documents, but no list holding none. There's a document titled in fifteen characters, but none titled in eighty. There's no failed save, and no screen for someone who lacks permission to open the thing.

Those screens still have to exist. When they aren't in the file, whoever is building at that moment decides them. Theo, implementing the document list, hits the empty case, works out that asking will cost half a day, leaves it as a blank area and moves on. That the first thing every new signup sees is an empty page is something Mia discovers a month later while looking at drop-off numbers.

Tooling solved the problem of moving values across. Designers used to write margins and type sizes onto the file by hand; now Figma and tools like it read those values straight out of the design. But that was a different problem. Values live inside the design, while missing cases and unsettled decisions live outside it. That's why handoff came to be called a process rather than an act of sending. It's the part the tools don't fill in.

Three things happen on the design before it goes over, and two more happen in the room.

1. Mark what's settled — separate the decided from the undecided, screen by screen. Noting "only the copy in this area changes next week" tells the engineer what to build in a way that's cheap to revise later.
2. Fill in the exceptions — draw everything other than the happy path. Empty list, very long text, loading, failed request, and no permission are the standard five. Drawing five more screens costs half a day; skipping them means five interruptions during implementation, or five decisions made without you.
3. Connect values and components — distinguish what's new from what already exists. If the button came from the design system, name it; if it's new, write down why the existing one didn't work. This is also where redlines, the measurements marked directly on the design, get attached.
4. Read it together — don't send the file and stop. Spend thirty minutes on the same screens. Most of what comes up takes the form "what happens in this case?" Five such questions is a good session. None at all means nobody has read it yet.
5. Agree where questions go — decide in advance where questions raised during implementation get posted. Implementation always meets something the design didn't anticipate, and without that channel those questions go back to being settled privately. A thread everyone can read also means the second person to hit the same case finds the answer instead of asking again.

The designer who drew the screens and the engineer who will actually build them both have to be there. Sending one representative to listen on the team's behalf rarely works, because the exception cases are the first thing lost when that person relays it onward. Product is worth including too, since deciding what gets built first and what drops out of scope happens here, and a designer left to make that call alone tends to either cut too much or nothing at all.

Timing is after the design is settled and a few days before implementation starts. Hold it earlier and the details get decided on screens that will change; hold it the morning work begins and there's no time to act on what surfaces. Running it before the estimating session is especially valuable. Seeing five exception screens routinely moves an estimate from two days to four, and that difference is work that was always there, just found late. An estimate given before handoff is an estimate for the happy path, which is rarely the thing being asked about.

When the session is hard to schedule, shorten it rather than skipping it. A two-screen change needs fifteen minutes, and one question raised in those fifteen minutes often saves two days. Teams that already keep a component spec, recording each component's properties and states, get through it faster still, because what used to be decided every time is decided once.

"Let's do handoff Thursday. I'll have the exception cases ready."

Not just the designs — the missing cases are coming too.

"This part isn't final yet, so build it in a way that's easy to change."

A request to match the implementation approach to an area still in flux.

"Empty state never came up at handoff. How should it behave?"

A decision that was missed, being asked mid-implementation.

Pagedeck's document sharing feature went into handoff as three screens and came out as eight. Noa brought the screen for picking people, the screen for setting permission levels, and the screen for copying a link. Theo read through and asked four questions: how someone who can already see the document appears in the invite list, whether an external email domain should be blocked, how a failed invitation email gets reported, and what happens when the person lowering a permission level is themselves.

Noa drew three of the four that afternoon. The fourth, Mia decided to leave out of scope, and instead they agreed on the single line of text that case would show and sent that along. Theo's estimate went from three days to five, but those two days weren't new work — they were work that had always been in there.

The most common mistake is treating handoff as a single act of delivery. The tool has a share button, so it's easy to believe pressing it completes the job. What actually has to travel is the decisions, not the screens. Without knowing what's settled, what isn't, and what happens in the cases nobody drew, the person implementing makes those calls alone — and calls made that way get written down nowhere, so months later nobody can explain the reasoning.

The belief that better tools have made the process unnecessary comes from the same place. Values are extracted automatically and code snippets come out the other end, so it looks like nothing is left for a person to do. Tools answer questions about what was drawn. About the screens that were never drawn they say nothing, and that's where most of the expensive questions live. The automation removed the copying, which was the cheap half of the job; the half that remains is judgment, and it still takes two people in a room.