Twenty years ago, give or take, handoff meant a PDF or PPT and a meeting.
Not because designers were unsophisticated. Because the tools available were Photoshop and Illustrator — neither of which had a handoff concept. So you exported what you could, attached it to an email, and booked a meeting to explain what the attachment meant. The developer arrived expecting both. The meeting was not optional. It was the handoff.
Then came Sketch. Then Figma. Then Zeroheights. Then Figma Dev Mode. Each tool promising to close the gap between design intent and production output. Each tool adopted by designers who believed the format was the problem. Each tool met by developers who still had questions that the format could not answer. And so the meeting continued. Under a different name, in a different tool, with a different screen shared — but the same dependency on a human to translate what the spec actually meant.
The handoff tool changed every few years. The culture did not. Twenty years later — the meeting is still happening. The only thing that has changed is the screen being shared.
The handoff is the moment where everything the design system promises is either delivered or abandoned. A component with perfect tokens, correct accessibility states, and thorough documentation still fails if the engineer who implements it does not know what the designer intended in the edge cases the spec did not cover. The spec never covers all the edge cases. That is not a documentation problem. That is a handoff problem.
A handoff that requires a human to translate in real time is not a handoff. It is a dependency with a calendar invite.
Why the Meeting Never Left
The meeting persists for three reasons. None of them are the tool.
Reason 1 — The Format Was Designed for the Sender
Every handoff format in the history of design tooling was designed around what the designer could export, not what the engineer needed to receive. The PDF was what Photoshop could produce. The Zeplin file was what Sketch could generate. The Figma link was what Figma could share. The question of what an engineer actually needed to implement correctly — the prop API, the interaction states, the edge case behavior — was answered by the meeting, not the format.
A handoff format built for the sender is a filing system. A handoff format built for the receiver is a specification.
Reason 2 — Nobody Wanted to Learn the New Tool
Every new handoff tool required the engineering team to learn something they had not asked to learn. Figma Dev Mode required engineers to open Figma. Zeroheights required engineers to navigate a separate documentation platform. The tool was correct. The adoption path was not. The engineering team already had a tool they trusted. It was open on their second monitor. It was called Jira.
The teams that avoided this problem did not find a better tool. They found a willing squad — one team, usually with a technically curious lead, who was prepared to take the challenge and learn something new. Not because it was mandated. Because they were invited into the process before the process was finalized. The willingness came from the invitation. Most teams skipped the invitation and went straight to the rollout. The engineers responded the only way a rational person responds to an unrequested tool adoption: they called the designer.
Reason 3 — The PM Became the Bridge
In the absence of a handoff process that actually worked, most organizations found a workaround. The product manager became the translation layer between design and development. The PM who understood enough of both to carry the intent from one side to the other. On the surface, the arrangement sounds admirable: someone bridging disciplines, reducing friction, and helping teams move. But structurally, it often concentrates control in one place. Design becomes negotiable. Velocity does not. What is framed as collaboration is actually prioritization through managerial filtering.
On the surface, the arrangement sounds admirable: someone bridging disciplines, reducing friction, and helping teams move. But structurally, it often concentrates control in one place. The translation layer decides what survives. Design becomes negotiable, while velocity becomes non-negotiable, because speed is the currency most legible to leadership. In many cases, what is framed as collaboration is actually prioritization through managerial filtering.
The translation layer decides what survives the crossing.
Design becomes negotiable. Velocity does not.
And when the PM leaves — the handoff leaves with them.
The Handoff Layer
The handoff that holds is not a better format. It is a layer built into the environment the receiving team already works in.
Figma Dev Mode — included in Figma's paid plans — closes part of this gap for teams already using Figma. It surfaces the component's token values, spacing, and properties directly in the design file without requiring a separate platform. The limitation is the same one that has always existed: it requires the engineer to open Figma. For engineers who have never opened Figma and have no reason to start, Dev Mode is a feature they will not discover on their own.
Three Rules for a Handoff That Holds
Rule 1 — Start Where Engineering Already Lives
The highest-adoption handoff format for most organizations at the ICP company size is a Jira ticket with structured design annotation fields built into the ticket template. Not a separate tool. Not a new platform. A template inside the tool the engineering team opens every morning.
Jira's ticket templates support custom fields — free for small teams, standard for most engineering organizations already in the Atlassian stack. Four fields added to every design-related ticket: component name, Figma link, known edge cases, and acceptance criteria from the design perspective. The engineer does not need to ask what the designer intended. The intent is in the ticket. The ticket is where the engineer already is.
Confluence extends this naturally. Same Atlassian ecosystem, same login, already familiar to every team using Jira. The component spec, the decision rationale, the usage guidelines — documented in Confluence and linked directly from the Jira ticket. The engineer follows one link inside the tool they already trust and arrives at everything the handoff needs to communicate. No new platform. No new login. No reason to resist.
And then there is PowerPoint. Still in the room. Still the format a stakeholder will forward to a VP who missed the meeting. Still the artifact a decision gets made inside before anyone opens Figma. Figma did not replace PowerPoint. It just added another tool the developer has to ignore before opening PowerPoint. Name this reality in your handoff process and build for it — because the handoff that does not account for PowerPoint will eventually be translated into one.
The transition from no handoff process to a structured one is easiest when the structure arrives inside a tool the team already trusts. Jira is that tool for most engineering teams. Confluence is the documentation layer they already accept. Start there. Expand from adoption, not aspiration.
Rule 2 — Make the Handoff Asynchronous
The meeting persists because the handoff format does not answer the questions the engineer will have. The async alternative is not a longer spec. It is a Loom recording that walks through the component, names the edge cases the spec does not cover, and answers the two or three questions the engineer will ask before they ask them.
The Loom recording does not replace the spec. It completes it. The spec covers what. The recording covers why and what happens when. An engineer who watches the recording before implementation arrives at the codebase with the same context the designer had when they made the decision. The meeting is no longer required because the information the meeting would have provided is already available.
Rule 3 — Find the Willing Squad First
Do not roll out the new handoff process to every team at once. Find one squad with a technically curious lead. Invite them into the process before the process is finalized. Ask them what a complete handoff looks like from their side. Build their answer into the format. Let them be the first team to use it.
The squad that helped build the handoff format will not resist adopting it. They will advocate for it. Every other squad that hears about it hears about it from a peer, not from the design system team. That is the adoption path that actually works. It is slower than a rollout. It is faster than the six months of resistance a rollout produces.
The willingness to adopt a new process comes from the invitation to shape it. Most teams skip the invitation. Then they wonder why the rollout failed.
The Quick Win: Audit the Last Handoff
Look at the last component your team handed off to engineering. Answer three questions.
- How many follow-up questions did the engineer ask after receiving the handoff?
- How many of those questions were answered in the spec and ignored — versus genuinely absent from the spec?
- Who answered them — the designer directly, the PM, or nobody and the engineer made a judgment call?
Every follow-up question is a handoff gap. Count them before you redesign the format. The number tells you how broken the current process is. The questions tell you exactly what the next format needs to answer.
Pick the three most common questions from the last five handoffs. Build the answers into the Jira ticket template before the next component ships. That is your handoff process version one. It does not require a new tool. It requires three fields and one willing squad.
The Argument
The handoff has been a problem for as long as design and engineering have been separate disciplines. The tools have improved. The meeting has not left. Because the meeting was never a tool problem. It was a process problem — a gap between what the designer knew and what the engineer received that no format has ever fully closed without a human in the middle. The handoff that holds is not the one with the best format. It is the one built with the people who have to use it, in the environment they already work in, answering the questions they will actually ask. Everything else is a better PDF.
Disagree loudly. Inspire boldly.
And remind me — falsely if needed — that somewhere a design handoff was received, implemented, and shipped without a single follow-up question.
How many follow-up questions did your last handoff generate — and what does that number tell you about the process? 🤔
