Product design / Practical notes
What Evidence Should a UX Audit Collect Before a Redesign?
A useful audit helps a team choose what to change. Collect enough evidence to explain the problem, reproduce it and separate a known defect from a question.
Begin with a question the evidence can answer
I begin with a decision the team needs to make. For example, is a delivery flow confusing because a state is missing, a label is unclear or the live service is failing?
Those explanations need different evidence. A screenshot can show wording and hierarchy; a recorded task or implementation check can show what happens after the action.
Collect complementary evidence
| Source | What it can establish | What it cannot establish alone |
|---|---|---|
| Observed task | What happened in that session | How common it is across all users |
| Product analytics | Recorded event patterns | Why the person acted that way |
| Support material | Reported friction and vocabulary | The experience of people who never contacted support |
| Interface inspection | Visible structure and behavior | A measured business consequence |
| Technical logs | Recorded failures and timing | The person's understanding of the failure |
Attach provenance to each finding
Capture the build or environment, role, viewport, starting state, steps and result. Add a screenshot or recording only when it helps another person inspect the observation. Remove personal and client data from the version that will be shared.
Keep the original observation separate from the interpretation. For example: the save failed and the form cleared is an observation; people will abandon because of this is a hypothesis unless further evidence supports it.
Use a reproducible finding format
- Task: what the person was trying to do.
- Observation: what actually happened and where.
- Consequence: what was blocked, lost or made ambiguous.
- Evidence: source, date and reproduction steps.
- Confidence: confirmed, observed once or needs reproduction.
- Next decision: repair, investigate, accept or redesign.
End with a decision-ready pack
Group findings by the decision they inform. Several navigation symptoms may share one naming problem; a failed integration may need an engineering repair rather than new screens. The point is to narrow the redesign question, not make the issue count impressive.
For portfolio work, be equally careful about evidence. A Figma screenshot can demonstrate a proposed hierarchy. It cannot stand in for an observed usability session or a shipped outcome. Keeping those categories separate makes both the audit and the case study more credible.
Follow the same task across its states
The Zapp driver next-stop and completion designs describe different moments. Progress toward a stop is separate from a completed handoff, and payment records are a further responsibility.
The screens help define the questions for an audit. They do not tell us that a delivery occurred. Keep the observed result and the next test attached to the same finding.
