Design to Development Handoff

Overview

Bridge the gap between design and development with systematic handoffs that prevent miscommunication, missing assets, and implementation guesswork.

Core principle: Clear handoff documentation eliminates 80% of design-dev back-and-forth.

When to Use

Use when:

• Designs complete, ready for implementation
• Developer needs design specs
• Handoff causing confusion/delays
• Missing design details during implementation
• Responsive behavior unclear
• Component variations not documented

The Handoff Checklist

Essential Deliverables

1. Design Tokens

/* Colors */
--primary: #3B82F6;
--secondary: #10B981;
--background: #FFFFFF;
--text: #1F2937;

/* Typography */
--font-heading: 'Inter', sans-serif;
--font-body: 'Inter', sans-serif;
--text-xl: 20px / 28px; /* size / line-height */
--text-lg: 18px / 26px;
--text-base: 16px / 24px;

/* Spacing */
--space-xs: 4px;
--space-sm: 8px;
--space-md: 16px;
--space-lg: 24px;
--space-xl: 32px;

/* Borders */
--radius-sm: 4px;
--radius-md: 8px;
--radius-lg: 12px;

2. Component Specs

• Dimensions (width, height, padding, margins)
• States (default, hover, active, disabled, loading)
• Variants (primary, secondary, outline, ghost)
• Typography styles
• Color usage
• Border radius, shadows
• Animations/transitions

3. Responsive Breakpoints

Mobile: 320px - 767px
Tablet: 768px - 1023px
Desktop: 1024px+

Specify behavior at each breakpoint:
- Layout changes
- Typography scaling
- Spacing adjustments
- Component reflow

4. Assets

• Icons (SVG format)
• Images (WebP with fallbacks)
• Logos (multiple sizes)
• Illustrations
• Properly named and organized

Component Specification Template

## Button Component

### Variants
- **Primary**: Default action button
- **Secondary**: Less prominent actions
- **Outline**: Tertiary actions
- **Ghost**: Minimal visual weight

### States
- **Default**: Base appearance
- **Hover**: Background darkens 10%, cursor pointer
- **Active**: Background darkens 20%
- **Disabled**: 50% opacity, cursor not-allowed
- **Loading**: Show spinner, disable interaction

### Specifications
**Primary variant:**
- Background: var(--primary) #3B82F6
- Text: White (#FFFFFF)
- Padding: 12px 24px
- Border radius: 8px
- Font: 16px / 24px, Medium (500)
- Hover: Background #2563EB
- Shadow: 0 1px 3px rgba(0,0,0,0.1)

**Sizes:**
- Small: 8px 16px, 14px text
- Medium: 12px 24px, 16px text (default)
- Large: 16px 32px, 18px text

### Usage
- Primary CTA: Use Primary variant
- Secondary actions: Use Secondary variant
- Destructive actions: Use Destructive variant (red)

### Examples
[Include screenshots of each variant and state]

Asset Export Guidelines

Icons

Format:

• SVG (vector, scalable)
• 24x24px artboard
• Outlined (not filled) unless intentional
• 2px stroke width
• Black (#000000)

Naming:

icon-name.svg
icon-name-filled.svg (if filled variant)

Examples:
user.svg
user-filled.svg
heart.svg
heart-filled.svg

Images

Export multiple resolutions:

image.webp (modern browsers)
image@1x.png (fallback, standard DPI)
image@2x.png (retina)
image@3x.png (high DPI)

Optimization:

• Compress with TinyPNG or ImageOptim
• Target <200KB per image
• Use WebP (80% smaller than PNG)

Logos

Variations needed:

logo.svg (primary)
logo-light.svg (dark backgrounds)
logo-dark.svg (light backgrounds)
logo-icon.svg (icon only, no text)

Sizes for web:

• Header: 32px height
• Footer: 24px height
• Favicon: 32x32, 16x16

Design System Handoff

shadcn/ui Integration

If using shadcn/ui:

1. Map designs to shadcn components
2. Document custom variants
3. Specify theme colors
4. Note any component extensions

Example mapping:

Design → Implementation

Primary Button → <Button variant="default">
Secondary Button → <Button variant="outline">
Card → <Card>
Input → <Input>
Dialog → <Dialog>

Custom: Success Button → <Button variant="success"> (new variant needed)

CSS Variables for Theming

/* Light theme (default) */
:root {
  --background: 0 0% 100%;
  --foreground: 222.2 84% 4.9%;
  --primary: 221.2 83.2% 53.3%;
  /* ... */
}

/* Dark theme */
.dark {
  --background: 222.2 84% 4.9%;
  --foreground: 210 40% 98%;
  --primary: 217.2 91.2% 59.8%;
  /* ... */
}

Developer Handoff Meeting

Agenda (15-30 min):

1. Walkthrough (10 min)

   • Show designs
   • Explain user flows
   • Highlight interactions

2. Technical questions (10 min)

   • Clarify responsive behavior
   • Discuss edge cases
   • Confirm component mapping

3. Deliverables check (5 min)

   • Confirm all assets exported
   • Verify specs documented
   • Access to design files

4. Timeline (5 min)

   • Implementation estimate
   • Review checkpoints
   • Launch date

Common Handoff Failures

Handoff Documentation Template

# [Feature] Design Handoff

## Overview
[Brief description of feature and user value]

## User Flows
1. [Step-by-step user journey]

## Components

### Component 1: [Name]
- Variants: [list]
- States: [list]
- Specs: [dimensions, colors, typography]
- Responsive: [behavior per breakpoint]
- Assets: [required images/icons]

### Component 2: [Name]
[Same structure]

## Design Tokens
[CSS variables or token file]

## Assets
- Icons: [location]
- Images: [location]
- Logos: [location]

## Responsive Breakpoints
- Mobile (320-767px): [behavior]
- Tablet (768-1023px): [behavior]
- Desktop (1024px+): [behavior]

## Interactions
- Hover effects: [describe]
- Click/tap feedback: [describe]
- Animations: [timing, easing]
- Transitions: [duration]

## Notes
[Any special considerations, edge cases, accessibility requirements]

Design File Organization

Figma/Sketch naming:

Page: Feature Name
├─ 1. Mobile (375px)
├─ 2. Tablet (768px)
├─ 3. Desktop (1440px)
├─ Components
│  ├─ Button variants
│  ├─ Form elements
│  └─ Cards
└─ Specs
   └─ Measurements & tokens

Quick Reference

Before handoff:

• All states designed
• Responsive behavior specified
• Design tokens documented
• Assets exported and organized
• Component specs written
• Edge cases considered
• Accessibility notes included

During handoff:

• Walkthrough completed
• Questions answered
• Developer has file access
• Timeline agreed

After handoff:

• Available for questions
• Review implementation checkpoints
• Sign off on final implementation

Smooth handoffs prevent wasted development time and maintain design quality in implementation.