Verified against ChatGPT · 2026-08-09
Get a screenshot critique that separates 'will confuse users' from 'I just don't like it' before a design goes to dev
Critiques a single UI screenshot against the interaction it's meant to support, sorting findings into what will actually cause user confusion versus aesthetic preference, so dev handoff isn't delayed over subjective taste.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Critique the attached UI screenshot before it goes to development. I need you to separate findings that will actually cause user confusion or errors from findings that are just aesthetic preference — a design review that treats both the same wastes engineering time relitigating taste. SCREEN AND ITS JOB Checkout review step for a subscription box — user confirms items, address, and total before paying. WHO USES IT AND WHEN A returning customer on mobile, mid-commute, expecting this to take under 30 seconds. WHAT HAPPENS RIGHT BEFORE AND AFTER THIS SCREEN Comes right after selecting a delivery date; next screen is a payment form. Back button returns to date selection. CONSTRAINTS I CANNOT CHANGE Cannot add a new screen — this must stay a single step; legal requires the cancellation-terms text to stay visible above the fold. RULES FOR THE CRITIQUE For every issue you flag, state which bucket it belongs in: "functional risk" (a user could genuinely misread, mis-click, or fail to complete the task because of this) or "preference" (a reasonable design choice, just not the one you'd personally make). Only elaborate on functional-risk items — for preference items, name them in one line and move on, don't argue for your preferred alternative as if it were objectively correct. For each functional-risk item, describe the specific mechanism of confusion: what a first-time user would likely think this element does, versus what it actually does, and why the gap exists (label ambiguity, visual hierarchy putting a secondary action above the primary one, a state that looks identical to a different state, etc.). Do not flag anything as a functional risk based on your own aesthetic taste dressed up as a usability claim — if you can't describe a specific way a real user would be misled, it belongs in the preference bucket or not at all. Respect the stated constraints; do not recommend a fix that violates one of them, and if the best fix for a functional risk requires violating a constraint, say so explicitly and offer the best fix that doesn't. OUTPUT FORMAT Functional risks (numbered, each with: what's confusing, why, and one fix that respects the constraints). Then preference notes as a short flat list, one line each, explicitly marked as skippable for this handoff.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
A design critique that doesn't explicitly separate functional risk from preference tends to produce a wall of undifferentiated feedback where a genuine usability bug (a disabled-looking button that's actually clickable) sits next to a subjective opinion (this shade of blue feels cold) with equal apparent weight — this is the single most common reason design reviews stall handoff, because engineers can't tell which items are blocking and which are optional. Forcing the model to name the bucket for every item, and to justify functional-risk claims with a specific mechanism (what the user would think versus what's true, and why the gap exists) rather than an assertion, closes off the failure mode where GPT-5.1 dresses up a stylistic preference as a usability finding by attaching plausible-sounding jargon like "cognitive load" or "visual hierarchy" to what is actually just taste — the mechanism requirement makes that dressing-up visible because a real functional claim has to specify what gets misread and why, while a fake one has nowhere to go beyond the label. Explicitly respecting stated constraints, and requiring the model to say so when a good fix would violate one rather than silently proposing it anyway, matters because unconstrained redesign suggestions are the most common way a critique becomes unusable to the team receiving it — a suggestion that ignores a hard legal or technical constraint has to be re-filtered by a human before anything in the critique is actionable, defeating the point of asking for a scoped review in the first place.
What you get back
Functional risks: 1. The 'Edit address' link uses the same gray as disabled text, so a first-time user may believe it's inactive and not attempt to change a wrong address before paying — increase contrast to match the other tappable links, no layout change needed. Preference notes (skippable): item thumbnails could be slightly larger; total price uses a different font weight than the rest of the summary.
Verified against
ChatGPT GPT-5.1 · 2026-08-09
Changelog
- 2026-08-09 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — branding & design, built and maintained for you — that's Scult's day job.
EXPLORE BRANDING & DESIGN
