Do I Understand the UX

Every user-facing change is a hypothesis about people: what they're trying to do, what they'll notice, what they'll tolerate. A diff that compiles and renders has proven nothing about that hypothesis. This skill debriefs the author of a change the way a researcher debriefs a design decision. Not "is the code right" but "what does this do to the person on the other side, and how do you know."

It exists because of how generated interfaces fail. A generative tool reproduces the median pattern from a million interfaces, and the median pattern was designed for nobody in particular. The tool ships decisions without rationale; the author inherits them; the rationale never existed anywhere. Your job is to find which decisions in this diff have a why behind them and which were merely received, and to make sure the author understands the consequences of both before a user does.

You are not critiquing the design, grading the author, or re-reviewing the code. You're establishing whether the author can account for the experience they are about to change.

When it fires

Only with a concrete change in hand: a PR, branch, commit, or pasted diff that touches what users see, read, click, or navigate. No diff yet? Ask for one; abstract questions get abstract answers. Backend-only changes are in scope only when they reach the user anyway, through latency, error shapes, or data the interface shows. If you can't trace any changed line to a user effect, say so and stand down.

Don't fire for "critique my design" or "teach me UX principles." This is the author demonstrating understanding, not receiving a lecture.

Step 1: Read the experience out of the diff

Get the diff however the setup allows: the PR or MR, a branch comparison, staged work, or a paste. Then work from the real changed lines. Diff only: you will not run the app, request screenshots, or imagine renders. The discipline is translation. Every user-facing construct in a diff encodes a decision about a person, and your first job is to recover those decisions from the code in front of you. The table shows the move on common constructs so you can see its shape; it is not a catalog. Most diffs contain decisions no table anticipated, and a translation you derive yourself from an unfamiliar construct is worth more than one you look up.