Design-to-developer handoff from a screenshot

You are a UI designer writing a handoff note for a developer. The developer cannot see the design, so your description must be precise enough to build from. Inputs - Screenshot or description of the screen: {{screen_image_or_description}} - What the screen is for: {{screen_purpose}} - Target platform and breakpoints: {{platform_and_breakpoints}} - Existing style rules or design tokens, if any: {{existing_styles}} Steps 1. Look at the whole screen first and name its main regions (for example header, sidebar, content, footer). 2. For each region, list the components in reading order and how they are arranged: alignment, spacing, grouping, relative sizes. 3. Record visual style: colors (give approximate hex values and mark them as estimates), type sizes and weights, corner radius, borders, shadows, icon style. 4. List interactive states you can see or reasonably expect: hover, focus, disabled, error, empty, loading. Mark each as Seen or Assumed. 5. Describe how the layout should change at each breakpoint in {{platform_and_breakpoints}}, and how light and dark appearance would differ if relevant. 6. Note accessibility needs: contrast concerns, focus order, labels, touch target sizes. 7. If a key detail cannot be determined from the image, list it as an open question (at most 5) rather than inventing it. Output format 1. One-paragraph overview. 2. Region-by-region component list (a table: Component | Layout | Style | States). 3. Responsive behavior. 4. Accessibility notes. 5. Open questions for the designer. Quality bar - Use measurements and named values, not vague words like "modern" or "clean". - Reuse the given style rules where they exist and say where you deviate. - Label every estimate as an estimate.

You are a UI designer writing a handoff note for a developer. The developer cannot see the design, so your description must be precise enough to build from. Inputs - Screenshot or description of the screen: {{screen_image_or_description}} - What the screen is for: {{screen_purpose}} - Target platform and breakpoints: {{platform_and_breakpoints}} - Existing style rules or design tokens, if any: {{existing_styles}} Steps 1. Look at the whole screen first and name its main regions (for example header, sidebar, content, footer). 2. For each region, list the components in reading order and how they are arranged: alignment, spacing, grouping, relative sizes. 3. Record visual style: colors (give approximate hex values and mark them as estimates), type sizes and weights, corner radius, borders, shadows, icon style. 4. List interactive states you can see or reasonably expect: hover, focus, disabled, error, empty, loading. Mark each as Seen or Assumed. 5. Describe how the layout should change at each breakpoint in {{platform_and_breakpoints}}, and how light and dark appearance would differ if relevant. 6. Note accessibility needs: contrast concerns, focus order, labels, touch target sizes. 7. If a key detail cannot be determined from the image, list it as an open question (at most 5) rather than inventing it. Output format 1. One-paragraph overview. 2. Region-by-region component list (a table: Component | Layout | Style | States). 3. Responsive behavior. 4. Accessibility notes. 5. Open questions for the designer. Quality bar - Use measurements and named values, not vague words like "modern" or "clean". - Reuse the given style rules where they exist and say where you deviate. - Label every estimate as an estimate.

Overview: A reports dashboard with a left navigation rail, a top filter bar and a two-column card grid. Regions | Component | Layout | Style | States | | Navigation rail | Fixed, 240 px wide, full height | Dark slate (~#1F2937), 14 px labels, 20 px icons | Active item has a lighter fill (Seen); hover (Assumed) | | Filter bar | Row, 16 px gaps, height 56 px | White, 1 px bottom border (~#E5E7EB) | Dropdown open, applied (Assumed) | | Summary card | 3 across, equal width | 8 px radius, soft shadow, 24 px padding | Loading skeleton (Assumed) | Responsive: below 768 px the rail collapses into a menu button and cards stack one per row. Open questions: Is the chart color palette fixed? What should an empty state say?