by Format-3

Share article

{
"@graph": [
{
"@type": "Article",
"image": {
"url": "https://media.babylovegrowth.ai/blog-images/organization-13731/1792585864542_Designer-and-engineer-reviewing-an-interface-together.jpeg",
"@type": "ImageObject",
"caption": "Designer and engineer reviewing an interface together"
},
"author": {
"url": "https://format-3.co",
"name": "Format-3",
"@type": "Organization"
},
"headline": "Design to Dev Handoff: Stop Handing Off, Start Sharing",
"publisher": {
"url": "https://format-3.co",
"name": "Format-3",
"@type": "Organization"
},
"inLanguage": "en-GB",
"description": "Design to dev handoff works best when it is a continuing conversation, not a file drop. Here is a practical workflow, checklist and tooling guide for 2026.",
"dateModified": "2026-10-23T00:00:00.000Z",
"datePublished": "2026-10-23T00:00:00.000Z"
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{
"item": "https://format-3.co",
"name": "Format-3",
"@type": "ListItem",
"position": 1
},
{
"item": "https://format-3.co/design-to-dev-handoff",
"name": "Design to Dev Handoff: Stop Handing Off, Start Sharing",
"@type": "ListItem",
"position": 2
}
]
}
],
"@context": "https://schema.org"
}

Design to Dev Handoff: Stop Handing Off, Start Sharing

The most expensive sentence in product development is “it’s all in the Figma file.” A design to dev handoff fails not because the file is incomplete, but because a file was never the thing that needed to move. What has to travel from designer to engineer is intent: why this interaction behaves this way, what happens when the data is ugly, which parts are fixed and which are negotiable.

This guide covers how to run a handoff that preserves that intent, what to put in the design specs developers actually use, how current tooling changes the job, and why the best teams are quietly trying to abolish the handoff altogether.

Format-3

Bring Design and Engineering Closer

Format-3 brings strategy, design, and engineering together to create digital products, helping teams carry intent from concept into delivery.

Explore Format-3

TL;DR

A handoff is a shared understanding, not a deliverable. Treat the file as the artefact and the conversation as the product.
Work design one to two sprints ahead of engineering, so decisions are tested and validated before anyone builds.
Specs should cover three layers: the visual what, the behavioural rules (states, breakpoints, edge cases) and the reasoning behind them.
Map design components to real code components with tools such as Code Connect, so developers pull production code rather than a visual approximation.
AI speeds up documentation, but it cannot replace the human alignment on why an interaction exists.

Table of Contents

Why the classic handoff keeps failing
Move design one or two sprints ahead
What belongs in design specs for developers
A handoff checklist you can use this week
How the tooling has changed the job
Where AI helps, and where it does not
The provocative part: aim for no handoff at all
Our perspective: handoff is where strategy meets reality
When to bring in a partner
FAQ
Sources

Why the classic handoff keeps failing
Picture the familiar ritual. A designer spends weeks refining a flow, marks the frames final, drops a link in a channel and moves to the next project. Two sprints later, the build is “mostly right”. The spacing is a little off, the error state was improvised, and the transition that made the product feel considered has become a hard cut. Nobody did anything wrong. The knowledge simply lived in one head and the file only carried its shadow.

This is the waterfall habit hiding inside agile clothing. Design “finishes”, then engineering “receives”. The word handoff itself implies a baton, and batons get dropped in the gap between two people running at different speeds.

The gap is not mainly technical. Designers optimise for coherence and feeling; engineers optimise for performance, maintainability and risk. Those are both legitimate. The failure is treating the transfer as a one-time event instead of a negotiation that continues until the feature ships.

We wrote about the root of this in the biggest design problem isn’t design, it’s timing. Most handoff pain is a scheduling problem wearing a communication costume.

Move design one or two sprints ahead

The single most useful structural change is to stagger the work. NN/g’s guidance from agile practitioners is that fitting research, design and development of the same feature into one two-week sprint rarely works, so teams run UX activities ahead of the sprint in which engineers build.

In practice that looks like this:

1. Sprint N: design explores and validates the feature for sprint N+1, with an engineer in the room for feasibility.
2. Sprint N+1: engineering builds what was validated, while design is already working on N+2 and stays on call for questions.
3. Every sprint: design reviews the build in a running environment, not a screenshot, before it is called done.

