This article is written as a working review tool rather than a universal formula. Apply the parts that match the product, evidence and constraints in front of you.
Audit first when the diagnosis is vague
If the brief is “the product feels dated” or “users seem confused,” an audit can separate visual debt from workflow, content, accessibility and implementation problems.
That prevents a visual refresh from preserving the same structural friction in cleaner components.
Audit first when the product has history
Long-lived products accumulate exceptions, permissions and workflows that are easy to miss in a greenfield redesign. Reviewing the current experience exposes the behavior users and support teams have already learned.
The goal is not to preserve every legacy choice. It is to understand the cost of removing or changing it.
Skip the broad audit when one failure is already clear
If a single high-value flow is demonstrably broken and the evidence is strong, a focused redesign may be more useful than auditing the entire product.
Do enough surrounding review to understand dependencies, then spend the effort on the decision that matters.
Use the audit to define redesign boundaries
A useful audit should identify what needs structural change, what can be fixed inside the current system and what should remain untouched.
The result is a smaller, more defensible redesign scope rather than a license to rebuild every screen.
Leave with priorities, not a presentation
The final output should connect evidence, severity, affected task and recommended next step. A deck full of annotated screenshots is not enough if nobody knows which decisions should happen first.
The best audit makes the next product conversation more specific.