Verified against Claude · 2026-08-08
Get a structured diagnostic review from a screenshot, not just a description of it
A vision prompt for reviewing a UI screenshot, error screen, or mockup that forces a severity-ranked list of specific, locatable issues instead of a general paragraph, with an explicit ban on fabricated precise measurements and a closing call on the best fix for the effort.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Look at the image below and produce a structured diagnostic review, not a general description of what's shown — I need specific, actionable findings, each tied to where in the image it actually is.
WHAT THIS IMAGE IS
A screenshot of the checkout page on our mobile web store, captured on an iPhone 14 at default zoom, mid-way through the payment step.
WHAT TO REVIEW IT FOR
Accessibility (contrast, tap-target size, readable error states) and clarity of the checkout flow specifically — not general visual polish or brand aesthetics.
AUDIENCE AND PLATFORM
Mobile web, general consumer audience, including users on older or budget Android devices with smaller screens than shown here.
FOR EACH ISSUE FOUND
1. A short label for the issue.
2. Where it is in the image, described precisely enough that someone looking at the same screenshot could find it in a few seconds — a screen region (top-left, the second row of the table, the button next to the search field), not a vague "somewhere in the interface."
3. Why it's an issue, stated concretely — not "this looks off," but what specifically is wrong (contrast ratio looks too low against this background, this label doesn't match the action it triggers, this error message doesn't say what the user should do next).
4. A severity: blocking, significant, or minor — blocking means a user cannot complete a normal task because of this; significant means they can, but with real friction or confusion; minor means it's worth fixing but doesn't meaningfully impede anyone.
ORDER
List blocking issues first, then significant, then minor — a reader triaging a fix list should see what actually matters first, not encounter it in whatever order your eye happened to scan the image.
WHAT NOT TO DO
- Do not pad the list with a restatement of something already covered by an earlier, more severe finding in the same area — if a whole section is broken, don't also separately list five small things wrong within it; note the section-level issue once, at its real severity.
- Do not invent a specific pixel value, hex color, or exact measurement you cannot actually verify from the image — describe what you can see ("the text looks noticeably lower-contrast than the button label next to it") rather than a precise-sounding number that implies a measurement tool you don't have.
- If an issue is purely subjective visual taste with no accessibility or usability basis, leave it out entirely rather than including it as a 'minor' finding.
IF THE IMAGE IS UNCLEAR OR PARTIALLY CUT OFF
Say so explicitly, and note which specific area is unreadable rather than skipping it silently or guessing at what's probably there based on similar interfaces you've seen.
AFTER THE LIST
In one or two sentences, name the single fix that would resolve the most real user friction for the least effort — not necessarily the most severe issue on its own, but the best ratio of impact to effort, if that differs from simply the top of the severity list.
IMAGE
[Screenshot attached]Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
The default failure mode for 'review this screenshot' is a fluent paragraph describing the whole interface at a level too abstract to act on — 'the checkout flow could be clearer' — which a reader can't turn into a fix list without re-deriving the specifics themselves; requiring a findable region description per issue converts a vague impression into something a designer or engineer can locate and act on directly, without having to re-scan the whole image guessing at what was meant. Severity labels defined by concrete user-impact criteria, rather than an unlabeled adjective scale, only work as a triage tool if the three labels map to something checkable — can the user complete the task or not — rather than the model's own sense of how bad something looks; defining the labels by actual consequence is what makes the resulting list usable for prioritization instead of just decoration on an otherwise flat list of complaints. The explicit prohibition on fabricated precise measurements matters because vision models can produce a confident-sounding specific value — an exact hex code, a precise pixel gap — that is not actually a measurement, just a plausible-looking number generated in the same fluent register as everything else in the response; naming this failure mode directly and requiring qualitative-but-honest description instead removes a specific way over-precision can smuggle false confidence into a visual review that nobody asked to be quantified that exactly. The impact-per-effort closing question, distinct from pure severity ranking, matters because the most severe issue is not always the most useful one to fix first if it's also the most expensive to fix, and a review that only ranks by severity leaves the actual prioritization decision unmade; asking explicitly for the best ratio of impact to effort surfaces a genuinely different, more actionable judgment than severity alone would produce on its own.
Verified against
Claude Opus 4.6 (Vision) · 2026-08-08
Changelog
- 2026-08-08 — Initial publish, verified against Claude Opus 4.6 vision on a mobile checkout screenshot.
Building this for real?
This is a free starting point. If you'd rather have what Scult builds built and running for your business, that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
