UI/UX Design Working With Developers

The gap between a polished design mockup and a finished product is where most design quality gets lost. A beautiful Figma file means nothing if the developer receiving it cannot understand the design intent, measure spacing correctly, or know which states were designed for every component. This page teaches designers exactly how to prepare and deliver designs to developers in a way that results in faithful, high-quality implementation.

Understanding the Designer-Developer Relationship

The relationship between designers and developers works best when both sides understand what the other needs. Many design-development handoff problems come from assumptions, not bad intentions.

WHAT DEVELOPERS NEED FROM DESIGNERS:

Specific measurements:
  → Exact pixel values for spacing, padding, margins
  → Exact font sizes, weights, line heights
  → Exact color values in the format the codebase uses (HEX, RGB, HSL)
  → Border radius values, shadow values

All states of every component:
  → Default, hover, active, disabled, focus, loading, error, success
  → Empty states, skeleton states
  → Mobile and desktop versions of every component

Behavior and interaction specifications:
  → How animations work (duration, easing, trigger)
  → What happens when a user clicks, hovers, focuses
  → Flow decisions: where does clicking X go? What does Y do?

Asset files:
  → Icons in SVG format (optimized, viewBox set correctly)
  → Images in appropriate formats and resolutions
  → Logos as vector files

Clear hierarchy and naming:
  → Layers and components named logically in the design file
  → Organized frame structure that matches pages/screens

WHAT DEVELOPERS DO NOT WANT:
  ✗ "Make it look more modern" (not measurable)
  ✗ Design files with unlabeled, scattered artboards
  ✗ Missing states for interactive components
  ✗ Designs that ignore technical constraints
  ✗ Changes after development has started (without clear specification)

Preparing Your Design File for Handoff

Naming Conventions

LAYER AND COMPONENT NAMING:

BAD naming (common in draft files):
  Frame 47
  Rectangle
  Rectangle copy 3
  Group 12
  Button thingy

GOOD naming (ready for handoff):
  /screens/checkout/step-2-payment
  components/button/primary/large/default
  components/button/primary/large/hover
  /icons/navigation/home
  /icons/navigation/search

NAMING CONVENTION RULES:
  ✓ Use lowercase with hyphens (not spaces or camelCase)
  ✓ Group components logically with forward-slash hierarchy
  ✓ Be specific: "button-primary-large-hover" not "button-v3"
  ✓ Name layers by purpose, not appearance:
    "error-message" not "red-text-box"
    "avatar-placeholder" not "gray-circle"

PAGE ORGANIZATION IN FIGMA:
  → Cover (thumbnail for the file)
  → Design System / Components
  → User Flows (flow diagrams)
  → Screens / Pages (organized by section or feature)
  → Archive (old versions, do not delete yet)

Component States

Every interactive component must have every state designed before handoff. Developers cannot build what was not designed. When states are missing, developers guess — and guesses almost never match the design intent.

REQUIRED STATES FOR COMMON COMPONENTS:

BUTTON:
  ✓ Default
  ✓ Hover
  ✓ Pressed/Active (slightly smaller, darker)
  ✓ Disabled (greyed out)
  ✓ Loading (spinner inside)
  ✓ Success (brief — checkmark before returning to default)

INPUT FIELD:
  ✓ Default (empty, no interaction)
  ✓ Placeholder text visible
  ✓ Focused (border highlighted, cursor visible)
  ✓ Filled (user has typed something)
  ✓ Error (red border, error message below)
  ✓ Disabled (greyed out, not editable)
  ✓ Read-only (shows data but user cannot edit)

TOGGLE/SWITCH:
  ✓ Off
  ✓ On
  ✓ Disabled-off
  ✓ Disabled-on

CARD (if clickable):
  ✓ Default
  ✓ Hover (elevation increase, slight scale or shadow)
  ✓ Selected (different border or background)
  ✓ Loading (skeleton version)

