A UI design critique checklist beyond visual taste.

Agree on the task and the review boundary

Before commenting on a screen, state who is trying to do what and what decision the review should support. Ask whether you are reviewing an early layout, a visual direction, or an implementation-ready interaction. The same comment can be useful at one stage and distracting at another. Separate known constraints from assumptions, including data availability, supported devices, and the design system the team intends to use.

Describe the review as an inspection, not a usability study. Reviewers can identify potential problems and contradictions, but they cannot speak for every user. Keep a place for questions that require product policy, engineering input, or research rather than resolving them by opinion. Agree on those boundaries before opening the file.

Follow the information hierarchy before adjusting style

Read the screen from the task outward. Can someone identify the page purpose, their current state, and the next meaningful action? Look for competing primary buttons, ambiguous labels, missing context, and details that arrive after they are needed. Review actual text rather than perfect-length placeholders. A hierarchy that only works with short names or empty error messages is not ready for handoff.

Use spacing, grouping, and typography to express relationships before adding more decoration. Compare repeated elements: do identical treatments mean identical things? Are destructive and routine actions distinguishable? If an icon carries a meaning that is not obvious, propose a text label rather than relying on visual familiarity. Describe the communication problem, not your preferred aesthetic.

Inspect states and recovery, not only the ideal screen

Walk through loading, empty, error, disabled, success, and partially completed states that are relevant to the task. Check what happens when data is long, missing, outdated, or interrupted. Ask how someone can go back, correct an entry, or recover without repeating work. Distinguish a system limitation from a missing design decision, and do not demand irrelevant states simply to complete a checklist.

Review accessibility as behaviour and content

Inspect text and control contrast in the states actually shown, not just the palette. Check whether colour is the only signal, whether important text remains readable when enlarged, and whether touch controls have sufficient space. Annotate expected focus order, visible focus, labels, and error announcements. A static Figma frame cannot demonstrate keyboard operation or assistive-technology support; those require checks in an appropriate implementation.

For a coded interface, try the relevant task without a mouse and investigate any lost or trapped focus. Pair automated checks with manual testing and, where possible, research involving disabled people. Use the current W3C reference to understand requirements and exceptions. Neither a critique checklist nor a plugin score certifies compliance or removes the need to understand the product context.

Turn comments into decisions the team can act on

Write each substantive comment as location, observation, task risk, and proposed next step. Keep evidence and confidence visible: an observed blocker, a documented requirement, and a reviewer’s hypothesis are not interchangeable. Prioritise by the importance of the affected task and the likely harm, then identify what needs validation. Avoid decorative numerical scores that imply precision the review does not have.

• Resolve contradictions or task blockers before optional visual refinements.
• Assign an owner to each accepted change or open question.
• Record declined suggestions with a reason so they are not repeatedly reopened.
• Schedule a focused recheck and retain unresolved risks in the handoff.