Handoff without meetings: a practical guide

Most handoff meetings exist because a design file can’t answer a developer’s questions on its own. Fix the file and the meeting goes away. Over the last year our product team shipped forty features without booking a single handoff call, and this is how.

Introduction

A handoff meeting feels productive. Everyone is in the room, the designer walks through the screens, the developer nods, and questions get answered on the spot. Then the call ends, the answers live in three people’s memories, and the same questions come back a week later when someone else picks up the ticket.

We didn’t ban meetings. We asked a different question: what would a developer need to find in the file so that the call wasn’t necessary? The answer turned out to be short, and it has changed how our designers finish their work.

Before we changed anything, we counted. Over six weeks, our developers asked designers 212 questions after handoff. Almost nine in ten fell into five groups, and every one of those groups is something a file can carry.

The five things developers need

These are the five, in the order our developers asked about them most. A file that has all five is ready to build; a file missing one isn’t finished yet, however good it looks.

1. Every state of every screen: empty, loading, error, partial and full.
2. Real content at its extremes: the longest name, the biggest number, no avatar.
3. Tokens, not raw values, for every colour, size and space.
4. Behaviour written down: what moves, what waits, what can be undone.
5. One owner and one open-questions list, pinned to the frame.

None of these is new. What changed is that we treat them as the definition of done for design, the same way a developer treats tests as the definition of done for code.

States and real content

The happy path is the least useful screen in a handoff, because it is the one everybody already understands. Our designers now draw the empty state first. It forces the question of what a new customer sees, and it is usually the screen with the most copy to write.

Real content matters just as much. A table that looks tidy with five rows of short names falls apart with a two-hundred-row account and a customer called Maximiliane Oppenheimer-Castellanos. We keep a page of awkward sample data in the shared library, and every frame gets tested against it before handoff.

Tokens, not values

When a developer inspects a button and sees #2563EB, they have to guess whether it’s the brand colour, a one-off or a mistake. When they see a token such as bg-brand-solid, there is nothing to guess. DrumKit’s Inspect panel shows the token first and the raw value second, and our designers work the same way round.

The rule we settled on is simple: if a value in a file doesn’t come from a token, it gets a comment saying why. Most of the time the answer is that it shouldn’t exist, and the designer swaps it before handoff.

Behaviour and review

Behaviour, written down

Static frames can’t show time. What happens when you press Save? Does the button wait, does the row appear straight away, can you undo it? We used to explain this in meetings. Now each flow has a short note beside the first frame that answers three questions: what changes, how long it takes and how to reverse it.

For anything with motion, a thirty-second prototype beats a paragraph. We link it from the note rather than embedding it, so the file stays fast to open.

Reviewing without a call

The last piece is the review itself. The developer who picks up the work reads the file and leaves comments on the frames, not in a chat thread. The designer answers there too, and resolves each thread once the file is updated. Anyone who arrives later reads the answers in place.

Each file keeps an open-questions list pinned beside the first frame. A handoff is ready when that list is empty or every item left on it has a named owner and a date.