UX Product Audit
A UX Product Audit examines representative workflows, roles, states and implementation evidence to identify what should be fixed, researched, redesigned, modernised or accepted.
- Product evidence
- Workflow diagnosis
- Decision queue
The unit of review is a product condition
It is useful when a product team can see friction but cannot agree on its cause or sequence. The audit does not begin by scoring screens. It begins with the product decision, the affected work and the consequence of being wrong.
A local interface issue may result from unclear ownership, fragmented information, an inconsistent rule or a missing recovery path. Tcules follows representative work across the interface, product model and implementation evidence far enough to locate the condition that creates the visible symptom.
The sample is agreed before review. It can focus on one critical workflow, a role boundary, a new capability or a cross-product pattern. The audit states where the sample cannot support a broader conclusion.
Bring
Bring product access, intended users, current concerns, known evidence, representative data, relevant analytics or support themes and the decision the audit must inform.
Receive
- scope and evidence record;
- finding-to-decision ledger;
- consequence and confidence;
- structural versus local diagnosis;
- action disposition and owner;
- validation recommendation;
- first release or research sequence where appropriate.
The decision queue distinguishes quick correction from structural work. It also identifies what should remain unchanged. Removing low-value recommendations is part of producing a usable result.
Finding-to-decision object
- 01
Fields
Each finding records the observation, source, affected condition, consequence, confidence, diagnosis, decision, owner and validation.
- 02
Use of examples
Representative examples and client findings use distinct labels so methodology examples are not confused with client-specific findings.
The related guide explains how to commission and use the result.
Evidence and confidence stay beside the recommendation
Findings may draw on product access, representative content and data, analytics, support material, user or stakeholder evidence and implementation inspection. Tcules records whether a conclusion is observed, reported or inferred.
A recommendation with incomplete evidence includes the next validation step rather than a stronger adjective.
Portfolio relevance
The Scissors case records heuristic review followed by stakeholder and user research that informed broader object-oriented workflow redesign. It supports moving from observed friction to structural diagnosis.
The Dealpath case records a deliberately selective change inside established software. It supports the audit principle that the correct outcome may be a bounded intervention rather than a product-wide redesign.
AI may increase coverage, not certainty
Start with the decision the audit must change
Bring product access, representative roles and data, available evidence, known constraints and the decision the team is currently unable to make. Tcules can then bound the sample and state what the audit can credibly establish.
Start with the product decision
Share the decision your team is currently unable to make so the audit sample can be bounded around credible evidence.