UI review checklist

Use when reviewing or polishing a screen before it ships, or when asked to review, audit or polish UI. Pair it with layout-and-hierarchy (structure), component-states, accessibility-basics, forms-feedback and theme-token-audit.

Look first, then judge

Capture the screen yourself: light and dark themes at desktop width (about 1280 px) and phone width (about 390 px), on a local or staging build with test data. Open every screenshot and read it as the user for five seconds: what is done, what needs them, what they press first. Write that down before the checklist; if you cannot, the first finding is structure.

Declutter pass

For every chip, badge, border, icon and label ask what job it does for the user. If none, report it for removal. Fewer elements beat more states. Example: an orders table where every row carries a "Paid" badge says nothing; show the status only where it differs ("Refund pending", "Payment failed") and put those rows first.

Checklist

1. Structure (layout-and-hierarchy): one headline per block; items as rows or cards, not prose; one-line titles with state on the right; blocks ordered by what the user loses if they miss it.
2. Hierarchy: one page title, one primary action per screen, secondary actions quieter; one action per button, named for the result ("Save changes", "Refund order", not "OK").
3. Layout: widths from the app's page frame or layout component; nothing clipped or wider than the viewport at 390 px; no horizontal page scroll; no dead space beside squeezed content.
4. Typography and spacing: the design system's heading levels, one body size, a smaller muted style for labels and meta; spacing from the scale, not one-off values; rows of one height in a list.
5. Copy: short and plain; no raw ids, codes or enum values as the only message; errors say what happened and what to do; the same thing has the same name on every screen.
6. Chips and status: shown only when they change what the user does; the warning tone only for what needs them; one word set per state.
7. States (component-states): empty, loading, error, long text, many rows.
8. Themes (theme-token-audit): light and dark, colours only from design tokens.
9. Focus and touch targets (accessibility-basics): name which control holds focus and whether THAT control shows a ring; 44 px targets on the phone.

Is it deliberate? (before you report)

An invented finding costs as much as a missed one. Before reporting something as a defect, ask whether the product does it on purpose: a status shown only where it differs; a large empty pane on a brand-new, empty workspace; a title cut with an ellipsis when the full text is one click away; the warning colour used only on rows that need action. If you are not sure, ask or mark it as a question, not a defect. The defects worth finding are often quiet ones, such as row titles styled exactly like their meta line so nothing stands out.

How to report

One finding per problem, ranked by cost to the user. Each:

• Where: screen and the exact element by its visible text ("the row 'Order #1042' in Recent orders"), not "a row".
• What: the screenshot (cropped) and what is wrong.
• Why: what the user loses (misses a pending item, cannot tell done from not done, presses the wrong thing).
• Fix: one line with the copy, the component or token, and the file.

End with what you checked and what you did not. A clean screen is a valid result: say "clean" and do not pad with taste remarks.

Example finding

• Where: Settings → Notifications, the "Email me about" section.
• What: six options run as one wrapped sentence of inline checkboxes; their on/off state sits at different horizontal positions on each line.
• Why: the user cannot see in a glance which notifications are on.
• Fix: a bordered list, one row per option, label on the left and a toggle aligned on the right, in NotificationSettings.tsx.