COMPLETE STATE MATRIX EXAMPLE (Button):
  
                Primary    Secondary    Destructive
  Default:      [✓ design] [✓ design]  [✓ design]
  Hover:        [✓ design] [✓ design]  [✓ design]
  Pressed:      [✓ design] [✓ design]  [✓ design]
  Disabled:     [✓ design] [✓ design]  [✓ design]
  Loading:      [✓ design] [✗ missing] [✗ missing]
  ← Missing states must be designed before handoff

Auto Layout and Real Content

DESIGNING WITH REAL CONSTRAINTS:

USE AUTO LAYOUT IN FIGMA:
  Auto layout means components grow naturally with real content.
  
  Bad (fixed dimensions):
  ┌──────────────────────┐
  │ Button Text          │  ← Fixed width. Long text will overflow.
  └──────────────────────┘

  Good (auto layout):
  ┌─────────────────────────────┐
  │ Much Longer Button Label    │  ← Grows to fit content.
  └─────────────────────────────┘

TEST WITH REAL CONTENT:
  "Lorem ipsum" hides real-world content problems.
  
  Test with:
  → Very short names: "Li" or "Bo" (profile, avatar)
  → Very long names: "Krishnamurthy Venkatasubramanian"
  → Very long text: Product descriptions that wrap 4+ lines
  → Numbers: Large amounts like "₹1,00,00,000.00"
  → Empty: What if there is no content at all?
  → Missing data: What if an optional field is blank?

Design Specifications

Design specifications (specs) are detailed documents or annotations that tell developers exactly how to build each element — measurements, colors, fonts, spacing, behavior, and assets.

Modern Spec Tools

HANDOFF TOOLS:

