Design Handoff and Developer Communication Questions

Covers the skills and practices required to effectively translate design intent into developer friendly artifacts and to collaborate with engineering teams. Includes explaining design decisions and rationale in terms developers understand, negotiating and accounting for technical constraints, and aligning on trade offs. Encompasses creation and maintenance of design systems, component specifications, interaction definitions, responsive behaviors across breakpoints, spacing and sizing rules, and component variants. Involves producing clear assets and deliverables such as vector and raster exports, annotated prototypes, accessibility notes, naming conventions, logical file and layer organization, and thorough documentation or acceptance criteria. Also covers using tooling and workflows that streamline handoff, for example developer mode in design tools, versioning, integration with component libraries, and participating in review and implementation QA to close the loop with engineering.

HardTechnical

77 practiced

Design a machine-readable JSON schema for UI component specifications intended to be generated from design tool exports and consumed by code generators and Storybook. Define required fields (id, displayName, variants, props, tokens, breakpoints, accessibility metadata) and provide a compact example JSON for a Button component illustrating key fields.

Sample Answer

**Approach — purpose and constraints**

I designed a compact, machine-readable JSON schema focused on export from design tools to drive code generators and Storybook. It includes required fields: id, displayName, variants, props, tokens, breakpoints, and accessibility metadata (a11y). The schema favors clarity for designers and engineers: human-readable names, stable ids, typed props, token references, and responsive breakpoint mapping.

**Required fields (brief)**

- id: stable component identifier (string)- displayName: human label for Storybook/title- variants: array of variant objects (id, displayName, propOverrides, preview)- props: typed prop definitions (name, type, default, options, description)- tokens: references to design tokens (color, spacing, typography)- breakpoints: named viewport widths for responsive variants- accessibility: aria role, keyboard behavior, label rules, contrast notes

**Compact example JSON (Button)**

json

{
  "id": "cmp.button",
  "displayName": "Button",
  "tokens": {
    "color": { "primary": "color.primary.500", "textOnPrimary": "color.neutral.0" },
    "spacing": { "paddingY": "spacing.2", "paddingX": "spacing.3" },
    "radius": "radius.1",
    "typography": "type.button.medium"
  },
  "breakpoints": { "mobile": 375, "tablet": 768, "desktop": 1024 },
  "props": [
    { "name": "variant", "type": "enum", "options": ["primary","secondary","ghost"], "default": "primary", "description": "Visual style" },
    { "name": "size", "type": "enum", "options": ["sm","md","lg"], "default": "md" },
    { "name": "disabled", "type": "boolean", "default": false },
    { "name": "icon", "type": "string", "description": "Optional icon name" }
  ],
  "variants": [
    {
      "id": "primary",
      "displayName": "Primary",
      "propOverrides": { "variant": "primary" },
      "preview": { "label": "Save", "state": "default" }
    },
    {
      "id": "primary/pressed",
      "displayName": "Primary / Pressed",
      "propOverrides": { "variant": "primary" },
      "preview": { "label": "Save", "state": "pressed" }
    }
  ],
  "accessibility": {
    "role": "button",
    "keyboard": ["Enter","Space"],
    "label": { "source": "text", "fallbackProp": "ariaLabel" },
    "contrast": { "minRatio": 4.5, "notes": "Ensure text-on-primary token meets ratio" }
  }
}

This structure maps cleanly to generator inputs (props → component args, tokens → theme), and Storybook stories (variants + breakpoints + previews).

MediumTechnical

59 practiced

An engineer reports that several complex SVG icons you supplied are causing slow initial paint and layout shifts on low-end devices because they're large and inlined. Describe how you would analyze the issue, propose optimizations (visual and technical), evaluate trade-offs between performance and fidelity, and document the final approach for future handoffs.

Sample Answer

**Situation & Analysis**- Reproduce the problem on low-end device/emulation (Chrome DevTools throttling CPU, Lighthouse, WebPageTest). - Capture metrics: First Contentful Paint, Largest Contentful Paint, Total Layout Shift, and CPU profiler during initial load. - Inspect assets: file size, DOM complexity (large inline <svg> with many path commands, filters, masks, gradients, metadata).

