When should the handoff happen?

After the design review is complete and stakeholders have approved the direction. Never hand off a design that is still being iterated on. The engineer will build the wrong thing and both teams will waste time. The [design review template](/templates/design-review-template) provides a framework for getting to approval.

Should engineers attend the design process before handoff?

Yes. The best handoffs are not surprises. Include the engineering lead in at least one design review so they understand the rationale behind decisions. Engineers who understand the "why" make better implementation trade-off decisions. Engineers who only see the "what" implement pixel-perfect mockups that miss the intent.

How do I handle designs that change after handoff?

Small changes (copy edits, color tweaks) can be communicated via Figma comments. Significant changes (new states, layout changes, added interactions) require an updated handoff document and a 15-minute walkthrough. If designs change frequently after handoff, the problem is usually that the design review process is not catching issues early enough. Use the [design brief](/templates/design-brief-template) to align on constraints before design starts.

What level of detail do animations need?

Specify duration (milliseconds), easing function (ease-in, ease-out, ease-in-out, or a cubic-bezier value), and the property being animated (opacity, transform, height). Engineers should not have to guess. If the animation is complex (staggered list items, physics-based springs), record a video reference or provide a prototype. Always note that animations should respect `prefers-reduced-motion` for [accessibility](/glossary/accessibility).

What if the design system does not cover a component needed for this feature?

Flag it as an open question in the handoff doc. The designer and engineer should agree on one of three approaches: (1) extend an existing component with a new variant, (2) build a one-off for this feature (tech debt, should be rare), or (3) add a new component to the design system (requires design system team review). Document the decision so future teams know whether this component is reusable. ---

Design Handoff Template

What This Template Is For

A design handoff is the moment a design moves from "approved in Figma" to "ready for engineering." It is where most design quality gets lost. The designer assumes the engineer will figure out hover states, responsive behavior, and edge cases. The engineer assumes the designer has specified everything. Neither is true. The result is a two-week cycle of "that's not what I designed" followed by "that's not what was specified."

This template provides a structured checklist and spec format that bridges the gap. It covers everything an engineer needs to build the design correctly on the first attempt: screen specs, responsive breakpoints, interaction states, animation behavior, copy (final, not placeholder), accessibility requirements, and asset delivery. If the engineer can build from this document without opening Figma, the handoff is complete.

This template follows naturally from the design review template (where the design was approved) and the design brief template (where the problem was defined). For the design system components being used, the design system documentation template provides reusable component specs. For complex flows being handed off, the user flow documentation template maps the full path. Teams doing structured product discovery use design handoffs as the transition from discovery to delivery.

How to Use This Template

Fill in the handoff metadata first: feature name, Figma link, target sprint, and engineering lead. This orients the engineer immediately.
Walk through each screen in the design and fill in the Screen Specs section. Include every unique state (default, hover, active, error, loading, empty, populated with max data).
Complete the Responsive Behavior section. Specify what changes at each breakpoint. If a designer says "it should just work on mobile," they have not finished the design.
Fill in the Interaction Specs for every interactive element: what triggers it, what it does, what animates, and how long animations take.
Write the exact copy in the Content section. Placeholder text from the design file is the number one cause of last-minute copy changes that break layouts.
Complete the Accessibility Checklist before handoff. Do not make accessibility the engineer's responsibility to figure out.
Schedule a 30-minute handoff walkthrough with the engineer. Walk through the document together. Answer questions. Then let them build.

The Template

Handoff Metadata

Field	Details
Feature / Project	[Name]
Designer	[Name]
Engineering Lead	[Name]
Figma File	[Link to final designs, Dev Mode enabled]
Prototype Link	[Link to interactive prototype]
Target Sprint	[Sprint number or date range]
Design Review	[Date approved, link to decision log]
Related PRD	[Link]

Pre-Handoff Checklist

Before sharing with engineering, confirm:

☐ All screens are in the Figma file (not just the happy path)
☐ Dev Mode is enabled with accurate measurements
☐ All text content is final (no "Lorem ipsum" or placeholder copy)
☐ Colors reference design system tokens (not hardcoded hex values)
☐ Components use the latest design system version
☐ All interactive states are documented (hover, focus, active, disabled, loading, error)
☐ Responsive layouts are specified for all target breakpoints
☐ Assets are exported in required formats (SVG, PNG @2x, WebP)
☐ Animations are specified with timing and easing values
☐ Accessibility requirements are documented (keyboard, screen reader, contrast)

Screen Specs

Document each unique screen or state in the feature.

Screen 1: [Screen Name]

Property	Value
Figma frame	[Frame name in Figma]
Page / Route	[URL or route path]
Layout	[e.g., Full width, max-w-4xl centered, sidebar + content]
Background	[Token or hex]

States to implement:

State	Figma Frame	Notes
Default	[Frame name]	[Notes]
Loading	[Frame name]	[Skeleton or spinner?]
Empty	[Frame name]	[What shows when no data?]
Error	[Frame name]	[Error message and recovery]
Populated (max data)	[Frame name]	[How does it handle 50+ items, long text?]

(Repeat for each screen)

Responsive Behavior

Breakpoint	Width	Layout Changes
Mobile	< 640px	[e.g., Stack columns, hide sidebar, full-width cards]
Tablet	640-1024px	[e.g., 2-column grid, collapsible sidebar]
Desktop	1024-1280px	[e.g., 3-column grid, persistent sidebar]
Wide	> 1280px	[e.g., Content max-width, sidebar fixed]

Mobile-specific changes:

