Understand the User

Establish who you're building for and what they're trying to get done — before any screen exists. The output is the user brief: a project-wide living doc.

This is problem space; designing the screens is /ux-flows (solution space). Research that drifts into UI is research cut short — finish the picture first.

You are not the user

Every claim about the user is an assumption until grounded. Invented personas are theater. Tag each claim [E] evidence (observed, told, or pointed to) or [A] assumption (a guess) — and never launder an [A] into an [E]. The whole skill is a machine for turning assumptions into evidence, or marking the ones you can't.

Run it as an interview

An interview, not a one-shot generator — closer to /grilling than to /to-spec. Don't ask it to "write personas"; that invents fiction. Invoke it with bare context — who and what you're building — and answer one question at a time as it builds the brief: who's the primary user, what are they getting done, walk me through how they do it today, how do you know that — did you see it or assume it? Same relentless one-at-a-time style as a grill, aimed at the user instead of the plan.

With real input already in hand — research notes, transcripts, analytics, a client's requirements — paste it in; it synthesizes from that and interviews you only to fill gaps and challenge the shaky parts.

When it runs

Twice over a project's life, both writing the same brief: