A useful Claude Opus 5.5 design review should leave you with specific changes to investigate. A verdict that a screen looks clean or feels cluttered gives a designer little to work with. Ask instead where the design makes a particular task difficult, what evidence supports that concern and how the proposed change would be checked.
Anthropic documents screenshot interpretation among Opus 5.5's vision capabilities. That gives the review a useful starting point. It still needs a boundary: a picture shows a state of an interface, while keyboard navigation, validation and responsive behavior require evidence from the working page.
Before sending material to Claude Opus 5.5, write down what the person using the screen is trying to finish. For an illustrative signup form, that might be creating an account with an email address and password. Include the initial screen, the relevant error state and the successful result if those designs exist.
Identify which images belong to which state and give their viewport dimensions. Preserve a full-screen view when adding a close-up of small text; otherwise the model loses the relationship between the detail and the surrounding controls. Anthropic's vision guidance recommends clear images with legible text and cautions that resizing or heavy compression can interfere with interpretation.
Also state which decisions are settled. A review of the signup flow need not become a proposal to replace the site's typography or navigation. Existing brand rules, fixed wording and the intended audience give the reviewer a basis for judging the screen you actually need to improve.
Request a short set of findings. Each should identify the element, describe the obstacle and suggest a way to confirm it. “The password rule appears only after submission; check whether people can find the requirement before entering a password” is a useful proposed investigation. It does not pretend anyone has already failed the task.
Keep observations and preferences distinguishable. “This label is clipped in the supplied mobile image” points to visible evidence. “The button would look nicer with rounder corners” expresses a design preference. Both can be discussed, but they should not receive the same priority merely because they appear in one answer.
Use the critique to direct checks on the working interface. Anthropic says Claude's coordinate and localization outputs are approximate. A model's visual estimate is therefore not a measurement of a button's dimensions or a reliable contrast calculation.
For text contrast, inspect the actual foreground and background colors. WCAG 2.2's minimum-contrast criterion sets a ratio of 4.5:1 for ordinary text and 3:1 for qualifying large text, with specified exceptions such as logos and inactive controls. If the critique flags faint helper text, record its computed ratio and applicable text category before deciding whether it fails the criterion.
Then try the relevant journey with a keyboard. W3C's preliminary checks describe moving through controls with Tab and back with Shift-Tab, checking access, sequence and visible focus. In the signup example, follow the fields through to submission. Record the exact step where focus disappears or a control cannot be reached. A screenshot of an unfocused button cannot settle that behavior.
Check the layout at a narrow viewport as well. WCAG's reflow criterion uses a width equivalent to 320 CSS pixels for vertically scrolling content, preserving information and functionality without requiring two-dimensional scrolling. It makes exceptions for content that needs a two-dimensional layout, such as certain tables or diagrams. Those exceptions do not automatically cover surrounding paragraphs or form controls.
For the form, inspect whether instructions, error text and the submit button remain available. Use the browser's viewport measurement; a screenshot's file dimensions are not enough to establish the CSS viewport used to render it. Keep the viewport and zoom setting with the finding so another person can repeat the check.
Error messages deserve their own pass. WCAG's error-identification criterion requires an automatically detected input error to identify the affected item and describe the error in text. A red border by itself does not provide that description. In the hypothetical signup flow, submit a required field empty and inspect what the interface actually says before reporting a defect.
An issue should carry its evidence into the revision. Describe the route and state, the affected element, the observed result and what a successful correction would look like. Attach the relevant image or measured value to your team's issue record. Avoid accepting a generated severity label unless its explanation matches the consequence for the task.
For example, a confirmed inability to reach the submit button by keyboard blocks completion of this journey. A suggestion to reduce the space above the heading has a different consequence. Work through the completion problems first, then consider polish against the existing design direction.
If you ask GPT-6 Astra for another reading, give it the same task and evidence. Compare whether it identifies a new, checkable problem. Agreement between two critiques still does not measure contrast or reproduce a keyboard failure. Keep the underlying page as the place where those claims are resolved.
After a change, repeat the check that produced the finding. If an error message moved, inspect the error state again at the recorded viewport. If a control received new focus styling, follow the keyboard sequence again. Save the result beside the original issue so the decision to close it is understandable later.
A focused Claude Opus 5.5 design review can end with a few well-supported revisions and a clear record of what remains untested. W3C describes its preliminary accessibility checks as incomplete; adding an AI critique does not turn them into comprehensive certification. The useful outcome is a design team that knows what to change, why and how to verify it.