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.

HardSystem Design

75 practiced

You are leading the handoff for a design system intended to scale across multiple product teams and platforms (web, iOS, Android). Describe the architecture of documentation, files, tokens, and processes you'd establish so designers and developers can collaborate, manage platform-specific divergence, and scale governance.

MediumTechnical

109 practiced

Design a versioning and branching workflow for design files that mirrors engineering Git workflows. Explain how to handle major releases, experimental features, and hotfixes in Figma (or your tool of choice) so developers can trace implementation back to a design version or branch.

Sample Answer

**Approach / Goals**Create a Figma workflow that mirrors Git (main, feature, release, hotfix) so designers and devs can trace implementation to a concrete design version or branch.

**Branching & naming**- main (production design system / canonical files)- feature/ABC-123-short-desc — for new features (branch file or Figma Branch)- release/vX.Y — created from main when preparing a release- hotfix/ABC-999 — branch from release/vX.Y for urgent fixes- experiment/UX-hypothesis — isolated exploratory file or branch

Use Jira ticket IDs in names: feature/ABC-123-login-flow.

**Process**- Branch or duplicate the main file to start work; keep components linked to the shared library where possible.- Work in the feature branch file/page. Add a cover frame with status, owner, and Jira ID.- When ready, create a Design Review (like a PR): create a Figma Branch Merge Request (or PR in a team doc) and tag reviewers.- On merge: publish component changes to the Design System library, then merge branch into main and create a Figma Version named release/vX.Y with changelog and linked Jira/Git tags.

**Releases**- Freeze main for release; QA design vs dev build.- Create release/vX.Y snapshot in Figma. In release notes include Figma version URL and component version numbers.- Developers reference the release snapshot URL in their Git commit/PR and Jira task.

**Hotfixes**- Branch from release/vX.Y, apply minimal changes, run quick review, publish, and create hotfix version (hotfix/vX.Y.Z). Link hotfix version in the associated Git commit and Jira.

