Your product doesn't need a redesign. It needs a diagnosis.

A redesign is proposed roughly the way a house move is proposed during a bad week. Something is wrong, the specific cause is unclear, and starting over feels like decisive action. It is decisive. It is rarely diagnostic.

The pattern is consistent enough to predict. Metrics plateau. Leadership asks why. Nobody has an evidenced answer, so the conversation moves to what everyone can see, the interface, and a redesign gets scoped. Eighteen months later the product looks current and the numbers are approximately where they were.

A redesign changes the visual and interaction layer. Most serious product problems do not live there.

• Information architecture that models the database rather than the job
• A core workflow that requires knowledge the interface never supplies
• Content and terminology that assume familiarity users do not have
• Missing states, empty, partial, failed, stale, that make the product feel unfinished
• Service breaks outside the product: onboarding emails, billing, support handovers
• Two teams owning two halves of one journey with no agreed standard between them

A visual redesign leaves every one of these intact and repaints them. The new version is prettier and equally hard to use, which is the worst possible outcome because it also consumed the political capital that a real fix would have needed.

What a diagnosis actually involves

Diagnosis is not a workshop where the team lists frustrations. It is a structured attempt to establish what is happening, why, and what each problem costs: using evidence that can settle an argument.

Behaviour before opinion

Start with what people do. Analytics for shape, session replay for texture, support tickets for language. Support tickets are the most under-read research asset in most companies: they have been resolved individually and never read as a body. Cluster two years of them and the same six workflow breaks appear in the customers' own words.

Tasks, not impressions

When you do speak to users, give them a task and watch. Asking what someone thinks of an interface produces a design critique from an untrained critic. Asking them to complete a real job produces evidence.

Severity is a commercial measure

Rate findings by what they cost: abandoned tasks, support contacts, extended sales cycles, compliance exposure, churn signals. A cosmetic inconsistency on a high-traffic screen may matter less than a broken permission state that three enterprise accounts hit weekly.

The useful output is not a report. It is an agreed account of the problem that survives contact with the leadership team, plus a sequenced plan separating quick fixes from structural work from strategic bets.

In our experience a meaningful share of value in a typical audit sits in changes that require no visual redesign at all: restructuring navigation, rewriting content, designing missing states, fixing a broken handover between two teams. Those ship in weeks.

Redesigns get relitigated for months because nobody agreed what was broken. A diagnosis ends the argument before the work starts.

Sometimes it genuinely is. When the visual language actively misrepresents the company, an enterprise-grade product that looks like a side project, an identity built for a market you left. When accessibility failures are systemic rather than local. When the design debt means every new feature costs more than the last.

The difference is that in those cases you can say precisely what the redesign is for, and what you expect it to change. If you cannot finish the sentence 'we are redesigning because…' with something measurable, you are not ready to start.