Claude for design critique, not just generation

A different task than generation, asking for a different kind of prompt

Asking Claude to critique an existing design is a genuinely different task from asking it to generate one, and prompting it the same way for both tends to produce a weaker critique than a deliberately-framed one would. Generation benefits from a clear target description; critique benefits from an explicit framing of what to actually evaluate against — without that framing, a critique request tends to default to generic, surface-level feedback that could apply to almost any design, rather than anything specific and actionable about the one in front of it.

Naming the actual criteria you want evaluated

A critique request that just says "what do you think of this" invites a broad, unfocused response touching a little on everything and going deep on nothing. Naming specific criteria — does this serve the stated user goal, is the visual hierarchy actually guiding attention where it should, does this hold up against the system's own established conventions — produces a more useful, specific critique than an open-ended request, because it gives the critique something concrete to be evaluated against rather than a vague, unanchored sense of quality.

Providing the context a critique actually needs

Design critique that's useful depends on context generation often doesn't need to the same degree — who the design is actually for, what problem it's solving, what constraints it's working within. A critique produced without that context is evaluating the design against an assumed, generic standard rather than against its actual purpose, and can easily produce feedback that's technically reasonable but irrelevant to what the design was actually trying to achieve. Provide the same context you'd give a human reviewer unfamiliar with the project, not just the design artifact itself.

Using critique to catch problems before they compound

Critique is most valuable early, while a design is still cheap to change — requesting a critique only after significant implementation work has already been built on top of a design decision means any real issue the critique surfaces is now more expensive to fix than it would have been earlier. Building a critique pass into the process before committing to implementation, not just as a retrospective exercise after something's already built, is where this actually pays for itself.

Weighing critique against your own judgment, not accepting it wholesale

A critique is an input to your own decision, not a verdict to implement automatically — some feedback will be genuinely useful and some will miss context or constraints the critique wasn't given, or wasn't able to weigh correctly against considerations a human reviewer with full context of the project would naturally factor in. Treat it as one more informed perspective to weigh alongside your own judgment and any other reviewer's, not as an automatic override of decisions you made for reasons the critique may not have had visibility into.

Asking for critique from more than one angle

A single critique pass tends to reflect whichever criteria were most prominent in how it was framed, and a design can genuinely have different strengths and weaknesses depending on the lens applied to it — usability, visual consistency with an existing system, accessibility, brand fit. Explicitly requesting critique from more than one of these angles, rather than one general pass, surfaces a fuller picture than a single unfocused critique would, since each angle tends to catch issues the others don't emphasise.

Critiquing your own past work, not just new proposals

The same critique discipline applies well to designs that already shipped, not only to proposals still in review — periodically critiquing an existing, live part of a product against current standards and current understanding of its users can surface drift that accumulated gradually and was never obvious at any single point, the same way a fresh pair of eyes catches things a team too close to the work stops noticing.

See reviewing a Claude-generated UI for real issues for a related but distinct discipline — reviewing implementation for correctness, versus critiquing a design's actual choices, which is what this page is about.