**Experimental work**- Use experiment/* files or a dedicated “Lab” page. Mark prototypes as “experimental” and include acceptance criteria. If validated, promote by merging into a feature branch and syncing components to the library.

**Traceability & Handoff**- Always include a canonical Figma version URL and version name in the Jira ticket and in the dev PR description.- Publish component changes with semantic versions and include change notes.- Attach exported specs (token values, accessibility notes) to the Jira ticket or use plugin-generated spec links (e.g., Inspect URLs).

**Best practices**- Keep component library stable; prefer tokens and variants.- Small, frequent merges and clear changelogs.- Enforce naming conventions and require a Figma link in PR templates so devs can trace design ↔ code.

EasyTechnical

59 practiced

Define what an acceptance criteria document for a UI component should contain. Provide a concise checklist a designer could attach to a component delivery that enables QA and engineers to test whether implementation matches design intent.

HardTechnical

92 practiced

Create a detailed template for documenting complex interaction sequences (micro-interactions) so engineers can implement them precisely. The template should cover triggers, state diagrams, timing/easing, cancelation and interruption behavior, and accessibility fallbacks.

Sample Answer

**Purpose & Summary**- One-sentence description of the micro-interaction, UX goal, and success metric (e.g., "Inline form validation: communicate field errors instantly; reduce submission errors by 20%").

**Scope & Context**- Screen/component where it occurs- Pre-conditions (when it is available)- Related interactions that must not conflict

**Triggers**- Primary trigger(s): user action or system event (tap, hover, focus, API response)- Trigger requirements: debounce, minimum dwell, device constraints- Example: "On blur of email input OR on 500ms of idle typing."

**States & State Diagram**- List states with concise definitions: Idle, Pending, Success, Error, Canceled- State transitions (source → event → target), include guard conditions and timeouts- ASCII state diagram reference or attach SVG/PNG- Example transition: "Idle → Typing (on input) → Pending (on 500ms no input) → Success/Error (on API response)"

**Visual & Motion Spec (Timing/Easing)**- For each transition: property (opacity, translateY, scale), duration (ms), easing (cubic-bezier or named)- Choreography order and delays (stagger values)- Motion purpose note (focus, continuity, affordance)- Example: "Error shake: translateX ±8px, duration 360ms, easing cubic-bezier(0.36,0.07,0.19,0.97)"

**Cancelation & Interruption Behavior**- What cancels current animation (new trigger, navigation, modal closed)- Graceful interruption rules: snap-to-end vs. reverse vs. fade-out- State reconciliation after interruption (recompute from latest data)- Example: "If user types during Pending, cancel API error animation and re-enter Pending."

**Accessibility Fallbacks**- Reduced motion: simplified/instant state changes; no decorative motion- Screen reader announcements: role, live-region text for each state change- Keyboard-only behavior: focus management, tabbable elements, visible focus styles- Contrast and timing adjustments for cognitive accessibility- Example: "On Error, set aria-live='assertive' with short message; for reduced-motion, skip shake and show static red outline."

**Implementation Notes**- Tokens: reference design system variables (e.g., --duration-short = 200ms)- Platform differences: web (CSS + prefers-reduced-motion), iOS/Android Lottie or native timings- Test cases: list unit/integration checks and accessibility audit steps- Assets: attach motion spec files (Figma prototype, JSON for Lottie)

**Acceptance Criteria**- Observable behaviors, performance constraints (max 120ms input-to-feedback), and accessibility checks that must pass before sign-off

Example micro-interaction attachments: state SVG, timing table, ARIA strings, and code-ready tokens.

HardSystem Design

66 practiced

Design an implementation QA process that allows designers to verify production UIs against design intent at scale. Describe manual and automated checks, gating criteria, roles, tools (e.g., visual-diffing, Storybook snapshots), and the process for triaging and closing mismatches.

Sample Answer

**Goal & constraints**Ensure production UIs match design intent at scale: visuals, spacing, copy, responsive states, and accessibility. Fast feedback in CI, clear owner for fixes, low false positives.

**High-level flow**1. Designer authors specs (Figma tokens, components, variants) + Storybook stories.2. Developer implements; CI runs automated checks → failed checks block merge if gating rules apply.3. Designer reviews triaged mismatches in dashboard; outcomes: Fix, Accept (with note), or Defer.

**Automated checks**- Visual regression: Storybook + Chromatic or Percy to capture component snapshots across viewports; pixel-tolerant diffs with thresholds and ignore regions for dynamic content.- End-to-end visual smoke: Puppeteer / Playwright snapshots of canonical pages, compare to golden images.- Accessibility: axe-core audits for contrast, ARIA.- Spec assertion: compare CSS tokens and computed styles against design token export (from Figma plugin) for color, type, spacing.- Linting: Storybook snapshot tests in Jest for component props/combinations.

**Manual checks**- Designer review board (weekly): inspect flagged diffs in visual review tool with overlay toggles (design vs prod), checklist for spacing, alignment, copy, motion.- Exploratory sessions for new flows and responsive breakpoints.- Accessibility manual spot checks (keyboard, screen reader).

**Gating criteria**- Block merge if visual diff > threshold on core components or accessibility failures.- Non-blocking for small cosmetic diffs on low-risk pages; create ticket with severity.

**Roles & responsibilities**- Designer: author specs, accept/reject diffs, prioritize fixes, update tokens.- Dev: fix implementation, add tests, update stories.- QA/DevOps: maintain CI, thresholds, tooling.- Product owner: set risk levels for gating.

**Triage & closure process**- Automated tool creates issue with screenshots, diff, metadata (viewport, component, commit).- Triage: Designer reviews within SLAs (24–48h). If fix needed, tag dev and set priority; dev links PR to issue.- After fix, CI reruns snapshots; designer verifies and closes issue; if intentional deviation, designer documents decision and updates design source or token.

**Metrics & feedback**- Track time-to-detect, time-to-fix, false-positive rate, and percent of builds blocked. Iterate thresholds and improve Storybook coverage.

This process scales by focusing automation on components/pages with high reuse and routing manual attention to ambiguous cases, keeping designers in the decision loop while minimizing noisy alerts.

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.