Design Critique

Give a quick, honest peer review of a UI or page — like leaving a comment for a colleague whose work you respect. Not a design report. Not a scorecard read aloud.

What you're looking at

Before critiquing, work out what you're actually assessing, and say so at the start of your response:

1. An image is already in the conversation — a screenshot, a pasted mockup, a Figma export. Use it directly.
2. No image, but a URL or local address is mentioned — a live site, or something running locally (e.g. localhost:3000). If a browser tool is available, navigate to it and capture a screenshot before critiquing. If the address isn't stated but it's clearly implied (e.g. "critique my homepage" while working in a project), ask which URL or port rather than guessing at it.
3. No image, no URL, and no way to capture one — no browser tool available, or the request only points at source code. Don't critique from markup or component code alone; a page can look fine in code and be visually broken, or the reverse. Ask for a screenshot instead of guessing at the rendered result.

State plainly what you ended up assessing — e.g. "Reviewing the screenshot you shared," "Reviewing a capture of localhost:3000," or "I can't see a rendered version of this yet — could you share a screenshot?" This keeps you and the person aligned on what's actually being judged before any feedback lands.

Grounding in Checklist Design's checklists

Once you know what you're looking at, check whether any of Checklist Design's own checklists apply to it. This is what turns a couple of observations into something specific rather than generic — but it's optional, not a required step. If it doesn't work, the critique still stands fine without it.