☐ [Navigation: hamburger menu / bottom tabs / back button]
☐ [Touch targets: minimum 44x44px]
☐ [Content: what is hidden or collapsed on mobile]
☐ [Inputs: use appropriate mobile keyboards (numeric, email, tel)]

Interaction Specs

Element	Trigger	Behavior	Animation	Duration	Easing
[Button / link / card]	[Click / Hover / Focus / Scroll]	[What happens]	[Fade / Slide / Scale / None]	[e.g., 200ms]	[e.g., ease-out]
[Element]	[Trigger]	[Behavior]	[Animation]	[Duration]	[Easing]
[Element]	[Trigger]	[Behavior]	[Animation]	[Duration]	[Easing]

Transition notes:

☐ [Page transitions: instant or animated?]
☐ [Modal open/close: fade + scale from center, 150ms ease-out]
☐ [Toast notifications: slide in from top-right, auto-dismiss after 5s]
☐ [Reduced motion: all animations respect prefers-reduced-motion]

Content (Final Copy)

Location	Copy	Character Limit	Notes
[Page title]	[Exact text]	[Max chars]	[Truncation behavior]
[Button label]	[Exact text]	[Max chars]	[Loading state text]
[Error message]	[Exact text]	-	[When displayed]
[Empty state heading]	[Exact text]	-
[Empty state body]	[Exact text]	-	[CTA button text]
[Tooltip]	[Exact text]	[Max chars]	[Trigger: hover/focus]

Localization notes:

☐ [Languages supported]
☐ [Strings that may expand 40-60% in translated languages]
☐ [Date/number format by locale]

Accessibility Checklist

☐ Semantic HTML: [e.g., Use
for navigation,
for content,
☐ Keyboard navigation: [Tab order, Enter/Space activation, Escape to close modals]
☐ Focus management: [Where focus goes when modal opens/closes, when content loads dynamically]
☐ Screen reader: [ARIA labels, live regions for dynamic updates, role announcements]
☐ Contrast: [All text meets 4.5:1 AA. Non-text elements meet 3:1]
☐ Alt text: [Provide alt text for each image. Mark decorative images with alt=""]
☐ Form labels: [Every input has a visible or aria-label. Error messages linked via aria-describedby]

Assets

Asset	Format	Size	Location
[Icon name]	SVG	[Dimensions]	[Figma frame / exported file]
[Illustration]	PNG @2x	[Dimensions]	[Location]
[Photo]	WebP	[Max width]	[Location]

Asset notes:

☐ [Color mode: icons should work on dark and light backgrounds]
☐ [SVGs should be optimized (SVGO) and use currentColor for fill]
☐ [Images should have max file sizes: icons < 5KB, illustrations < 50KB, photos < 200KB]

Open Questions

#	Question	Owner	Status
1	[Unresolved design or implementation question]	[Name]	Open / Resolved
2	[Question]	[Name]	[Status]

Filled Example: Settings Page Redesign

Handoff Metadata

Field	Details
Feature	Settings Page Redesign
Designer	Jordan Lee
Engineering Lead	Maria Chen
Figma File	figma.com/file/settings-v3 (Dev Mode enabled)
Target Sprint	Sprint 14 (March 10-21, 2026)

Screen Specs: Profile Settings

States to implement:

State	Figma Frame	Notes
Default	settings/profile-default	Pre-filled with current user data
Editing	settings/profile-editing	Inline edit mode, Save/Cancel buttons appear
Saving	settings/profile-saving	Save button shows spinner, fields disabled
Saved	settings/profile-saved	Success toast: "Profile updated" (auto-dismiss 4s)
Error	settings/profile-error	Inline error below field: "Display name must be 2-50 characters"
Avatar upload	settings/profile-avatar	Drag-and-drop zone, 2MB max, JPG/PNG/WebP

Responsive Behavior

Breakpoint	Changes
Mobile (< 640px)	Tabs convert to a full-width dropdown selector. Form fields stack vertically. Avatar upload is full-width.
Tablet (640-1024px)	Sidebar tabs visible. Form fields 2-column where logical (first name / last name).
Desktop (> 1024px)	Sidebar tabs + form content side by side. Max content width 720px.

Interaction Specs

Element	Trigger	Behavior	Animation	Duration
Tab switch	Click	Load tab content, update URL hash	Fade in	150ms ease-out
Save button	Click	Validate, submit, show spinner	Spinner replaces label	Instant
Success toast	Save success	Slide in from top-right	Slide + fade	300ms ease-out, dismiss 4s
Avatar upload	Drag file	Show preview, upload in background	Fade in preview	200ms

Accessibility

☑ Tab bar uses role="tablist", tabs use role="tab", content uses role="tabpanel"
☑ Arrow keys navigate between tabs. Enter activates selected tab
☑ Focus moves to the tab panel when a tab is selected
☑ Success toast uses role="status" and aria-live="polite"
☑ Avatar upload area accepts keyboard activation (Enter/Space) and has aria-label="Upload profile photo"

Key Takeaways

Complete the pre-handoff checklist before sharing with engineering. Missing states cause rework
Specify responsive behavior at every breakpoint. "It should just work on mobile" is not a spec
Write final copy in the handoff doc. Placeholder text from Figma causes late-stage layout changes
Document accessibility requirements in the handoff, not as a separate QA phase
Schedule a 30-minute walkthrough with the engineer. Documents supplement conversations, not replace them

About This Template

Created by: Tim Adair

Last Updated: 3/4/2026

Version: 1.0.0

License: Free for personal and commercial use

Design Handoff Template