**Optimizations — Visual & Technical**- Simplify artwork: remove unnecessary anchors/points, merge shapes, reduce node count in Illustrator/Figma; keep visual fidelity by testing at target sizes. - Remove metadata/comment, precision-reduce coordinates, convert transforms to simpler paths. Use SVGO with a custom config. - Replace heavy filters/gradients with flattened fills or optimized CSS effects when possible. - Switch delivery: move large icons from inline SVG to external SVG sprite (<symbol>) or optimized PNG/WebP for very small sizes; load via <img> or <use> to avoid parse cost. - Defer non-critical icons: lazy-load, load-asynchronously, or progressive enhancement (placeholder low-res or CSS icon until ready). - Consider icon font or SVG icon system for repetitive UI elements to amortize cost.

**Trade-offs**- Raster (PNG/WebP) lowers parse cost but loses scalability and crispness at arbitrary scales; acceptable for fixed small sizes. - External sprite reduces HTML weight and reuses cached asset but prevents per-instance CSS customization unless planned. - Simplification may alter appearance; validate with designers/product on brand fidelity.

**Documentation & Handoff**- Provide before/after assets, SVGO config, build steps, and example implementation snippets (<symbol> sprite, <img src>, lazy-load pattern). - Add accessibility notes: include role/title/aria-hidden where appropriate and ensure semantic fallbacks. - Add performance budget guidance to the design system (max SVG node count/file size per icon, when to rasterize). - Share results (metrics) and a short checklist for future icon creation and review.

EasyTechnical

68 practiced

Write a short template for acceptance criteria that a UI designer would attach to a component handoff ticket. The template should include checks for visuals (colors, spacing), interaction states, accessibility requirements, responsive behavior and edge-case examples for QA to follow.

HardTechnical

70 practiced

Write a thorough specification template for keyboard navigation and focus management for a complex composite component such as a nested data grid with editable cells and row selection. Include ARIA roles, tabindex rules, key bindings, focus traps, expected focus return behavior and sample screen reader announcements for key interactions.

Sample Answer

**Specification: Keyboard Navigation & Focus Management — Nested Data Grid (UI Designer perspective)**

Overview- Purpose: Ensure predictable keyboard navigation, visible focus, and accessible announcements for a nested editable data grid with row selection and cell editing.- Audience: designers, developers, QA, a11y testers.

Roles & Semantics- Outer container: role="grid" aria-label="Orders table"- Rows: role="row"- Cells: role="gridcell" (editable cells add aria-readonly="false" when editable)- Row selection checkbox: role="gridcell" contains input[type=checkbox] with aria-labelledby- Nested child grid: role="rowgroup" or nested role="grid" with aria-label describing relation (e.g., "Order items for order #1234")

Tabindex Rules & Focusable Elements- Tab sequence: only one tabbable element into the grid (tabindex="0" on the active cell or a grid container landmark); all other interactive elements inside use tabindex="-1" and are navigated via arrow keys.- Editable controls (when open): become tabbable (tabindex="0") while editing; revert to tabindex="-1" on edit end.- Visible focus indicator (2px high-contrast outline) for cells and interactive controls.

Key Bindings (primary)- ArrowLeft/Right/Up/Down: move focus between cells within current grid (wrap at edges optionally configurable)- Home / End: move to first/last cell in row- Ctrl+Home / Ctrl+End: move to first/last cell in grid- Enter: when focused on cell → toggle edit mode (focus moves into cell editor). When in editor → commit edit.- Escape: cancel edit, restore previous value, return focus to cell.- Space / Enter on row checkbox: toggle selection; update aria-selected on row.- F2: alternate edit toggle (for users accustomed to spreadsheets)- Tab / Shift+Tab while editing: move between focusable controls inside editor; at editor boundary, commit and move focus to next/prev cell (configurable).

Focus Traps & Modal Editing- If editing opens a modal/dialog: trap focus in dialog (focusable elements get normal tab order), set aria-modal="true".- On dialog close (commit/cancel): return focus to originating cell; announce result.

