Review an AI-generated screen
Turn “something feels off” into specific observations, focused corrections and checks that tell you whether the revision worked.
Review a task before judging a screenshot
An attractive first frame can hide a confusing workflow. Follow the intended task with realistic content. Keep visual preferences separate from interaction failures: they need different corrections.
This example is a fictional workshop booking form built by an AI assistant. A visitor chooses a session, enters contact details and submits a booking. Suppose a long workshop title crowds the form on mobile, validation clears the selected session, and the submit button's vague label leaves the next step unclear.
Use a local or test environment for submission checks. The goal is to inspect the interface without creating real bookings or sending messages to customers.
Make the review repeatable
Write down the page, viewport, data and action for each observation. “The mobile form is broken” is hard to reproduce. “At 360 pixels wide, the two-line workshop title overlaps the session selector” tells the agent where to look. Use the width where you actually observed the issue; do not invent a measurement.
Keep the same content across revisions: a long workshop name, a long email address, an unavailable session, a validation error and a submission failure. Inspect loading and success states too. Screenshots show appearance; test focus behavior, submission and screen-reader support separately.
Review this workshop booking form in the test environment. The task is to choose an available session and submit contact details. Inspect desktop and narrow layouts with realistic long content, an unavailable session, a validation error and a failed submission. For each issue, report the exact state, what you observed, the consequence and a proposed check. Separate observed findings from things you could not test. Do not change the UI yet.
Fix lost work before decorative details
In the fictional draft, clearing the session after a validation error comes first. It makes the visitor repeat work and could lead them to choose a different session accidentally. The expected behavior is to retain valid input, identify the field needing attention and allow a correction.
Next, address the mobile overlap because it blocks reading or interaction. Then clarify the submit label using the action the product actually performs. If it creates a booking immediately, “Book this session” may fit; if another confirmation step follows, the label should describe that next step. Verify the flow before choosing the words.
Then consider heading weight and spacing. A preference for a calmer page still needs to preserve useful information and readable text.
The verdict for this example is revise. Losing a selected session and obscuring a control are reasons to hold the draft, even if its typography looks finished. Reconsider that verdict after reproducing and checking those failures; a preference about heading weight need not block an otherwise usable form.
Use a reference to explain your preference
For visual feedback, choose a Taste reference that demonstrates the relationship you want: perhaps a clear session summary beside a simple form. Annotate the relevant detail. Explain whether you admire the grouping, the hierarchy or the spacing; a full screenshot leaves those intentions ambiguous.
For this example, a useful note is: keep the chosen date and time visible near the action so visitors can check them before submitting. Use our current text and surface styles. The reference's decorative image and promotional banner do not help this task.
Ask the agent to inspect the reference and its notes alongside the current screen. If it cannot access or view the image, it should identify the missing evidence. A screenshot from another product cannot establish how that product handles validation.
Keep the session summary close to the form action. I want visitors to check their choice without scrolling back. Preserve our current type, colors and form components.
Give the correction a clear boundary
A good correction names the observed problem, desired behavior and parts to preserve. Requests such as “make it more premium” invite broad changes and make it harder to tell whether the original issue was fixed.
The following prompt assumes the illustrative problems have been confirmed in your project. Replace them with your own findings. Keeping errors beside their fields can lengthen the form; that is usually a useful tradeoff if people can locate and correct the problem. Check that the layout can accommodate the message.
Correct these confirmed booking-form issues only: preserve the selected session and valid contact fields after validation fails; prevent the long workshop title from overlapping controls at the narrow width we tested; and make the submit label describe the verified next action. Keep our existing form components, tokens, field order and booking logic. Reproduce each issue before editing, then show the same states after the fix. Report any check you could not complete.
Check the whole task again
Run the original and failing paths again. Wrapping the long title and showing validation errors may push the action out of view. Inspect both the running result and the implementation diff.
- Choose a session, trigger validation, correct the field and continue. Check that the session and other valid values survive.
- Repeat with long content and a narrow viewport. Confirm that labels, errors and controls remain readable and reachable.
- Navigate by keyboard and check visible focus. Use an appropriate accessibility review for behavior that a visual inspection cannot establish.
- Compare the revision with your original findings. Mark each as verified, unresolved or untested, and keep new suggestions separate.
What success looks like
The revision addresses each confirmed issue, preserves the intended task and includes evidence for what was checked. A new screenshot alone is not the acceptance record.
Carry the feedback into your next task
Save useful reference notes for later work. Keep decisions that apply only to this product in its project brief.