Build with AI
Screenshot to UI: turn a visual reference into a working screen
Use screenshots to infer layout and hierarchy while keeping behavior, components and responsive rules explicit. Includes a reference-to-code prompt.
A screenshot is evidence of one state
To turn a screenshot into a working UI, first separate what you can see from what you need to decide. The image shows one layout, content set and viewport. It may not reveal loading behavior, keyboard interaction, responsive breakpoints or the component model behind it.
Write an observation list before asking for code. For an illustrative project dashboard, you might observe a left navigation rail, a page heading, filters and a list. Do not infer that the list is virtualized, that filters persist or that a particular framework produced the screen.
Choose the degree of fidelity
Decide whether the task is to reproduce your own approved design or adapt selected ideas from a reference. Those are different briefs. In the first case, verify the source assets and measurements you can access. In the second, explain the visual decisions worth carrying into your product.
Keep branding, copy and imagery appropriate to the project. A reference is not a license to reuse another company’s assets. If the screenshot is your own earlier version, identify which parts remain valid and which behavior has changed.
Map visible patterns to existing components
Ask the agent to inspect the project before creating a parallel component library. A reference button may map to the app’s existing button with a different size, while a list may need a new composition of established elements. Use real content to test the mapping.
Save the screenshot in a Taste collection and annotate the intended roles: hierarchy, density or the treatment of a selected item. Add another reference only if it resolves a specific uncertainty. Conflicting images need an explicit decision rather than an averaged style.
Brief the missing states
This prompt makes the limits of the image part of the work instead of hiding them.
Use this screenshot as a visual reference for our project list. First describe observable layout and hierarchy, then list behaviors the image cannot establish. Inspect our existing components and my Taste notes. Reuse the component system and our own copy/assets. Implement the agreed layout with realistic long content. Propose narrow-screen behavior and include loading, empty, error and selected states. Do not claim pixel-perfect fidelity without a rendered comparison at the reference viewport.
Compare the implementation at the same conditions
Open the result at the screenshot’s viewport with comparable content. Review spacing, alignment and information order before judging differences caused by another font or a longer title. Then deliberately change the viewport and content to test the rules behind the image.
A successful result remains usable outside the one captured state. Keep screenshots of the implemented states and the decisions that explain intentional differences. That record is more useful for later revisions than a vague instruction to stay close to the original.