Expected Focus Return Behavior- End of edit (commit): focus returns to the cell (now showing updated value); announce "Cell updated."- Cancel edit: focus returns to cell; announce "Edit cancelled, value restored."- Row expand/collapse: focus remains on the expander control; if automatic focus moves to nested grid, announce "Expanded — focus on first cell of items."

Screen Reader Announcements (examples)- On focus of a cell: "Column: Quantity, Row: Order 1234, editable, value 10"- On entering edit mode: "Editing Quantity, press Enter to commit, Escape to cancel"- On commit: "Quantity updated to 12"- On selection change: "Row selected. 3 rows selected total."- On navigation to nested grid: "Order items for order 1234, grid, 5 rows"- On validation error: "Error: Quantity must be a positive number. Edit not saved."

Edge cases & notes- Ensure aria-live polite region for non-focus announcements (selection counts, async saves).- Support configurable wrap behavior and keyboard schema in settings.- Provide visual feedback for focused vs editing state and disabled cells.

Testing checklist (hand-off)- Keyboard-only navigation walkthroughs- Screen reader tests (NVDA, JAWS, VoiceOver) across browsers- Focus order verification, focus visible, announcements accuracy- Mobile keyboard and touch behavior mapping

Design tokens- Specify focus outline color, thickness, and spacing in design system; include hover vs focus styles.

This template balances designer-level clarity with developer-implementable rules; include these specs in component documentation and review with a11y engineer before implementation.

HardTechnical

60 practiced

You are tasked with migrating a legacy codebase that uses inline styles and duplicated CSS to a token-driven design system without interrupting releases. Outline an incremental migration plan including steps designers and engineers take, CI changes, monitoring for regressions, communication approach to consumers and how to validate visual parity during the rollout.

Sample Answer

**Overview / goal**I’d run a staged, token-first migration so teams can ship continuously while replacing inline styles and duplicated CSS with semantic design tokens and components.

**Phases (incremental)**1. Audit & tokenize (2–4 weeks) - I’ll inventory colors, spacing, typography from mocks and runtime (browser devtools, CSS coverage). - Define token categories (color, type, spacing, elevation, states) in Figma and a tokens JSON spec.2. Wrapper & adapter (1–2 sprints) - Engineers add a lightweight CSS variables adapter that maps tokens to :root CSS vars; add a JS/SCSS adapter for legacy inline style consumption. - Designers publish token documentation and usage examples in Figma components.3. Component migration (iterative) - Prioritize high-impact UI surface (headers, buttons, forms). Replace implementations with token-backed components while keeping legacy class names shims for compatibility.4. Cleanup & hard switch - Gradually remove duplication and inline fallbacks, deprecate legacy tokens.

**Engineers’ tasks**- Implement token system, CSS vars, and adapter layer.- Create token-backed component library with accessibility tests.- Add feature flags for new vs legacy styles.

**CI changes**- Add token linter and style regression snapshot tests to CI.- Run visual regression tests on PRs (per-component and page-level).- Fail CI if token linter or accessibility checks fail.

**Monitoring & regression detection**- Automated visual diffs (Percy/Chromatic) per PR and nightly full-suite runs.- Metrics: UI error/visual bug rate, user click funnels, and session replays for anomalies.- Rollback plan via feature flags and canary deploys.

**Communication to consumers**- Public deprecation roadmap, changelog, and migration guides.- Beta opt-in channel for early adopters with feedback loop.- Regular design-review syncs and a migration FAQ.

**Validating visual parity**- Define acceptance criteria per component (pixel-tolerance, typography, color contrast).- Use automated visual regression plus manual QA across breakpoints and devices.- Designers run side-by-side Figma-to-implementation checks and produce annotated diffs; sign-off required before removing legacy code.

I’ll pair with engineers daily during the first migrations and collect measurable checkpoints every sprint to keep releases uninterrupted and confidence high.

Unlock Full Question Bank

Get access to hundreds of Design Handoff and Developer Communication interview questions and detailed answers.

Join thousands of developers preparing for their dream job.