How to run a design to development handoff without guesswork

I run a design to development handoff by agreeing scope with the developer, specifying behaviour beyond the happy path, and walking through the riskiest decisions in ten minutes. I keep one versioned reference for implementation, record unresolved questions with owners, and check the build against explicit acceptance criteria.

What to include in a design handoff

I start with a buildable slice, not a page of finished screens. For an invitation feature, that might mean entering an email address, choosing a role, submitting, and seeing the result. Changing permissions afterwards is another slice. This boundary matters because an attractive screen can conceal several unrelated implementation decisions.

My handoff reference contains the feature's purpose, the agreed scope, the relevant designs, behaviour notes, acceptance criteria, and open decisions. I link it from the development ticket. I don't paste competing copies into chat and a separate presentation. A developer should know which reference wins when two versions disagree.

Before calling it ready, I ask a developer to check dependencies and constraints. Does the service support the proposed role? Can it distinguish an existing member from a pending invitation? If that discussion changes the design, it has done its job. I would rather redraw one interaction than specify behaviour the product cannot deliver.

How to write design specs developers can use

I specify decisions that cannot be reliably inferred from the file. That includes layout constraints, content rules, component variants, and responsive behaviour. I reference existing spacing and colour tokens instead of inventing a parallel specification. If a standard button already defines its height and padding, I don't repeat those values unless this instance genuinely differs.

Figma presents Dev Mode as a place to inspect designs and access implementation information. I use inspection for measurable properties, not as a substitute for explaining intent. A visible gap tells a developer the current distance between elements. It doesn't explain whether that distance should shrink, remain fixed, or disappear when content wraps.

For a two-column form, I might specify that the supporting panel moves below the fields when the main column can no longer accommodate them. I agree the actual breakpoint with the developer and test it with realistic content. I skip annotations that merely describe what is visible, such as a note saying that a blue button is blue.

Which component states belong in a handoff

I map states before polishing every screen. For each interactive element, I check its initial condition, pending behaviour, success result, and failure recovery. Not every state needs a separate frame. A reused component with established behaviour can be referenced; a new interaction or an exception needs more explicit treatment.

For an invitation form, my state inventory would include the following:

• Initial: the default role is visible, and the submit rule is defined.
• Invalid: field errors explain the problem and appear at an agreed point.
• Submitting: the form prevents duplicate requests and preserves entered values.
• Successful: the result appears, with a clear rule for clearing or retaining inputs.
• Failed: recoverable input remains available, with a defined retry action.

How to document edge cases and accessibility

I choose edge cases by consequence, not by how many extra frames I can produce. For an invitation, I would prioritise duplicate submissions, expired permissions, an existing member, and a request that times out. A timeout deserves particular attention: no response does not necessarily mean nothing happened. I ask how the implementation will check before retrying.

I also test content that breaks the composition. That means a long address, a translated label, no results, and enough results to require pagination or scrolling. I use actual content limits where they exist. If the limit is unknown, I record that uncertainty rather than quietly turning a convenient sample length into a product requirement.

Smashing Magazine's guide to accessible front-end components is a useful reference for the interaction details a static composition cannot express. I document keyboard operation, focus movement, accessible names, and feedback for status changes. For a closing dialog, I specify where focus returns. For a rejected submission, I specify how someone discovers the error without relying on colour alone.

How to run a ten-minute design handoff walkthrough

I send the reference before the meeting and use the walkthrough to test understanding. Ten minutes is a timebox for a small, prepared slice, not a claim that every feature can be explained that quickly. If the developer has not seen the scope, I would rather reschedule than sprint through twenty screens.

I divide the time deliberately:

• Minutes zero to two: explain the task, the intended result, and what is outside scope.
• Minutes two to five: show the main flow, including the component and layout decisions.
• Minutes five to eight: examine failure recovery, permissions, and the most consequential edge case.
• Minutes eight to ten: ask the developer to describe the implementation plan and record unresolved decisions.

How to manage design changes during development

I mark the agreed design version and record the review date in the ticket. From that point, a changed design is a changed agreement. I add a short note saying what changed, why it changed, and whether work already built is affected. Quietly moving a component in the source file is not adequate notification.

I separate blocking decisions from questions that can wait. An unresolved permission rule blocks implementation of the affected behaviour. A choice between two acceptable icon treatments probably does not. Each open item gets an owner and a decision deadline tied to the work it affects. A comment without either is easy to mistake for optional feedback.

When a technical constraint appears, I discuss the trade-off against the task rather than defending the original composition. A simpler interaction may be acceptable if it preserves understanding and recovery. Removing error feedback is a different proposition. I update the shared reference after the decision so the next person doesn't have to reconstruct it from a conversation.

How to check handoff quality after implementation

I review the working feature against behaviour first. Can someone complete the task, understand a failure, and recover without losing input? Then I check keyboard access, content extremes, responsive layout, and visual details. I compare the implementation with the agreed reference, not with unannounced improvements I made after development started.

I write acceptance criteria as observable outcomes. For example: submitting an invalid address displays a field-level explanation and preserves the selected role. That is more useful than asking for the form to match the design. I put these criteria in the ticket so the developer and tester can use the same checks before I review it.

To improve the process, I track clarification questions caused by missing information and reopened work caused by misunderstood behaviour. I count them per completed handoff and note the cause; raw totals rise when delivery volume rises. I don't aim for zero questions. I look for repeated omissions, then change the template only when that change would have prevented a real problem.

Questions people ask

What is a design to development handoff?

I treat it as an agreement about what will be built and how it should behave. The design file is one input, alongside scope, interaction rules, acceptance criteria, and unresolved decisions.

Is a Figma file enough for developer handoff?

I wouldn't rely on the file alone unless it also contains the necessary behaviour notes and scope decisions. Inspection can expose visual properties, but it cannot settle an unspecified retry rule or permission constraint.

When should developers be involved in design handoff?

I involve a developer before the interaction is treated as finished, especially when data or permissions shape the experience. The final walkthrough confirms decisions rather than introducing the feature for the first time.

Do I need to design every edge case?

I document consequential edge cases, but I don't draw a separate screen for every variation. I reference established component behaviour and create additional frames where a written rule would leave meaningful room for misunderstanding.

Where I checked my thinking

• Figma Dev Mode
• Smashing Magazine: A Complete Guide To Accessible Front-End Components