The point is not speed. It is that by the time a developer picks up a ticket, the awkward questions have already been asked by someone with time to answer them. Rework drops because technical constraints surface while the design is still cheap to change.

If you are starting from nothing, a short design sprint is a good way to build this rhythm: a compressed period in which designers and engineers resolve the riskiest decisions together before any build begins.

What belongs in design specs for developers

There is a temptation to answer a failed handoff with more documentation. Resist it. The aim is the right amount, no more and no less. A useful way to think about it is three layers.

Layer one: the what

Screens, spacing, colour, type, assets and design tokens. This layer is largely automatable, and it should be. If a designer is still writing pixel values into a spreadsheet in 2026, the tooling is being underused.

Layer two: the rules

This is where most handoffs quietly fail, because a static frame cannot show behaviour. Specify:

• Empty, loading, error, partial and permission-restricted states.
• Content extremes: one item, no items, far more items than you hoped for, and a name that is forty characters long.
• Responsive behaviour: what reflows, what truncates, what disappears.
• Motion: duration, easing and what the movement is meant to communicate.
• Accessibility: focus order, labels, contrast and reduced-motion handling.

Layer three: the reasoning

One sentence of “why” beside a non-obvious decision saves a thread of questions later. “The confirm button is deliberately slow to enable because this action cannot be undone” changes how an engineer treats the edge cases. Without it, they will reasonably optimise the delay away.

A good test: could an engineer who missed the kickoff meeting build the right thing from the file and its annotations alone, and know when to come back with a question? If yes, you have enough. If they would have to guess, you have a gap. If they would have to read forty pages, you have too much.

A handoff checklist you can use this week

Before marking anything ready, run through it as a pair, designer and developer, not as a solo gate.

Check: Scope | Question to ask: Is it clear which frames are final and which are exploratory? | Owner: Designer

Check: Components | Question to ask: Does every element use an existing system component, or is a deviation flagged and explained? | Owner: Designer

Check: States | Question to ask: Are empty, loading, error and edge-case states designed? | Owner: Designer

Check: Behaviour | Question to ask: Are transitions, validation and responsive rules annotated? | Owner: Designer

Check: Feasibility | Question to ask: Has an engineer confirmed nothing here is unexpectedly expensive? | Owner: Developer

Check: Data | Question to ask: Do the designs reflect real or realistic data, not tidy placeholders? | Owner: Both

Check: Accessibility | Question to ask: Are focus order, labels and contrast covered? | Owner: Both

Check: Acceptance | Question to ask: Who reviews the build against the design, and when? | Owner: Both

The last row matters most. A handoff with no agreed review of the result is a hope, not a process.

How the tooling has changed the job

It is worth being precise about what tools now do, because the marketing runs ahead of reality.

In Figma, designers can tag sections with a Ready for dev status, giving developers a clear signal about what is finalised. The same guide recommends checking that designs use the design system consistently and annotating in Dev Mode, where a comment thread can carry the conversation when a component has been deliberately detached.

The larger shift is automation. Figma describes automated UI handoff as a live connection between design files and the development workflow, where components link to their code counterparts and specs update as designs change. Code Connect is the bridge here: it links components in your repositories to components in your design files, and supports mapping across frameworks such as React, SwiftUI and Jetpack Compose.

Why does that matter? Because generated code that ignores your component library is a debt in disguise. A snippet that looks right but bypasses the team’s real components gives the developer a visual approximation, which they must then rewrite or, worse, ship. Mapping design components to the actual repository components means the developer pulls code that already belongs to the system.

The workflow described by Mantlr follows the same logic: the designer marks frames ready for dev, and the developer’s editor pulls structured design context through the Model Context Protocol rather than transcribing properties by hand.

A sober reading of all this: tools have made the “what” layer nearly free. They have not touched the “rules” and “reasoning” layers, which is exactly where handoffs fail. Buying better software for a problem that is mostly about conversation is a classic way of building yesterday’s dreams with tomorrow’s tools.

Where AI helps, and where it does not

AI is genuinely useful in handoff: summarising research, drafting interaction documentation, flagging components that deviate from the system. Product designers writing about the 2026 workflow make a consistent point: AI is a catalyst, not a replacement for human communication, because it cannot replicate team alignment on the why behind complex interactions.

