Design Handoff Checklist for Developers

The design is approved. Everyone loves it. Now someone needs to build it. And this is where things fall apart.

A developer opens the design file. The body text is 15px — or is it 16px? The spacing between cards looks like 24px but might be 32px. There’s a button that says “Submit” but nobody documented what happens after it’s clicked. Is there a success message? A redirect? An animation?

A design handoff checklist bridges the gap between what the designer envisioned and what the developer builds. It’s not about controlling the process — it’s about giving developers everything they need to ship accurately without twenty Slack messages a day.

Before handoff: get approval locked down

Don’t hand off work that isn’t fully approved. Every change after handoff costs significantly more than a change during the design phase. Before starting the handoff package:

• Final designs are approved by all stakeholders. Use an approval workflow to get explicit sign-off, not just “looks good.”
• Content is finalized. All copy, headlines, labels, and microcopy are final — not placeholder text. Copy changes during development cause layout bugs.
• Edge cases are designed. Empty states, error states, loading states, and long-content scenarios have been designed, not just the happy path.

If any of these aren’t done, you’re handing off an incomplete design. Pause and finish them first.

Layout and spacing

This section prevents the “eyeballing it” problem. Developers shouldn’t have to guess measurements.

• Grid system documented. Column count, gutter width, margins, and max-width. If you’re using an existing system (like a 12-column grid at 1280px), reference it.
• Spacing scale defined. List every spacing value used: 4px, 8px, 16px, 24px, 32px, 48px, 64px. Map them to your design system tokens if you have them.
• Component spacing annotated. For key components, annotate the internal padding and external margins. This matters most for cards, form groups, and section headers.
• Responsive breakpoints specified. Define exactly which breakpoints the layout changes at. For each breakpoint, show what changes: column count, font sizes, visibility of elements, and stacking order.
• Max-width and alignment. Specify the content max-width and whether sections are centered, left-aligned, or full-bleed.

Typography

Typography specs are where small inaccuracies compound into a noticeably different feel.

• Font files or links provided. Include the exact font files (or Google Fonts / Adobe Fonts link) with the weights needed: Regular, Medium, Semi-Bold, Bold, etc.
• Type scale documented. For every heading level and body style, specify: font family, weight, size, line height, and letter spacing.
• Responsive type sizes. If font sizes change at breakpoints, document each change. A 48px desktop heading that stays 48px on mobile will overflow.
• Text styles named consistently. Use the same naming convention across design and code: “heading-1”, “body-large”, “caption.” This avoids translation confusion.

Color

• Full palette provided. Every color used in the design, with hex codes (or HSL/RGB). Include background colors, not just brand colors.
• Semantic color mapping. Map colors to their purpose: primary, secondary, success, error, warning, info, neutral. This helps developers use the right token.
• Opacity values noted. If any elements use transparency, specify the exact opacity.
• Dark mode colors (if applicable). Provide the full alternate palette, not just “invert the colors.”

Assets and icons

Missing or incorrectly exported assets are a constant source of developer frustration.

• Icons exported as SVG. Provide individual SVG files for every icon. Specify whether they should be inline SVGs or an icon sprite.
• Images exported at correct sizes. Include 1x and 2x versions for raster images. Specify the format: WebP for photos, PNG for transparency, SVG for illustrations.
• Image naming convention. Use descriptive, kebab-case names: hero-dashboard-preview.webp, not Screenshot 2026-04-10 at 3.45.12 PM.png.
• Logo variations provided. Full color, single color, reversed (for dark backgrounds), and favicon versions.
• Asset folder organized. Group assets by page or component, not dumped in a single folder. Include a brief README or index if the folder structure isn’t obvious.

Interactive states and behaviors

This is the section designers skip most often — and the section developers need most.

• Button states. Default, hover, active, focus, disabled. Show each one visually.
• Link styles. Default, hover, visited, focus. Underline behavior.
• Form field states. Empty, focused, filled, error, disabled, read-only. Include the error message text and positioning.
• Loading states. What does the user see while content loads? Skeleton screens, spinners, progress bars — specify which and where.
• Transitions and animations. Duration, easing curve, and trigger. Don’t just say “it fades in.” Say “opacity 0 to 1, 300ms ease-out, triggered on scroll into viewport.”
• Scroll behavior. Which elements are sticky? What’s the sticky offset? Does the header shrink on scroll?

Responsive behavior notes

Don’t assume developers will figure out responsive layouts from looking at one desktop mockup and one mobile mockup.

• What hides on mobile? List elements that are hidden at smaller viewports: sidebar navigation, decorative images, secondary CTAs.
• What reorders? If a two-column layout stacks on mobile, specify which column comes first.
• Touch vs. hover. For any hover-dependent interactions (tooltips, dropdown menus), document the touch alternative.
• Tap targets. Minimum 44x44px for all interactive elements on mobile. Flag any elements that are too small and provide the enlarged mobile version.

Handoff communication

The checklist above covers the deliverables. But how you share them matters too.

Use a single source of truth

Don’t email a ZIP file of PNGs. Use a tool that keeps the latest version centralized. If a spec changes post-handoff, update it in one place. A visual feedback tool lets both designers and developers annotate on the same reference, keeping discussions tied to the design itself.

Walk through the design once

Even with a comprehensive handoff document, schedule a 15-minute walkthrough. Let the developer ask questions while looking at the design together. Record it so anyone joining later can watch.

Stay available for questions

Post-handoff questions are inevitable. Make it easy: a dedicated Slack channel, a daily 15-minute standup, or comments on the design itself through Reviewer. The faster a developer gets an answer, the less likely they are to guess wrong and create rework.

After handoff: visual QA

Once development is complete, the design needs a visual QA pass. Compare the built version against the approved design, element by element. Annotate any discrepancies directly on screenshots using a visual review tool so the developer sees exactly what needs adjusting.

This feedback loop — design, handoff, build, visual QA, fix — is what separates polished products from “close enough” implementations.

Use this checklist on your next project

Copy this design handoff checklist into your project template. Customize it based on your stack and team. The first handoff using the checklist will take a bit longer to prepare, but you’ll reclaim that time immediately through fewer developer questions and less rework.

Ready to streamline the back-and-forth? Try Reviewer to annotate designs, collect approvals, and share visual specs — all without requiring anyone to create an account.