Put yourself in the shoes of an ordinary new user using this product for the first time: no technical background, haven't seen the source code, and don't know the developer's design intent.
This time it's not about reviewing code, but actually using it, finding confusing, obstructive, and unsettling places, and fixing what's worth fixing.
## Use — Real operations, not imagination
First find the product's main entry points and 1–3 core tasks (what ordinary users most often use to accomplish things), then walk through each task from scratch:
- If the product can be started, you must actually open it, click, and type; don't just look at code or screenshots.
- If it really can't be started, infer from code and component behavior, and mark each conclusion as [Verified] or [Speculated].
- Follow the order of real usage: first open → complete core task → view, modify, save, export results → use again a second time.
- Along the way, deliberately encounter these states: empty state, loading, error, no results, network disconnection or timeout, very long or invalid input, exit midway and come back, narrow mobile screen.
## Find — Only find places that will truly block users
- Can't understand: don't know what this is for, terminology, copy, or options are unclear.
- Can't find: don't know where to start, what to do next, and after finishing don't know where the results are.
- Not smooth: many steps, repeated operations, unreasonable defaults, counterintuitive operation order.
- No feedback: after clicking don't know if it took effect, while waiting don't know what's happening, and on failure don't tell the user what to do.
- Afraid to use: unclear about operation consequences, easy to mistakenly delete or overwrite, don't know if it's saved, worried about data loss.
- Doesn't meet expectations: feature names don't match actual behavior, same operations give different results in different places.
## Verify — Try to disprove every finding first
For each suspected issue, first take the opposing side and try to prove it doesn't hold:
- Must clearly write [specific operation steps] + [what the user originally expected] + [what was actually seen] + [what the user got stuck on, worked around, errored, or worried about because of it]. If it can't be stated clearly → discard.
- Must be encounterable through normal, reasonable usage flow. If it only appears by tampering with data, breaking configuration, or using unsupported methods → discard.
- If it's just an aesthetic preference, style difference, theoretical inconvenience, or users already have a smooth workaround → discard.
- Multiple issues caused by the same reason merge into one, not counted repeatedly.
- Keep only what cannot be disproven. Better to miss than to pad the list.
Priority:
- High: cannot complete core tasks, will lose data, serious consequences of misoperation.
- Medium: causes confusion, repeated attempts, or requires help from others to complete.
- Low: doesn't delay task completion, but improvement effect is clear and reproducible.
## Fix — Only fix confirmed issues
- Fixes should be minimal and targeted. First change copy, feedback, defaults, entry positions; only consider adding things last.
- Don't add features, steps, popups, confirmation boxes, or settings without authorization. Every additional interaction must clearly explain what confusion or risk it reduces.
- Follow existing design style, interaction methods, and project structure; keep behavior consistent across pages.
- After fixing, walk through the original reproduction steps again, then walk through related normal flows, confirm the experience is actually better and doesn't break usage others are already used to.
## Iterate until convergence
After one round of "Use → Find → Verify → Fix → Regression Test", start the next round to find new issues beyond confirmed ones, especially go back and check whether this round's changes introduced new confusion, redundant steps, inconsistent behavior, or misoperation risks.
If there are no new, verified, and worth-fixing issues for 2 consecutive rounds, stop. Don't pursue "no flaws can be found"; endless nitpicking will never end.
## Output
One line per confirmed issue:
Location (page/step, with file:line if necessary) · Operation steps · Expected vs Actual · Impact on user · Priority · Evidence [Verified/Speculated] · Fix (what was actually changed, or mark "suggestion only")
At the end of each round: this round newly confirmed N, disproven and discarded M, actually fixed X, regression test results, cumulative confirmed Y.
Finally, summarize in a few lines: the 3 issues that most affect new users, modifications already completed, unresolved issues, and which places could not be actually verified.
Start now: first clarify the product's entry points and core tasks, then act as a new user and start using it. For issues that can be confirmed and are suitable to fix directly, fix them and verify; don't stop at making suggestions.
