The Design Handoff Checklist (2026): What Engineers Actually Need

Key Takeaways

• Specs are solved. Rules and rationale are not. Spend your handoff effort where the tooling cannot help.
• Handoff is a conversation, not a delivery. The moment it becomes a document thrown over a wall, it fails.
• Edge cases are the deliverable. Empty, loading, error, overflow, and permissions are where implementations diverge.
• Say what is non-negotiable and what is not. Engineers make better trade-offs when they know which is which.
• Include accessibility in the handoff, not after it. Retrofitted accessibility is a rebuild.

The Three Layers of Handoff

Layer one: the what

Screens, measurements, colours, type, spacing, assets, and design tokens.

This layer is automated. Dev Mode in Figma and its equivalents expose measurements, generate code snippets, and export assets on demand. Your job here is small and mostly about hygiene: name layers so they are findable, mark the file version that is actually being built, remove the abandoned explorations, and make sure tokens map to whatever the codebase already uses rather than inventing a parallel naming scheme.

If you are spending significant handoff time here, you are doing work a tool does better.

Layer two: the rules

Everything true about the interface that a static frame cannot express.

States. Default, hover, focus, active, disabled, selected, loading, and error for every interactive element. Focus states in particular are skipped constantly and are a keyboard accessibility requirement, not a nicety.

Content extremes. What the screen looks like with nothing, with one item, and with far more than expected. What happens to a layout when a name is one character or seventy.

Transitions and motion. Duration, easing, what animates and what does not, and what the reduced-motion version is. If motion is unspecified, it will either be omitted or invented.

Responsive behaviour. Not just the breakpoints you drew, but what happens between them. Which elements reflow, which wrap, which are hidden, and what the priority order is when space runs out.

Interaction detail. What is clickable versus what merely looks clickable, what happens on submit, what is optimistic versus what waits for the server.

This layer is where most handoff effort should go, and it is the one that shrinks review cycles the most.

Layer three: the why

The rationale that lets an engineer decide correctly about something you never drew.

The intent of the screen. What is the user trying to accomplish, and what is the one thing that must work.

Which rules are load-bearing. "The primary action must remain visible without scrolling" is a constraint. "This card has a twelve-pixel radius" is a preference. If you do not distinguish them, engineers treat them identically, which means either everything gets litigated or nothing does.

What was tried and rejected. Prevents the well-meaning suggestion to implement the thing you already ruled out.

The known compromises. Where you already know the design is imperfect and why you accepted it. This stops an engineer spending a day fixing something you decided on purpose.

Layer three is almost never delivered, and it is the layer that determines whether the build survives its first unanticipated case.

The Handoff Checklist

Run this before calling a handoff complete.

The last row is the most valuable one in the table. Something will not be buildable as drawn. Deciding in advance who adjudicates that, and how fast, is worth more than any amount of specification.

When Handoff Actually Happens

The word implies a moment, and treating it as one is the most common structural mistake. Handoff is a sequence of checkpoints, and the earlier ones do most of the work.

While the design is still rough, bring an engineer in. Not for approval, for feasibility. Ten minutes at sketch stage catches the thing that is disproportionately expensive to build, while it is still free to change. This is the single highest-return moment in the whole sequence and it is the one most often skipped, usually because designers do not want to show unfinished work.

When the direction is settled, agree the data. What fields exist, what is optional, what the real maximum lengths are, what the API can and cannot return. A large share of edge-case surprises are really data surprises, and they are knowable before the screens are drawn.

When the design is complete, do the walkthrough. Live or recorded, twenty minutes, covering intent, the states, the edge cases, and what is non-negotiable. Not a screen-by-screen tour, which nobody retains.

During the build, stay reachable. The questions that arrive mid-build are the valuable ones, because they are exactly the cases the design did not anticipate. Answer them fast and write the answers somewhere they persist, because the next engineer will hit the same case.

When something cannot be built as drawn, use the protocol. Somebody decides, quickly, and the decision goes back into the file so the design and the product do not silently diverge.

After the build, review the implementation against the intent, not the pixels. The useful question is whether it does the job, not whether the padding matches. Pixel-diffing an implementation is a poor use of a design review and it trains engineers to treat the whole handoff as pedantry.

The pattern across all six: the cheap checkpoints are early and the expensive ones are late. A team that only does the third one has moved all of its risk to the end.

The Edge Cases Every Handoff Needs

If you produce nothing else beyond the screens, produce these.

Empty. No data yet, and the difference between "you have not created anything" and "your filter matched nothing," which are different messages with different actions.

