# Design-to-Code Handoff Checklist

Use this before implementation starts. The goal is to reduce guessing between design and engineering.

## 1. Product Intent

- [ ] The screen has a clear user goal.
- [ ] The primary action is named.
- [ ] Secondary actions are ranked.
- [ ] Required business rules are documented.
- [ ] Non-goals and deferred behavior are explicit.

## 2. Component Inventory

- [ ] Each repeated UI pattern maps to an existing component or a proposed new one.
- [ ] New components have names that match the design system language.
- [ ] Component variants are named by behavior, not appearance only.
- [ ] Slot/content flexibility is clear.
- [ ] Interaction ownership is clear: component, parent view, or route.

## 3. States

- [ ] Default state.
- [ ] Hover state.
- [ ] Focus-visible state.
- [ ] Disabled state.
- [ ] Loading state.
- [ ] Empty state.
- [ ] Error state.
- [ ] Success or confirmation state.
- [ ] Long-content state.
- [ ] Permission or unavailable state.

## 4. Responsive Behavior

- [ ] Mobile layout is designed, not assumed.
- [ ] Tablet behavior is defined for dense interfaces.
- [ ] Desktop max width and alignment are specified.
- [ ] Fixed-format elements have stable aspect ratios or dimensions.
- [ ] Text wrapping is checked for the longest realistic strings.
- [ ] Navigation and filters remain usable on narrow screens.

## 5. Tokens And Styling

- [ ] Colors use semantic tokens where possible.
- [ ] Type scale and weights match existing styles.
- [ ] Spacing uses system values.
- [ ] Border radius matches the local UI language.
- [ ] Shadows, borders, and dividers are intentionally chosen.
- [ ] Dark mode implications are captured if applicable.

## 6. Data And Content

- [ ] Data fields are listed.
- [ ] Required and optional fields are marked.
- [ ] Example content includes realistic lengths.
- [ ] Empty copy is written.
- [ ] Error messages are written.
- [ ] Date, currency, and locale formats are defined.

## 7. Accessibility

- [ ] Headings follow a logical document outline.
- [ ] Interactive controls have accessible names.
- [ ] Keyboard order matches visual order.
- [ ] Color contrast is checked.
- [ ] Motion has a reduced-motion fallback when needed.
- [ ] Icon-only controls have labels or tooltips.

## 8. Engineering Notes

- [ ] API dependencies are named.
- [ ] Feature flags are identified.
- [ ] Analytics events are specified.
- [ ] Testing expectations are clear.
- [ ] Known tradeoffs are documented.
- [ ] Acceptance criteria are written in observable terms.

