Put yourself in the shoes of an ordinary first-time user of this product: you don't understand the technology, you haven't read the source code, and you don't know the developer's design intent.
First, actually use it, and find the places where a new user gets stuck, confused, or uneasy. Then switch back to the developer role: verify each one, judge for me whether it's worth changing, and give me a fix that can be carried out directly.
I will only reply briefly (for example "do", "do 1 3", "not 2"), and you will implement and verify the changes according to my reply. So you need to do enough of the judging and planning yourself; don't throw the problem back at me.
## 1. Use — actually use it once; suggestions may only come from here
- First, clearly state the product's entry point, target users, and 1–3 core tasks. The basis for your judgment must come from the product itself (UI, copy, README, docs, default data); don't guess out of thin air.
- If the product can be started, you must actually open it, click, and type, and complete each core task from scratch.
- Follow the order of real use: first open → complete the core task → view, modify, save, export the result → close and reopen → after using it for a while (more data, repeated use).
- Along the way, deliberately poke at these states: empty state, loading, error, no results, very long or invalid input, exiting midway and coming back, narrowing the window or a phone screen.
- While walking through, note down every place that makes you pause: which step, what you wanted to do, what felt wrong, and how you finally worked around it.
## 2. Verify as much as possible — "unverified" is the last resort
When you hit a step you can't drive (system dialogs, file pickers, native menus, network services, large data volumes), first find a way around it, and only then consider marking it "unverified":
- Stub or mock the layer that calls the system capability (for example, replace the directory picker with one that always returns a fixed test directory), so the UI flow still runs through.
- Call the same backend interface directly, then check the actual artifacts: generated files, database records, whether the configuration changed.
- Use a script to generate test data at realistic scale (hundreds to thousands of records), and experience the speed and information density of browsing, filtering, and scanning.
- Close and reopen, delete the cache and reopen, and confirm whether data and state are retained.
- If you used a workaround, state which part you bypassed and how much uncertainty remains.
- Only for those that truly cannot be bypassed should you mark them "unverified", and explain why and the verification method you recommend.
## 3. Find — places that make a new user stop (any type)
Can't understand, can't find, hard to use, no feedback, afraid to use (afraid of losing data, afraid of misoperation), doesn't match expectations, missing feature, superfluous feature, uncomfortable detail.
The above is not a checklist; don't hunt deliberately just to fill one item per category.
## 4. Verify — for each one, first try to disprove it
For each suggestion, first take the opposing side and try to prove it doesn't hold:
- You must clearly write [at which step] + [what the user expects] + [what they actually see] + [what the user gets stuck on, works around, gets wrong, or worries about because of it]. If you can't state it clearly → drop it.
- It must come from a normal, reasonable usage flow. If it only appears by tampering with data, breaking configuration, or using an unsupported method → drop it.
- "Other products all have it", "it might be useful someday", "it looks better this way", "I'm used to it this way" — drop all of these.
- Is this a real need of an ordinary user, or of a small number of advanced users, or just your own preference? The latter → drop it.
- Is the existing behavior intentional? Check code comments, README, docs, and requirement notes. If there is a reasonable reason, respect the original design; if there is a real conflict, state where the conflict is.
- Merge multiple suggestions caused by the same reason into one; don't count them repeatedly.
- Keep only the ones you can't disprove. Better fewer than padding the list.
## 5. Judge — draw the conclusion for me
For each suggestion that remains, give a clear conclusion; don't write "could consider":
- ✅ Recommend doing: real impact, light solution, controllable risk.
- 🟡 Optional: valuable, but there is a cost or trade-off; state clearly what the trade-off is, and say which side you lean toward and why.
- ❌ Not recommended: explain the reason (benefit too small, cost too high, conflicts with the original design, just a preference).
Judgment principles:
- Always propose the lightest solution. If you can change the copy, don't change the interaction; if you can change the interaction, don't add a feature.
- Try not to add popups, confirmation dialogs, settings items, or extra steps. If you really must add one, explain what confusion or risk it reduces, and why a lighter solution doesn't work.
- Don't break the usage that existing users are already used to in order to improve one scenario.
- Changes such as deleting or hiding features or changing existing behavior can at most be judged 🟡, unless the evidence is very strong.
- Priority: high = can't complete the core task, will lose data, serious consequences of misoperation; medium = causes confusion, repeated attempts, detours; low = doesn't block completing the task, but the improvement is clear and reproducible.
## 6. Produce a plan — written so that when I say "do", you can act directly
Every ✅ and 🟡 must come with a concrete plan:
- Where to change: page or component, and the corresponding file (file:line).
- What to change it to: concrete copy before/after (old → new), how the interaction changes, under what conditions it appears or disappears, what the default value becomes.
- What not to change: explicitly say which related behaviors will remain unchanged.
- How to verify: after the change, which flow to walk through again, what result means success, and which normal flows to regress.
- Scale: small (a few lines) / medium (one component) / large (cross-module). Split large changes into steps that can be done separately.
## 7. Output
1. Entry point, target users, core tasks (a few lines is enough).
2. Walkthrough record: write it in order of use, and mark each step [Verified / Bypass-verified / Unverified].
3. Suggestion list, sorted by "conclusion → priority → benefit ÷ cost", numbered S1, S2..., with each item in the format:
S-number · Conclusion (✅/🟡/❌) · Priority · Type · Location · Expected vs actual · Impact on users · Plan (per section 6) · Confidence
❌ items only write one line: problem + reason for not doing it.
4. Unverified items: reason, and recommended verification method.
5. One-sentence conclusion: which item should be done first, and why.
6. Reply menu, placed at the end, listed verbatim:
- "do" = implement all ✅
- "do S1 S3" = only do these items (can also include 🟡)
- "do all" = do both ✅ and 🟡 (implement 🟡 according to the side you recommend)
- "not S2" / "change S2 to..." = adjust a certain item
- For other questions, just say them directly.
## 8. After receiving my reply
- Implement the changes according to my reply, strictly within the scope of the plan, and don't change anything else along the way. If during implementation you find the plan doesn't work, first explain why, switch to the closest plan, and don't force it.
- After each change is done, walk through the original flow again according to the verification steps in the plan, and regress the related normal flows. If the project has tests, run the tests.
- Report: for each item, "completed / partially completed / not completed" + actual changes (files, copy before/after) + verification results.
- Then walk through the core tasks again as a new user, specifically checking whether this round of changes introduced new confusion, extra steps, or inconsistent behavior. If there are new findings, produce a new list according to sections 4 to 6, with the same reply menu; if not, explicitly write "there are no new issues worth changing in this round".
- Stop after 2 consecutive rounds with no new, verified, and worth-changing issues. Don't nitpick endlessly just to fill the list.
Start now.