Loading. Both the first load and the subsequent refresh, which usually look different. Whether it is a skeleton, a spinner, or nothing at all.

Error. Network failure, server failure, validation failure, and permission denial. Each needs copy, and the copy is a design decision rather than something engineering should invent.

Overflow. Long names, long titles, many items, deep nesting. Truncate, wrap, or scroll, and where exactly.

Permissions. What a user without access sees. Hidden entirely, visible but disabled, or visible with an upgrade path, and this is a product decision with real consequences.

Offline or stale. Whether the interface acknowledges it, and what happens to actions taken in that state.

Slow. What happens when something takes ten seconds instead of two hundred milliseconds. Often the most common real-world state and the least designed.

Accessibility Belongs in the Handoff

Accessibility added after a build is a rebuild, which is why it belongs here rather than in a later pass.

Focus order. The keyboard path through the screen, especially where the visual order and the DOM order differ.

Focus visibility. An actual designed focus state. The browser default is acceptable and being removed without a replacement is not.

Contrast. Checked for body text, but also for placeholder text, disabled states, icons carrying meaning, and text over images.

Names for icon-only controls. Every icon button needs an accessible name, and the designer is better placed to write it than the engineer.

Announcements. When something changes without a page load, decide what a screen reader should say. Silence is a decision, and usually the wrong one.

Motion. A reduced-motion alternative for anything that moves substantially.

Target size. Interactive targets large enough to hit reliably on a touch screen, which is a layout decision made at design time.

Handing Off to a Client or an External Team

When the receiving team is outside your organisation, three things change.

You will not be in the standups. The rationale layer has to be written down properly rather than transmitted by proximity, because there is no corridor to catch a question in.

Assume no shared design system. Tokens, components, and patterns that are implicit internally must be explicit here, including the ones you think are obvious.

Agree the deviation protocol in writing. What happens when something cannot be built as designed: who is told, how quickly, and who decides. Without this, external teams substitute silently and you discover it at review.

A short written rationale document, even one page, is worth more on an external handoff than another twenty screens.

Quick Picks: Tools for Design Handoff

Best for the handoff itself: Figma Dev Mode. Specs, measurements, tokens, code snippets, and asset export directly from the file the design lives in. For product work this is the default and there is no serious competitor. Included with paid Figma plans; pricing varies by seat type (verify current pricing).

Best for the specification of behaviour: a written document beside the file. Notion, a Markdown file in the repo, or a page in your wiki. The rules layer is prose and tables, not pixels, and it belongs where engineers already read things.

Best for async explanation: Loom. A five-minute walkthrough of intent and edge cases before the build starts reliably prevents a category of misunderstanding that written specs do not.

Best for the rationale layer: Storyflow. The canvas where the brief, the rejected directions, the constraints, and the reasoning sit together, so an engineer facing an undesigned case can see why the design is the way it is. Free plan is $0; Plus is $7.99/month billed annually. The honest limit: it produces no specs, no measurements, and no assets, and the design does not live there.

Pricing checked July 2026. Competitor pricing changes often and varies by plan and seat type, so verify on each vendor's page before quoting it.

Common Mistakes in Design Handoff

Treating handoff as an event. It is a conversation that starts before the design is finished and continues through the build.

Spending the effort on layer one. Specs are automated. Effort there is effort wasted.

No edge cases. The single largest source of post-build divergence.

No focus states. Skipped almost universally, and a keyboard accessibility failure.

Placeholder copy shipped as final. Lorem ipsum in a handoff becomes lorem ipsum in staging.

Not distinguishing constraints from preferences. Engineers cannot make good trade-offs without knowing which is which.

No named contact. A blocked engineer with nobody to ask will guess, and the guess costs a review cycle.

Accessibility deferred to a later pass. That pass is a rebuild.

The Bottom Line

The old handoff problem was information transfer, and tooling solved it. An engineer can read every measurement in your file without asking you anything.

What tooling did not solve is that a design file describes a finite set of screens and a real product has an infinite set of situations. The gap between those two is filled by an engineer making a judgment, and the quality of that judgment depends entirely on whether you told them what the screen is for and which rules actually matter.

So spend the effort where it counts. Draw the states and the edge cases, write down the rules that no frame can show, and say plainly what is non-negotiable and what you would happily trade. Handoff does not fail on the screens you designed. It fails on the screen nobody designed, and that is decided by whether the engineer knows why.

Author

Justkay is a documentary filmmaker and the founder of Storyflow. He works with the engineers building Storyflow, and rewrote the team's handoff practice after one too many correct implementations of an incorrect assumption.