UX Torture Test

Epistemology: prove observable user harm, not aesthetic opinion.

An agent turned loose on a UI can generate infinite "this could be cleaner" commentary. This skill reports defects and friction only when tied to a real user goal and evidence.

Read references/CONSTITUTION.md first.

The evidence gate

A defect or friction finding requires:

1. User goal — what the user is trying to accomplish.
2. Observed obstruction — the exact thing that blocks, confuses, misleads, or increases error risk.
3. Consequence — abandonment, lost work, wrong action, repeated effort, uncertainty, exclusion, or recovery cost.
4. Evidence — concrete viewport, zoom, content, state, input method, network condition, sequence, or runtime observation.
5. Reproduction path — precise steps and environment.

If all five cannot be supplied, classify it as a research hypothesis or discard it. Do not soften opinion into a defect.

Phase 0: Define user objectives and critical journeys

Identify:

• primary user roles;
• first-time and returning-user goals;
• top critical journeys;
• irreversible/destructive actions;
• financially or operationally sensitive steps;
• important recovery paths;
• known analytics/drop-off evidence if available.

Define success for each journey before judging friction.

Phase 1: Reconnaissance

Map:

• routes/screens and journey transitions;
• responsive primitives and breakpoints;
• shared components and tokens;
• forms and mutations;
• state/data ownership;
• overlays, navigation, menus, focus behaviour;
• loading/error/empty patterns;
• localisation and RTL support;
• browser/runtime test setup;
• known accessibility utilities and automated checks.

Inspect implementation and run the interface where possible.

Phase 2: Journey friction pass

Trace critical objectives end to end as a first-time user and, where relevant, a returning user.

Hunt for:

• unnecessary decisions;
• premature information requests;
• repeated entry;
• unclear next action;
• terminology drift;
• weak system status;
• hidden prerequisites;
• dead ends;
• forced context switching;
• destructive ambiguity;
• lost work;
• recovery requiring refresh or restart;
• success states that fail to establish what happened next.

A friction finding must pass the evidence gate. If the consequence depends on user preference or behaviour that has not been observed, mark it RESEARCH HYPOTHESIS.

Phase 3: State completeness and transition integrity

Inventory meaningful user actions and data views. Map only applicable states:

• idle;
• hover/focus/active;
• pending;
• success;
• failure;
• partial success;
• retry/recovery;
• disabled and reason;
• first-use empty;
• filtered empty;
• no-permission;
• failed-to-load;
• stale;
• offline;
• interrupted;
• conflict.

Do not merely check that states exist. Test transitions:

ready → action → pending → acknowledgement → persistence → reconciliation → feedback → recovery

Ask:

• Can repeat action duplicate effects?
• Can success appear before durable success?
• Can failure lose user input?
• Can retry duplicate work?
• Can partial success be distinguished from total failure?
• Can stale/conflicting data be recognised?
• Does navigation interruption leave ambiguous outcome?
• Is disabled state explained when action is expected?

Phase 4: Environmental torture pass

Test strategically across combinations, not only isolated dimensions.

Conditions include, where applicable:

• 320px narrow viewport;
• mobile landscape;
• tablet;
• common desktop;
• ultrawide;
• 200% and 400% zoom;
• OS/browser large text;
• long names, emails, URLs, and unbroken strings;
• localisation expansion;
• Unicode, emoji, and non-Latin scripts;
• RTL;
• empty, one-item, many-item, and huge datasets;
• zero and extreme numeric values;
• slow, failed, and missing images;
• dynamic mobile viewport and on-screen keyboard;
• safe areas/notches;
• orientation change;
• reduced motion;
• slow network;
• timeout;
• offline;
• interrupted mutation;
• back/forward navigation;
• refresh during pending action;
• stale tab;
• multiple tabs;
• expired session;
• downgraded permission where relevant.

Prioritise combinations likely to compound harm, such as narrow viewport + large text + long localisation, or slow network + repeated submit + navigation away.

Phase 5: Accessibility interaction pass

At minimum, where tooling permits:

• complete critical journeys keyboard-only;
• verify logical focus order and visible focus;
• test modal/menu focus containment and restoration;
• inspect accessible names and semantics;
• test form validation announcement and recovery;
• test zoom and reflow;
• inspect target sizes;
• verify meaning is not communicated by colour alone;
• test reduced-motion behaviour;
• inspect dynamic status/error announcement where relevant.

Automated scanners are supporting evidence, not a substitute for interaction testing.

Do not claim WCAG conformance from this skill. Use PASS WITHIN TESTED SCOPE.

Phase 6: Visual and behavioural consistency

Report consistency issues only when they create expectation mismatch or task harm.

Look for:

• same appearance, different behaviour;
• same behaviour, materially different presentation;
• inconsistent save models;
• inconsistent Enter/Escape/Back behaviour;
• token drift that causes hierarchy or affordance confusion;
• inconsistent pending/disabled/error treatment;
• responsive divergence without product reason;
• terminology inconsistency affecting comprehension.

Distinguish intentional variation from drift.

Phase 7: Browser/runtime orchestration

For each critical journey, build a small torture matrix combining:

• viewport;
• content extreme;
• network state;
• session/permission state;
• input method;
• interruption/navigation condition.

Record exact environment and result.

Use browser developer tools where available to inspect:

• console errors;
• network requests and retries;
• duplicate requests;
• response timing;
• storage/session state;
• layout shifts;
• accessibility tree;
• focus order.

Static review should generate hypotheses. Runtime testing should prove or disprove them.

Phase 8: Verification and prioritisation

Re-run High-impact findings from a clean state. Preserve screenshots, recordings, traces, or exact steps where possible.

Prioritise using:

• user harm;
• frequency/reach;
• journey criticality;
• recoverability;
• exclusion/accessibility impact;
• business consequence.

Separate:

• CONFIRMED DEFECT
• HIGH CONFIDENCE
• RESEARCH HYPOTHESIS
• NOT TESTED

Report format

# UX Torture Report — [surface/flow]

**Status:** WITHSTANDS WITHIN TESTED SCOPE | HARM FOUND | PARTIAL
**Declared scope:** [...]
**Critical journeys tested:** [...]

## Torture matrix
| Journey | Environment/state combination | Result | Evidence |

## Findings

### [Severity] · [Journey / State / Environmental / Accessibility / Consistency] · [title]
- **User goal:** [...]
- **Obstruction:** [...]
- **Consequence:** [...]
- **Evidence:** [...]
- **Reproduction:** [...]
- **Fix:** [...]
- **Confidence:** Confirmed | High Confidence | Research Hypothesis

## State coverage gaps
[...]

## Research hypotheses
[...]

## Not tested
[...]

## Retest plan
[Exact journeys and conditions to repeat after remediation.]

Anti-patterns

• The opinion generator.
• Aesthetic drift disguised as user harm.
• Happy-path-only testing.
• Checking states without testing transitions.
• Testing dimensions individually when the failure comes from combinations.
• Vague reproduction such as "mobile is bad."
• Claiming accessibility conformance from a limited pass.
• Treating a research hypothesis as a confirmed defect.