Screenshot prompts: separate pixels from behavior

Last updated: 5 Oct 202611 min read

tutorial

A screenshot-to-code prompt should label what is visible, what is inferred, and what remains unknown. Pixel position, color, and apparent grouping are observations. Element role, reading order, keyboard behavior, hidden states, and data source are not visible proof. Map each visible control to its intended semantic element and action, then require confirmation where the image cannot resolve an ambiguity. Use the screen as a comparison target after the implementation renders; do not treat a close visual match as evidence that controls work. Preserve the product's existing type scale and spacing rules unless a real design requirement calls for a change.

Operational case

The Dispatch Queue screenshot shows a pill labeled Held, six visible rows, and a small number beside the heading. It does not reveal whether Held is a button, a link, or a tab; whether the six rows are all matching records or only one page; or how keyboard focus is drawn. The prompt records those unknowns. The selected filter becomes a labeled native control in the implementation, with a visible focus indicator and a count tied to the current result. A screenshot comparison checks spacing and alignment. A separate interaction check confirms that selecting All restores 47 rows in the fictional fixture.

Visible evidence: Held label, six rows, heading count, card spacing.
Unknown: role, pagination, focus treatment, fetch behavior.
Semantic contract: named filter control; heading and list in reading order.
Behavior check: Held -> 6 visible; All -> 47 visible.
Review: compare rendered image, then test keyboard and state changes.

Performance and operating cost

Rendering and image comparison cost roughly O(P) work for P pixels per captured state, while interaction checks scale with the number of tested transitions. A single screenshot is cheap but covers one width and one state. Keep a small, risk-based set of captures instead of multiplying every state by every browser and width without a reason. Store the observation and the chosen assumption together so reviewers can distinguish an intentional design decision from a guess.

Common Mistakes

Do not infer an element's semantics from its color or shape.
Do not approve a button because it looks correct while it cannot be reached by keyboard.
Do not crop away the state or viewport that would reveal overflow.

Connected lessons

prompt engineering

ui engineering