Our own view, set out in our guide to AI in product development, is that AI works best as infrastructure for the team rather than a substitute for its judgement. If a model writes the annotations and no human has argued about them, you have documentation without understanding, which is the original problem at higher speed.

There is a quieter benefit too. Details that survive a handoff, such as sensible loading behaviour, clear states and fast, stable pages, are the details that shape how a product feels and how it performs in search. If that link interests you, this piece on shows how UX choices feed visibility.

The provocative part: aim for no handoff at all

Here is the uncomfortable proposition. If your process needs a dramatic handoff moment, it is probably telling you that design and engineering are working as two separate departments with a border crossing between them.

The direction of travel among mature teams is toward co-ownership. Designers and engineers share the product experience, design finishes a sprint ahead, and a design system whose code implementation is treated as the single source of truth guarantees parity from the start. The handoff does not get better; it dissolves, because there is nothing left to transfer that both sides do not already hold.

That is not an argument for abolishing documentation. It is an argument for changing its purpose: from a message to a successor, to a shared record that two collaborators keep current together.

Four habits get you most of the way:

1. Pair early. An engineer joins design reviews while options are still open, and a designer joins refinement before tickets are sized.
2. Design in the system. Work with real components from the first draft, so the file and the codebase are speaking the same language.
3. Review in the build. Designers sign off on running software, in the browser or on the device, not on screenshots.
4. Keep the thread alive. Questions after “handoff” are not a failure. They are the process working.

We explore the human side of this in the role of collaboration in product development.

Our perspective: handoff is where strategy meets reality

We build digital products end to end, across strategy, design, engineering and growth, and the pattern we see is consistent: the quality of a product is decided less in the design tool than in the seams between disciplines. That is why we prefer to work as an embedded partner rather than a vendor who delivers a package and leaves.

When the same team holds the strategy, the interface and the code, the handoff shrinks to a conversation across a desk. Engineers shape the design while it is still malleable. Designers see how their decisions behave in production and learn from it. And because we think in systems rather than screens, what we build is meant to scale past the first release instead of needing to be redrawn.

Our advice to any team, ours or otherwise, is to measure the health of a handoff by how few surprises appear in the build. Surprises are a lagging indicator of conversations that did not happen. Fix the conversations and the files mostly take care of themselves.

— Martin

When to bring in a partner

If your handoffs keep leaking intent, the cause is often structural: no shared design system, design and engineering on different cadences, or a product that has outgrown its first team. That is the kind of problem we are built for. Our services span design sprints, product discovery, experience design, native apps, web experiences and full-stack development, so strategy, design and build can sit inside one accountable team. If you are ready to talk about a specific product, start from Format-3.

FAQ

What is a dev handoff?

It is the point at which a design moves from the people who shaped it to the people who will build it. In the modern version, it is less a single event than a continuing exchange: files, specs and annotations, plus the conversations that explain the intent behind them.

What should design specs for developers include?

Cover the visual basics (spacing, colour, type, assets, tokens), then the behaviour a static frame cannot show: states, edge cases, breakpoints, motion and accessibility. Add a short note of reasoning beside any non-obvious decision. Link components to their code counterparts wherever your tooling allows.

How far ahead of development should design work?

NN/g’s reporting from agile practitioners supports running UX work ahead of the sprint in which a feature is built, because two weeks is usually too short to research, design and build the same feature. One to two sprints of lead time is a sensible starting point, adjusted to your release cadence.

Do handoff tools replace talking to developers?

No. Tools such as Dev Mode and Code Connect remove manual transcription of specs and link design components to production code. They do not carry the reasoning behind a decision, so a short conversation at the start and a review of the running build at the end remain essential.

Sources

• Top 10 Tips for UX Success From Agile Practitioners, NN/g
• The Designer’s Handbook for Developer Handoff, Figma Blog
• Automated UI Handoff: A Guide for Design Teams, Figma
• Code Connect introduction, Figma Developer Docs
• Design Handoff in 2026: Dev Mode, MCP, and What’s Next, Mantlr

Recommended

• The Biggest Design Problem Isn’t Design, It’s Timing
• Hire a Partner, Not a Vendor
• No Exit: Committed Partnerships in Product Development

By Format-3

Press & Media

More thoughts

Thought leadership creates value, builds knowledge and takes a stand, bridging the gap between traditional and digital platforms