An interface without errors does not necessarily deliver quality. Waiting, comprehension, recovery, and assistive-technology use are often where people actually feel the product’s quality.
The UX Quality Perspective Skill examines task flow, feedback, accessibility, and recovery moments, making lived experience concrete enough to improve.
A checkout journey makes waiting, timeout, keyboard focus, mobile recovery, and accessible feedback observable across concrete interface states.
Awesome QA Skills organizes Skills by language and testing stage. The series overview covers repository structure and shared installation options; this guide stays with UX Quality Perspective.
Read the source Skill first
The main prompt covers Inputs, Applicability Check, UX Questions, Output Contract, Evidence and Boundaries. Those headings are navigation; the project artifacts still provide the facts.
This Skill has no separate examples directory. The sample below is derived from its entry point, main prompt, and eval constraints.
Related Skills
UX Quality Perspective looks at whether users can understand, complete, and recover from a task. These Skills help with cross-role or specialist questions:
| Skill | When to use it | What it adds |
|---|---|---|
| Product Quality Perspective | An experience issue affects business rules or user value | Connects observations to tasks, conversion, trust, and acceptance trade-offs |
| Accessibility Testing | Keyboard, focus, semantics, or assistive technology is a primary risk | Checks accessibility criteria, interaction paths, and reproducible evidence |
| Multi-Role Quality Synthesis | UX conclusions need to be decided alongside Product, QA, and Technical material | Preserves user impact, technical constraints, and role disagreements |
| Technical Quality Perspective | An experience issue depends on APIs, performance, errors, or telemetry | Adds runtime consequences and technical evidence boundaries |
| Project Delivery Perspective | UX evidence work affects test windows or release dates | Tracks follow-up work without deciding whether UX passes |
What UX Perspective contributes across the workflow
UX Quality Perspective shares eight stages with Product and QA, but analyzes only material with UX impact or evidence. The stage names may match; the questions and outputs do not.
| Stage | What UX checks | What the team receives |
|---|---|---|
| Requirements analysis | Whether task, navigation, state, feedback, breakpoint, and assistive-technology evidence is sufficient | UX facts, evidence gaps, questions, and responsible role |
| Test strategy | Whether proven UX risks cover task flow, key states, devices, input methods, and accessibility | UX coverage, method, observation signals, and exit criteria |
| Test strategy review | Whether evidence-backed states, devices, or assistive paths are missing | UX risks, strategy gaps, and evidence requests |
| Code review | Whether the PR has traceable UI impact and follows design and state evidence | Demonstrable UX deviations and evidence requests for Design, Development, and QA |
| Test case writing | Whether supplied tasks, states, and design requirements can become observable steps | Evidence-backed preconditions, steps, expected results, and risks |
| Test case review | Whether cases cover evidenced states, input methods, devices, and assistive technology | Demonstrable UX coverage gaps and revisions |
| Test reporting | What conclusions the record supports across tasks, devices, input methods, and assistive technology | Observations, impact, reproduction conditions, owner, and next step |
| Test report review | Whether a screenshot or recording is being generalized to all states and devices | Evidence scope, UX risk, information gaps, and actions |
A UX report includes summary, facts, evidence, findings, risks, information gaps, questions, actions, and confidence. State what a recording proves and what it does not. Without prototype, flow, state, or device evidence, the useful output may be “not applicable” and a list of evidence to collect.
Separate the three perspectives on one input
| Shared input: delayed payment callback | Product Quality Perspective | QA Quality Perspective | UX Quality Perspective |
|---|---|---|---|
| Requirements, PR, regression record, payment logs, timeout recording | Confirm waiting rules, duplicate-charge risk, and business approver | Check whether timeout, retry, and reconciliation ran and have evidence | Check processing/timeout feedback, focus, copy, and recovery |
Turn checkout experience observations into actions
Review feedback, error recovery, keyboard use, copy, and mobile behavior in the checkout flow. The question is whether the user can take the next step.
| Task state | Observation | User impact | Improvement |
|---|---|---|---|
| Waiting for payment | No progress, timeout, or duplicate-submit message | User may refresh or pay again | Show state and idempotency guidance |
| Address validation fails | Error appears only at the top of the page | User may not find the field to correct | Associate focus and error text with the input |
| Keyboard use | Focus stays behind an opened dialog | Keyboard user cannot complete payment | Manage focus and provide an exit path |
| Mobile recovery | Form is empty after returning to the page | User must re-enter details | Preserve safe draft state |
A UX conclusion should name the specific state, user impact, and verifiable improvement.
Make observation records reproducible
“Feels awkward” is not enough to reproduce an experience issue. Record device, entry point, steps, state changes, and whether the user can continue.
| Record field | Example |
|---|---|
| Environment | iOS Safari, slow network, keyboard input |
| Entry point | Membership page → Upgrade → Payment |
| Failure state | Payment times out while the order remains processing |
| Evidence | Recording, analytics event, accessibility tree, support record |
Product and Technical owners can then assess impact and repair priority.
Hand off the same UX path through development
Keep one reproducible path as a UX issue moves through requirements, design, development, and testing.
| Development step | Input or artifact | Experience question | Handoff |
|---|---|---|---|
| Requirements review | User task, flow diagram, target user | What must the user do while waiting, failing, and recovering? | Define task states and open questions |
| Design handoff | Prototype, copy, breakpoints, design system | Are empty, error, loading, keyboard, and mobile states designed? | Save state map and interaction notes |
| Development integration | State model, components, API error codes | Can the UI reliably show feedback and preserve input and focus? | Record state changes, telemetry, and reproduction entry |
| QA verification | Build, device, browser, assistive technology | Can the user see feedback, understand the next step, and recover? | Recording, steps, accessibility tree, defect link |
| Post-release review | Funnel, support records, user feedback | Does the same friction recur in real use? | Update risk, owner, and acceptance criteria |
For payment waiting, Product, Development, and QA can share a state table:
| State | What the user should see | What the user can do | Acceptance evidence |
|---|---|---|---|
| idle | Amount, payment method, and submit conditions | Check details and submit | Screen recording, keyboard path |
| submitting | Clear submission progress and button state | Wait without submitting twice | Network log, button state |
| processing | Order is processing, with next step or lookup entry | Stay or leave safely | Order state, UI copy |
| timeout | Timeout status and whether to wait or contact support | Look up, retry, or exit | Slow-network recording, duplicate-click record |
| success | Payment result and benefit-delivery state | View benefits or order | Order and UI state comparison |
| failure | Reason and an actionable recovery path | Correct details and retry | Error linkage and focus position |
The state table can become component acceptance criteria: link error text to its field, move focus into a dialog and return it on close, prevent duplicate submission while loading, and retain safe form content after navigation. Accessibility and mobile behavior affect whether users can complete the same task.
The following observation is hypothetical. It shows how to turn “the flow feels stuck” into a reviewable input and does not claim the current product has this issue.
stage: test-reporting
environment: iPhone Safari / slow network / VoiceOver enabled
task: Recover membership upgrade after payment timeout
steps:
1. Open the membership upgrade page and submit payment
2. Delay the payment callback until the client times out
3. Return to the order page, then reopen the upgrade page
observed:
- The page shows an error but does not say whether an order was created
- VoiceOver does not announce the processing state
- The address field is empty after returning to the upgrade page
evidence:
- checkout-timeout.mov
- order-status-response.json
- repro-steps.md
user_impact: User may pay twice or abandon the flow and re-enter details
inference: Failure recovery information, status announcement, and form retention need confirmation
action: Add an order lookup entry, announce status, retain safe fields, and review keyboard behavior
owner: Front-end lead / Product lead
status: pending
confidence: mediumReviewers should also check whether screen readers announce error copy, focus reaches the field that needs correction, narrow screens obscure status messages, and slow networks make it clear that work is still in progress. Each check needs an interface, prototype, recording, accessibility tree, or run record; impressions alone cannot close it.
Adaptable prompt
Use the ux-quality-perspective Skill.
Stage: test report review (test-report-review)
Task: Review checkout feedback, error recovery, keyboard use, copy, and mobile behavior
Version and environment: [requirement / build / environment]
Inputs: [file paths or links]
Scope: [included and excluded journeys]
Constraints: [accounts, data, time, compliance]
First check whether the UX perspective applies. Report summary, facts, evidence, findings, risks, information gaps, questions, actions, and confidence. Record task flow, state, device/browser, input method, accessibility setup, and screenshots/recordings/reproduction steps. Without UX evidence, use not_applicable or evidence_gap; do not report code correctness, test pass, or release approval.Check whether users can continue after failure
Experience problems often appear in failure states: can a user avoid paying twice after a timeout, retain an address after validation fails, and understand what to do after an API error? Check the start, wait, failure, recovery, and completion states for each key task.
These conclusions need evidence from a real task, such as a prototype, analytics, usability observation, or support record. Without it, state a risk assumption rather than claiming that the experience is good.
Who should use this Skill
Design and Product can use it to review task flows and failure states; QA can make experience issues reproducible; front-end and accessibility owners can plan focus, feedback, and recovery fixes. Without task material, keep the result as a risk assumption.
Review UX evidence before handoff
| Review item | What to retain | If missing |
|---|---|---|
| Task and flow | Start, goal, key path, and failure-recovery path | Record the flow gap; do not invent interactions |
| State and feedback | Loading, success, failure, empty state, focus, and errors | State which evidence is missing |
| Use conditions | Device, browser, viewport, input method, and accessibility settings | Do not generalize one device observation |
| UX evidence | Prototype, screenshot, recording, accessibility tree, reproduction, or user observation | Mark evidence_gap or not_applicable |
| Impact and action | User impact, owner, fix, and confidence | Separate fact, inference, and recommendation |
stage: test-report-review
applicability: applicable / not_applicable / evidence_gap
task: [user task]
flow: [start, wait, failure, recovery, completion]
state: [observed interface state]
device_browser_input: [device, browser, viewport, input method]
accessibility: [screen reader, keyboard, focus, or other condition]
evidence: [screenshot, recording, prototype, accessibility tree, or reproduction steps]
experience_impact: [user impact]
action:
owner: [owner]
next_action: [next step]
confidence: high / medium / lowInstall and invoke
Install the individual Skill. The series overview carries the longer installation explanation.
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-workflows/ux-quality-perspective -gInvoke it with “Use the ux-quality-perspective Skill,” then attach the real artifacts.
Common questions
Can I review UX with screenshots alone?
Screenshots show a visual state, but do not prove waiting, keyboard, screen-reader, or recovery behavior. Add an interactive prototype, recording, or direct observation where possible.
What if there is no user research?
Use task flows, analytics, support records, and accessibility checks, while marking which claims are observations and which need user confirmation.
How do I know an experience issue is fixed?
Repeat the same entry and failure path. Confirm the user sees feedback, understands the next step, and can recover; retain review evidence.
Can a UX conclusion replace functional testing?
No. It adds task-flow and perceived-quality evidence. Functional, API, and security checks remain separate.
Run UX Quality Perspective on a real checkout path and retain device, state, evidence, and review notes. The example provides structure; project evidence must come from the project.
References
- Awesome QA Skills project:https://github.com/naodeng/awesome-qa-skills
- Awesome QA Skills series overview:https://inaodeng.com/en/blog/ai-testing/introduction_of_awesome_qa_skills/
- Awesome QA Skills: UX Quality Perspective Skill source:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-workflows/ux-quality-perspective
- UX Quality Perspective Skill details:https://inaodeng.com/en/qaskills/ux-quality-perspective/