developer-handoff

name	developer-handoff
description	Hand product design to engineering with complete flows, states, responsive and accessibility behavior, component intent, assets, content, constraints, and explicit open decisions while preserving implementation ownership.

Developer Handoff

Use when approved product design is ready to be implemented by frontend or other engineering specialists.

Procedure

1. Start from the accepted product outcome and requirements so the handoff distinguishes mandatory product behavior from visual/design preference and exploratory concepts.
2. Provide the complete flow, not isolated polished screens. Include entry points, success, empty, loading, validation, permission, failure, interruption, recovery, and relevant destructive/confirmation behavior.
3. Specify interaction behavior: control intent, navigation, transitions, selection/editing rules, keyboard/focus expectations, input methods, cancellation, persistence, and other user-observable details that engineering should not invent.
4. Specify responsive/adaptive behavior by principles and critical breakpoints/states where layout meaning changes. Avoid demanding pixel-perfect screenshots that do not explain what should happen between sizes.
5. Identify design-system components/tokens/patterns that should be used when semantically appropriate. Flag new component behavior separately so Design Systems or engineering can decide the reusable implementation boundary.
6. Provide accessibility behavior including semantics, accessible names/content intent, focus order/management, keyboard alternatives, announcements/status behavior, reduced motion, contrast/adaptation expectations, and known review risks.
7. Provide production-ready assets or exact source/export requirements with naming, dimensions/ratios, formats, states, and licensing/attribution constraints where relevant.
8. Provide final or clearly marked placeholder content. Route unresolved product copy to the appropriate content/copy specialist instead of letting engineering invent customer-facing language by accident.
9. Call out data/API assumptions that affect the experience, such as pagination, permissions, latency, optimistic behavior, upload limits, or unavailable fields, but do not prescribe backend/frontend architecture beyond the accepted contract.