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.
Start with behavior, not opinions
Screenshots and stakeholder reactions are useful context, but they are not enough to explain why an experience is failing. Look for evidence of where people stop, repeat an action, abandon a flow, contact support or take an unexpected route through the product.
The goal is not to collect every available metric. It is to connect observable behavior to a product decision the redesign can realistically change.
Read support and sales language closely
Support tickets, onboarding calls, sales objections and customer-success notes often contain the clearest vocabulary for recurring friction. Group themes by task and consequence rather than by the department that recorded them.
If three different teams describe the same confusion in different words, that is usually more important than a single loud complaint.
Audit the states between the polished screens
Review loading, empty, error, permission, validation, timeout and recovery states. These are easy to omit from redesign presentations because they are less photogenic, which is precisely why they often survive into production as inconsistent behavior.
Record whether each state explains what happened, what the user can do next and whether their previous work is still safe.
Include accessibility and responsive evidence
Test keyboard navigation, focus order, contrast, labels, zoom, text scaling and common mobile widths. Responsive problems should be recorded as interaction failures, not just screenshots of awkward wrapping.
A desktop redesign that ignores these constraints usually postpones the hardest decisions until implementation.
Finish with a decision-ready evidence map
For each finding, capture the evidence, affected task, likely consequence, confidence level and the next design question. That gives the team a better starting point than a long list of isolated usability comments.
A good audit should make the redesign scope narrower and clearer, not simply make the problem list longer.