UX Flow Review

逐屏逐态地走一遍真实用户的路径，在「屏与屏之间」找出摩擦点，而不是孤立地评审单个界面。

视觉评审看的是一块屏幕，而这份提示词走的是路径，找出用户卡住的地方。它从「用户是谁、他为什么而来、他已经知道什么、处于什么心态、出错会怎样」开始，逐屏逐态推进——其中失败路径一节按作者所述通常产出最多发现，因为多数产品只在正常路径上做了设计，其余全靠临场发挥。附加章节涵盖「该删掉什么」，以及新手引导多快能触达第一次真实价值。

# UX Review

**Use when:** reviewing a flow, a feature, or a whole product for friction and confusion.
**Pairs with:** [ui_design.md](ui_design.md), [../core/self_critique.md](../core/self_critique.md)

Visual review looks at a screen. UX review walks the path a real person takes and finds where they get stuck.

---

## The prompt

```text
Review this as a user experience problem, not a visual one.

STEP 1: WHO AND WHY
- Who is the user and what do they want to get done? Not "use the app".
  The actual outcome they came for.
- What do they know already? What do they not know?
- What is their state of mind: rushed, careful, frustrated, first time,
  hundredth time?
- What happens to them if this goes wrong? That sets how much protection
  the flow needs.

STEP 2: WALK THE PATH
Step through the whole flow, one screen or state at a time. For each:
- What does the user see first? Not what is on the screen, what their eye
  lands on.
- What are they supposed to do here? Is that obvious in one second?
- What could they do by mistake?
- What do they have to remember from a previous step? Every remembered
  thing is a cost. Can the system remember it instead?
- How many taps, clicks, or fields to get through? Is each one necessary?
- What happens if they stop here and come back tomorrow?

STEP 3: COUNT THE FRICTION
List every point where the user has to:
  think, wait, decide, type, remember, go somewhere else, or read
  something to continue.
For each, ask: can this be removed, defaulted, deferred, or done by the
system? Rank by how much friction removing it would save.

STEP 4: FIND THE FAILURE PATHS
For each step, what happens when:
- The network is slow, then fails
- The user enters something unexpected
- The operation partly succeeds
- Permission is denied
- The data is empty, or far larger than expected
- The user goes back mid flow
- The user closes the app and returns later
- The same action is triggered twice quickly
For each: what does the user see, what can they do next, and did they
lose any work? Losing user input is the worst outcome in this list. Flag
every place it can happen.

STEP 5: CHECK THE MOMENTS THAT DEFINE QUALITY
- First use, before any data exists. Is it a dead end or a starting point?
- The moment of waiting. What do they see in the first 200ms, at 2
  seconds, at 10 seconds?
- The moment of error. Does the message say what happened and what to do?
- The moment of success. Does the user know it worked, and what is next?
- The moment of undo. Can they take it back? Should they be able to?
- The moment of leaving. Is anything unsaved?

STEP 6: ACCESSIBILITY AS EXPERIENCE
- Can this be completed with a keyboard alone, or with a screen reader
  alone? Walk it.
- Focus order: does it follow the visual order?
- Is anything communicated only by colour, only by position, or only by
  a hover?
- Does it work at the largest text size and at the smallest screen?

FINDINGS
  [Severity] where in the flow
  What the user experiences
  Why it is a problem for this specific user
  The fix, specifically

  Blocker: the user cannot complete the task, or loses data or work.
  Major:   the user completes it but is confused, slowed, or annoyed.
  Minor:   friction a user would tolerate but not choose.
  Polish:  would make it feel better.

RULES
- Every finding names a real moment in the flow. Not "the onboarding
  could be smoother".
- Do not list generic best practices. Only what is wrong here.
- Say what works well, briefly, so I know you understood the design
  before criticising it.

END WITH
- The single biggest thing standing between this user and their goal.
- The three changes with the highest effect for the least work.
- One thing that could be removed entirely and would improve the product.
```

---

## The first minute test

```text
Simulate a first time user, out loud, one thought at a time. They have
not read anything. They are mildly impatient. Narrate their internal
monologue for the first sixty seconds of using this.
Then list every moment where they thought "what?", "where?", "why?", or
"did that work?".
```

This finds more real problems than a checklist, because it forces the model to hold a point of view rather than evaluate a list.

---

## The removal question

```text
What could be removed from this product entirely and make it better?
Give me three candidates ranked by confidence. For each, say who would
complain and whether they are right.
```

Adding is easy for models. Removal takes a stance, so it must be asked for directly.

---

## For onboarding

```text
Review this onboarding against one question: how fast does the user reach
the first moment of real value?
- Count every screen, field, and decision before that moment.
- For each, could it be removed, defaulted, deferred until after value,
  or inferred?
- Where is the user asked for something before they understand why?
- Is there a way to try the product before committing to anything?
Report the current count of steps to value, and the version you would
build with the fewest.
```

---

## Why it works

Walking a path beats reviewing a screen, because problems in experience live between screens rather than inside them.

The failure path section usually produces the most findings. Most products are designed on the happy path and improvised everywhere else, and the improvised parts are where users decide the product is not good.