# UX audit report template

Duplicate this document for your review. The completed example below is fictional; replace it with your own evidence. Do not present it as a client audit or user research.

## Scope

- Product and release:
- Review date and reviewer:
- Intended audience and task:
- Roles, browsers, devices and states sampled:
- Evidence location:
- Exclusions and limitations:

## Executive decision

What should the team do first, and why? Separate supported defects from questions for research.

## Finding template

- ID and title:
- Task and reproduction conditions:
- Observation:
- Evidence (frame, screenshot, recording, story or reproduction):
- Consequence (observed or hypothesized):
- Confidence and limitations:
- Recommendation and alternatives:
- Disposition and rationale:
- Owner (assign a real person):
- Acceptance check:
- Resolution evidence and date:

## Completed demonstration: workspace invitations

Evidence is limited to the constructed interface behavior described at https://www.uxadvantage.com/articles/ux-audit/. No participants, usage metrics or client results are included. The actor is a workspace owner inviting a colleague.

### INV-01: unexplained access choice

Observation: the selector defaults to Full, with no permissions explanation.
Consequence: the interface does not provide enough information for the access decision; actual over-granting is unmeasured.
Recommendation: describe roles accurately and have product/security owners decide the default.
Disposition: resolve before routine use because access has consequential effects.
Owner: unassigned.
Acceptance: the interface accurately describes each role and the invited account receives the selected role.
Status: illustrative finding; not an executed test.

### INV-02: no explicit success feedback

Observation: the form closes; no member-list update or confirmation appears until reload.
Consequence: success is ambiguous; repeated attempts are a hypothesis.
Recommendation: show the destination address and a pending-invitation result; do not imply the colleague has joined.
Owner: unassigned.
Acceptance: result is understandable without reload, visually and with assistive technology.
Status: illustrative finding; not an executed test.

### INV-03: rejected requests clear input

Observation: rejection clears the form and displays Something went wrong.
Consequence: data entry must be repeated and recovery is unspecified.
Recommendation: retain input and explain an appropriate recovery for the actual failure.
Owner: unassigned.
Acceptance: every supported rejection path preserves the appropriate values and offers a working recovery.
Status: illustrative finding; not an executed test.

## Questions for research

Does the Add label make sense in the member-list context? Observe task initiation without telling participants which control to use. Do not classify confusion as observed until you have evidence.

## Repair order

Agree the access contract; implement confirmation and rejection recovery; revisit the wording question with research. Assign owners and verify each acceptance check on the changed release.

## Follow-up

Record what changed, what was checked, unresolved limitations, next review date, and measures that could indicate whether the experience improved. Distinguish implementation verification from measured user outcomes.