How I review pull requests for UI risk

A UI pull request can look safe and still change the product in ways that matter. A class name moves. A loading state disappears. A button becomes reachable only by mouse. A data assumption works for the happy path and fails for the account with 4,000 records.

So I do not review UI PRs only as code. I review them as product behavior.

Start with the user path

Before reading line by line, I ask what user path changed. Can someone sign up, filter a table, update billing, complete checkout, invite a teammate, or recover from an error differently than before?

The diff tells me what files changed. The path tells me what can break.

If the PR description does not name the path, I reconstruct it from routes, components, tests, and copy. That context makes the code review sharper because every question has a product anchor.

Look for hidden state loss

UI regressions often hide in state transitions:

• Loading to loaded.
• Empty to populated.
• Valid to invalid.
• Online to offline.
• Desktop to mobile.
• Authenticated to expired.
• Filtered to reset.

I scan for branches that render less information than before. Did the error keep its retry action? Did the form preserve typed values? Did pagination reset intentionally? Did the modal return focus to the opener? Did the optimistic update handle failure?

State loss is frustrating because it makes the product feel careless.

Check accessibility where behavior changed

Accessibility review should not wait for a separate audit. If a PR changes interactive UI, it should preserve keyboard access, focus order, labels, disabled behavior, and motion preferences.

I pay special attention to custom controls. If the PR introduces a div that behaves like a button, a popover, a drawer, a tab, or a menu, the review gets stricter. Native behavior is cheap. Recreating it requires evidence.

Compare responsive constraints

A UI can pass visual review at one viewport and break everywhere else. I look for fixed widths, long strings, nowrap text, absolute positioning, and components that assume a short label.

For product screens, I care less about whether every breakpoint is novel and more about whether the layout can absorb real content: translated copy, long customer names, missing images, high zoom, and dense data.

Ask what should be tested

Not every UI PR needs a large test suite. But every meaningful UI PR needs a theory of verification.

Small copy or style changes may need a build and a screenshot. Shared component changes need focused tests or stories. Checkout, auth, billing, and destructive actions deserve heavier coverage. The risk should set the test surface.

My short checklist

Before approving, I ask:

• What user path changed?
• Which states can now render?
• Which states disappeared?
• Does keyboard and focus behavior still work?
• Does the layout survive mobile and long content?
• Does the PR include the right level of verification?
• Is any abstraction broader than the problem?

The best UI reviews are not slow. They are specific. They find the behavior most likely to surprise users and make it visible before it ships.