ux-quality-perspective

UX Quality Perspective (Chinese Version)

English version: See the corresponding English skill.

When to Use

• When a quality phase requires reviewing information architecture, interaction states, consistency, responsive behavior, or accessibility from a user experience perspective.
• When interface, prototype, user flow, or UI test evidence is needed to turn experience risks across product, design, engineering, and QA into actionable items.

Inputs

• stage(required):requirements-analysis、test-strategy、test-strategy-review、code-review、test-case-writing、test-case-review、test-reporting or test-report-review。
• Provided evidence such as prototypes, screenshots, interface descriptions, design specifications, user flows, change materials, test assets, or reports.
• Optional context: target users, devices/breakpoints, assistive technologies, design system, release scope, known limitations.

Execution Flow

1. Validate stage. If missing or unsupported, return "Not Applicable", explain the supported phases and request a valid value; do not generate filler findings.
2. Load and follow only the one Prompt in the table below corresponding to that stage ; do not read across or merge multiple phase Prompts.
3. First determine applicability based on the materials.test-strategy、test-strategy-review、code-review、test-case-writing and test-reporting areconditionally involved: analyze only when there is traceable UI/UX impact or relevant experience evidence. When there is no UI/UX impact or evidence, return "Not Applicable", explain the reason, known facts, gaps, and materials needed for reassessment, and do not write filler findings.
4. requirements-analysis can still apply when there is no prototype: report only confirmable requirement facts, UX evidence gaps, open questions, and prototype/flow/state materials that need to be supplemented; do not fabricate screens, states, copy, or cross-device behavior.
5. Generate an independent UX quality report that clearly distinguishes facts, evidence, inferences, and unverified items.

stage	Prompt to load only
requirements-analysis	prompts/requirements-analysis.md
test-strategy	prompts/test-strategy.md
test-strategy-review	prompts/test-strategy-review.md
code-review	prompts/code-review.md
test-case-writing	prompts/test-case-writing.md
test-case-review	prompts/test-case-review.md
test-reporting	prompts/test-reporting.md
test-report-review	prompts/test-report-review.md

UX Responsibilities and Boundaries

• Focus on information architecture, navigation, discoverability, interaction feedback and states, consistency, responsive behavior, and accessibility; base this on the provided UI/UX evidence.
• When prototype, flow, state, breakpoint, or assistive technology evidence is not provided, mark it as unknown or to be confirmed; do not fabricate pages, controls, copy, error states, device behavior, or test results.
• Do not replace backend/frontend implementation correctness review, API reliability or security assessment, test execution, or release approval. Without corresponding evidence, do not assert that the implementation is correct, the interface is reliable, it is secure, tests pass, or it can be released.

Report Contract

Unless returning "Not Applicable", each report contains in order:Summary, Facts, Evidence, Findings, Risks, Information Gaps, Open Questions, Actions, Confidence Level. Findings, risks, and actions are ordered by impact; each conclusion states its evidence basis and responsible role.

Pre-Delivery Self-Check

• stage is validated and only one matching Prompt is loaded
• applicability was determined first; no filler findings when a conditionally involved phase is not applicable
• requirement analysis without a prototype reports only evidence gaps and does not fabricate UI
• the report distinguishes facts, evidence, inferences, and gaps, and includes all contract fields
• no out-of-scope assertions about implementation, interfaces, security, testing, or release conclusions

Load on Demand

• Only after stage is valid, read the uniquely corresponding prompts/ file in the table.
• Use when evaluation or regression is needed evals/ and run the skill-up validation; do not treat eval cases as project facts.

Common pitfalls

• Do not disguise a generic UX checklist as confirmed defects of the current product.
• Do not fabricate pages, states, or mobile behavior due to a lack of prototypes.
• Do not write a UX review as unsupported conclusions about implementation correctness, interface reliability, or release.

Report sources

The report header retains the selected stage, stable source_id , and provided version. When a source ID is missing, declare a temporary local locator; when a version is missing, write unknown, and do not fabricate. Each finding includes a stable finding_id, source/evidence locator, and status. Each action links back to a finding and states the evidence needed to close it; owner, date, and action status are filled in only when provided, otherwise unknown. These are independent report fields and do not constitute a dependency on other Skills.

Optional experience evidence matrix

When project materials select these dimensions, record 输入方式 × 设备/断点 × 辅助技术 × UI 状态, and for each cell retain the source/version and the observation result or NOT_RUN/unknown. Do not assume all combinations apply, specify devices that were not provided, or mark unobserved cells as passed. A single screenshot supports only the visible cells; keyboard, screen reader, mobile, and recovery conclusions each require their own evidence.