FIGMA DEV MODE (Figma's built-in handoff):
  → Developer clicks any element and sees:
     - Exact dimensions (width × height)
     - Position on artboard
     - Padding and spacing values
     - Color in HEX, RGB, HSL
     - Font name, size, weight, line height, letter spacing
     - Border radius, shadow values
  → Can copy CSS, Swift, or Android XML code for styles
  → Can export assets (images, icons) directly

ZEPLIN (Dedicated handoff tool):
  → Syncs from Figma or Sketch
  → Organizes screens by section
  → Shows measurements on hover
  → Allows developer comments on specific elements
  → Generates style guide from design tokens automatically

NOTION / CONFLUENCE (For behavioral specs):
  → Written documentation for complex interactions
  → Animation specifications
  → Edge case handling instructions
  → API/data dependencies

STORYBOOK (For component libraries):
  → Developers can see every component with all its states
  → Interactive component playground
  → Connects directly to the component code

Writing a Component Specification

COMPONENT SPEC EXAMPLE:

COMPONENT: Notification Toast
─────────────────────────────────────────

VISUAL SPECS:
  Background:   White #FFFFFF
  Border:       1px solid #E5E7EB (Gray 200)
  Border radius: 8px
  Shadow:       0 4px 12px rgba(0,0,0,0.12)
  Padding:      16px (all sides)
  Width:        360px fixed on desktop; screen-width - 32px on mobile
  Max width:    360px

ICON:
  Size: 20×20px
  Success: #22C55E (Green 500) checkmark icon
  Error:   #EF4444 (Red 500) X icon
  Warning: #F59E0B (Amber 500) ! icon
  Info:    #3B82F6 (Blue 500) i icon

TYPOGRAPHY:
  Title: 14px, font-weight: 600, color: #111827 (Gray 900)
  Body: 14px, font-weight: 400, color: #374151 (Gray 700)
  Line height: 20px for both

BEHAVIOR:
  Entry animation: Slide in from top-right
    Duration: 300ms, ease-out
    Transform: translateY(-16px) → translateY(0)
    Opacity: 0 → 1

  Auto-dismiss: After 4 seconds (default)
    Can be overridden: Error toasts do not auto-dismiss
  
  Exit animation: Fade out
    Duration: 200ms, ease-in
    Opacity: 1 → 0
  
  Manual dismiss: × button in top-right corner
    Touch target: 32×32px
    Icon: 16×16px

  Stacking: Multiple toasts stack with 8px gap
            Maximum 3 toasts visible simultaneously
            Oldest dismisses first when limit reached

  Position:
    Desktop: top-right, 24px from right edge, 80px from top
    Mobile:  top-center, full width minus 16px padding each side

STATES:
  → Success: Green icon + success message text
  → Error: Red icon + error message + optional action link
  → Warning: Amber icon + warning message
  → Info: Blue icon + info message
─────────────────────────────────────────

Communicating Interactions and Animations

Static design files cannot communicate movement. Animation specifications must be written out explicitly or demonstrated in an interactive prototype.

ANIMATION HANDOFF OPTIONS:

1. INTERACTIVE PROTOTYPE (Figma, Framer, Principle):
   Share a clickable prototype that demonstrates the animation.
   Developer watches it, references it while coding.
   
   Best for: Page transitions, modal openings, complex sequences.

2. WRITTEN ANIMATION SPEC:
   Document the animation properties explicitly.
   
   Template:
   Element: [Name]
   Trigger: [User action or system event]
   Property animated: [opacity / transform / color / etc.]
   From: [Starting value]
   To: [Ending value]
   Duration: [Xms]
   Easing: [ease-out / ease-in / ease-in-out / spring]
   Delay: [Xms] (if applicable)
   
   Example:
   Element: Navigation sidebar
   Trigger: User clicks menu icon
   Property: transform: translateX
   From: translateX(-240px)
   To: translateX(0)
   Duration: 280ms
   Easing: ease-out
   
   Overlay:
   Property: opacity
   From: 0
   To: 0.5
   Duration: 280ms (simultaneous with sidebar)

3. LOTTIE FILE:
   For complex illustrative animations.
   Designer exports .json from After Effects.
   Developer imports into app using Lottie library.

4. VIDEO RECORDING:
   Record a screen capturing the prototype animation.
   Send alongside written spec.
   Useful when developer and designer are in different time zones.

Asset Preparation and Export

ASSET EXPORT GUIDE:

ICONS:
  Format: SVG (always)
  Why SVG: Scales perfectly to any size, can be colored via CSS,
           small file size, can be animated
  
  SVG optimization:
  ✓ Remove unnecessary groups and empty layers
  ✓ Merge paths where possible
  ✓ Set viewBox to "0 0 24 24" (standard icon viewbox)
  ✓ Remove fill colors from SVG file (let CSS control color)
  ✗ Never export icons as PNG unless absolutely required

IMAGES:
  Photography:    WebP (modern, best compression) or JPG
  Screenshots:    PNG (lossless, preserves text clarity)
  Illustrations:  SVG (if vector) or PNG (if complex)
  
  Export at multiple resolutions for responsive images:
  image@1x.webp  → For standard screens
  image@2x.webp  → For retina/high-DPI screens
  image@3x.webp  → For very high DPI (some iPhones)

LOGOS:
  Format: SVG (mandatory for logos)
  Export: Full logo + symbol-only version + wordmark-only
  Versions: Dark background version + Light background version

NAMING CONVENTION FOR EXPORTS:
  icon-arrow-right.svg
  icon-arrow-left.svg
  image-hero-banner@1x.webp
  image-hero-banner@2x.webp
  logo-full-dark.svg
  logo-full-light.svg
  logo-symbol.svg

Edge Cases and Specifications

Edge cases are situations the design did not explicitly account for. When developers build something and hit an edge case, they either guess the design intent or stop and ask — both options slow development. Covering edge cases upfront eliminates this friction.

EDGE CASES TO DOCUMENT:

CONTENT LENGTH:
  What happens when:
  → User's name is 1 character? "X"
  → User's name is 60 characters? "Krishnamurthy Venkatasubramanian..."
  → A description is 5 words? 500 words?
  → A number is 0? Negative? Very large (1,000,000)?

MISSING OR EMPTY DATA:
  → User has no profile photo → Show initials avatar? Icon?
  → User has no transactions → Show empty state or zero state?
  → API returns null for a field → Show dash, zero, "N/A", or hide?

ERROR STATES:
  → Network error during a critical action → Banner? Modal? Toast?
  → Server returns unexpected data format → Fallback behavior?
  → Image fails to load → Show broken image icon? Placeholder color?

LOADING STATES:
  → Data takes 5+ seconds → Progress indicator? Timeout message?
  → Partial data loads → Show partial data or wait for all?

PERMISSION STATES:
  → User has read-only role → Which elements are hidden vs greyed?
  → User's subscription has expired → Which features locked?
  → User is logged out and visits a protected page → Redirect?

RESPONSIVE EDGE CASES:
  → Page with a table on a 320px wide screen
  → Long navigation labels on a 375px screen
  → Form in a small iframe or embed context

Design-Developer Communication During Build

HOW TO COLLABORATE DURING DEVELOPMENT:

DESIGN REVIEW SESSION:
  Schedule a 1-hour session after the developer starts building.
  Review: Does the live implementation match the design?
  Discuss: Any constraints or issues discovered during development.
  Adjust: Make design decisions together for edge cases.

COMMENT-BASED ASYNC FEEDBACK:
  Use Figma comments or GitHub PR reviews for async feedback.
  
  Effective comment format:
  "The spacing here should be 24px, not 16px.
   See: [link to spec].
   This matters because the text needs breathing room."
  
  Not helpful:
  "The spacing is wrong."
  "Doesn't match design."

QA CHECKLIST FOR DEVELOPERS:
  Share a design QA checklist alongside the spec:
  □ Font sizes match spec
  □ Colors match HEX values in spec
  □ Spacing matches (use pixel inspector)
  □ All hover states implemented
  □ Focus states visible for keyboard navigation
  □ Error states trigger correctly
  □ Animations match duration and easing specs
  □ Mobile layout matches mobile designs
  □ Touch targets meet 44px minimum

WHEN DEVELOPER SAYS "THAT'S NOT POSSIBLE":
  Step 1: Ask what specifically is constrained.
          (Technology limitation? Time limitation? Complexity?)
  Step 2: Understand the constraint fully before negotiating.
  Step 3: Find an alternative that achieves the same UX goal
          within the technical constraint.
  Step 4: Document the agreed compromise.
  Step 5: If it significantly impacts UX, discuss with PM.

  Remember: "Not possible right now" ≠ "Not possible ever."
  Distinguish between technical impossibility and sprint scope.

Reducing Handoff Friction with Design Systems

HOW DESIGN SYSTEMS IMPROVE HANDOFF:

WITHOUT A DESIGN SYSTEM:
  Every component is custom-built in the design file.
  Developer must measure every element individually.
  Designer must document every measurement.
  → Every new feature requires full documentation.
  → Inconsistencies accumulate over time.

WITH A DESIGN SYSTEM:
  Developer uses the component library in code.
  Designer references the component in Figma.
  Tokens (colors, spacing, typography) are shared.
  → Handoff becomes: "Use Button/Primary/Large at this position."
  → Developer does not need to measure — they use the token.
  → Changes to a component propagate everywhere automatically.

EXAMPLE:
  Without system:
  "Button: #3B82F6, 16px padding top/bottom, 24px left/right,
   8px border radius, 16px font, 600 weight, white text,
   on hover: #2563EB, on click: scale(0.97)..."
  
  With system:
  "Use "
  Everything else is already defined in the shared system.

Key Points

• Developers need exact values — pixel measurements, HEX colors, font weights, animation durations — not vague descriptions like "make it look polished."
• Every interactive component must have every state designed before handoff: default, hover, active, disabled, loading, error, and success.
• Use Auto Layout in Figma so components stretch naturally with real content — fixed-width designs break with real-world data.
• Modern handoff tools like Figma Dev Mode and Zeplin let developers inspect measurements and copy CSS values directly from the design file.
• Document animations with explicit specs: property, from value, to value, duration in ms, and easing type.
• Export icons as optimized SVG files with no hardcoded fill colors. Export images at 1x, 2x, and 3x for responsive resolution support.
• Document edge cases before development starts: empty states, missing data, very long content, permission states, and error states.
• Schedule a design review session after the developer starts building to catch implementation deviations early, when fixes are cheap.
• Design systems dramatically reduce handoff work — a shared component library replaces detailed per-element documentation for established components.