Reviewing peach UI/prototypes/web pages based on UX laws read-only review skillis.
This skill does not modify code. It organizes problems and improvement suggestions, and actual implementation is handed over to peach-gen-ui, peach-team-ui-proto, peach-team-dev or direct modification work.
Input targets
It can receive one or more of the following inputs.
| Input | Processing |
|---|---|
| URL | Check browser/HTML content and review the screen flow |
| Screenshot | Review visual hierarchy, information density, and action placement |
| Vue file path | Review component structure, form/table/button placement |
| ui-proto task folder | Review overview, routes, and screen files together |
| Spec document | Review whether the required flow and actual screens align in UX |
| Natural language description | Heuristic review based on the specified screen/user flow |
Core principles
- Read-only: Do not modify files, commit, or stage.
- Context first: For back-office/operations tools, repetitive work efficiency, scannability, and error prevention take priority over decoration.
- Laws are evidence: Do not apply UX laws as absolute rules; use them as a basis for judgment suited to the screen's purpose and user role.
- Priority-focused: Do not list all problems; report problems that directly affect the user's task success rate first.
- Actionability: Prioritize suggestions that can be fixed directly in the screen/code over abstract criticism.
- No forced nitpicking: Treat the number of problems as a cap. If there is 1 problem, report only 1, and do not forcibly fill 3 or more on a small screen.
Reference loading rules
Read only the necessary references.
| Situation | Reference |
|---|---|
| Evidence per UX law is needed | references/laws-of-ux-summary.md |
| Peach back-office screen review | references/backoffice-ux-checklist.md |
| A report format is needed | references/review-report-template.md |
Workflow
Step 1: Confirm the review target
Identify the review target from the input.
- If it is a URL, first grasp the page purpose, main users, and core tasks.
- If it is a file/folder, read the related screen files and Spec.
- If the target is ambiguous, ask only 1 question.
예:
검토 대상이 여러 개입니다. 이번에는 URL 화면, Vue 파일, ui-proto 폴더 중 무엇을 기준으로 볼까요?
Step 2: Define the screen purpose and user tasks
Before reviewing, organize the following one line each.
대상 화면:
주요 사용자:
핵심 작업:
검토 범위:
If the user role is not specified, infer it from the screen structure, but indicate that it is an inference.
Step 2.5: Indicate evidence level
Attach an evidence level to each finding whenever possible.
| Evidence level | Meaning |
|---|---|
| Code confirmation | Directly confirmed in Vue/TS code |
| DOM confirmation | Confirmed in the running screen's DOM/text/state |
| Screenshot confirmation | Confirmed from the image as visual structure |
| Spec confirmation | Compared against Spec or ui-proto requirements |
| Inference | Possible for the screen's purpose, but runtime evidence is insufficient |
추정Items with only are not judged as high severity.
Step 3: Primary UX check
For pitch screens, apply the following 8 criteria first.
- Cognitive load: Is the information that must be understood on one screen not excessive?
- Choice overload/Hick: Are buttons, filters, and options not exposed too much at once?
- Chunking/proximity: Are related fields and actions grouped into meaningful groups?
- Jakob/mental model: Does it behave differently from existing back-office conventions and confuse users?
- Fitts: Are the size and spacing of primary buttons and click targets sufficient?
- Von Restorff/selective attention: Is the core action distinguished from secondary actions?
- Feedback/Doherty: Are save, search, loading, and failure states immediately visible?
- Peak-End/result clarity: After completing a task, are the result and next action clear?
For detailed criteria, references/backoffice-ux-checklist.mdfollow.
Step 4: Problem classification
Problems are classified by the severity below.
| Severity | Criteria |
|---|---|
| High | The user is likely to fail the task or save incorrect data |
| Medium | Task time, comprehension cost, and repeated operation burden increase |
| Low | A completeness and consistency issue, but does not lead to immediate failure |
Step 4.5: QA judgment mapping
The judgments in this skill are not judgments that directly fail the existing QA skill. They are candidate judgments for prioritizing follow-up work.
| Judgment | Condition | Follow-up handling |
|---|---|---|
| REJECTED candidate | One or more well-founded High findings | After user confirmation, peach-team-ui-proto or peach-team-dev handed over as the modification scope |
| CONDITIONAL candidate | One or more Medium findings or multiple Low findings | Report UX risk separately from mechanical verification |
| Recommendation | Only Low findings exist | Record as a candidate for the next UI cleanup task |
| No notable issues | No major UX risks within the confirmed scope | End without integration work |
Do not fail existing frontend-qa나 team-e2ebased only on UX heuristics rather than mechanical verification failure.
Step 5: Report Results
Write the report in the following order.
- One-line conclusion
- 3–7 major issues
- UX law rationale for each issue
- Fix suggestions
- Application priority
- Remaining items to verify
Use the following report format: references/review-report-template.md.
Step 6: Follow-up Connection
When passing review results to the next task, follow the criteria below.
| Target | Connection condition |
|---|---|
peach-team-ui-proto |
Layout, action placement, or feedback issues in the ui-proto screen itself are the main cause |
peach-team-dev |
Issues with save/search/state feedback or the actual API flow in this project's UI implementation are the main cause |
peach-team-e2e |
When verification of result confirmation, next action, or failure recovery is needed in the user flow |
| Manual hold | When it is a matter of UX preference or when work frequency/user role needs to be confirmed |
Output rules
- All responses must be written in Korean.
- Do not modify files directly.
- For items without issues, do not give lengthy praise; handle them briefly with something like "no particular issues."
- For UX law names, write both the Korean name and the English name.
- If the rationale cannot be confirmed on the screen, mark it as "inferred."
Follow-up reinforcement notes
This skill is version 1. In the future, peach-team-analyzeinvestigate and reinforce the following.
- Refine the classification of laws from the original Laws of UX and the GeekNews summary
- Strengthen the checklist by Peach back-office screen pattern
proto-ui-qa,frontend-qa,peach-team-e2eSelect the minimum checklist items to integrate into- Organize false positives/false negatives based on actual use cases