How do you audit an existing design before redesigning it?

Published Read 4 min read

On this page

A useful audit assesses the current design against user needs, goals, and performance, cataloguing what works, what fails, and why, across usability, consistency, accessibility, and outcomes, so that the redesign is grounded in evidence about real problems rather than in assumptions or taste. The method has a name: diagnose before you prescribe. The instinct to avoid is skipping the audit and starting from a fresh vision, because a redesign launched from vision alone fixes the problems you imagined and leaves untouched the ones users actually have.

The reason diagnosis has to come first is that you cannot solve a problem you have not located, and the problems a design actually has are rarely the ones a designer assumes by looking at it. A screen can be visually awkward and still convert fine, or look clean and quietly leak users at a step nobody examined. Without an audit, a redesign is a bet that your taste happens to align with the real failure points, and that bet usually loses, because taste sees surface and the failures live in behavior. Auditing replaces the bet with evidence: it tells you which parts of the current design are doing real work and must be preserved, which parts are failing and why, and which parts are simply different from current fashion but causing no harm. That last category matters as much as the others, because an audit grounded in needs and outcomes keeps you from spending the redesign budget on things that merely look old.

A real audit works across several dimensions rather than one. On usability, you watch what users actually do, where they hesitate, where they backtrack, where they abandon, and you read the support tickets and search logs that record their frustration in their own words. On performance and outcomes, you pull the metrics that the design exists to produce, conversion, completion, time on task, drop-off by step, and you find where the numbers fall short of what they should be. On consistency, you inventory the components and patterns and note where the same problem is solved different ways, since inconsistency is both a user cost and a maintenance one. On accessibility, you test against real standards, color contrast, keyboard navigation, screen-reader behavior, focus order, because a redesign that ignores this just reships the same exclusion in a newer skin. Then you assemble the findings into a catalogue: each item paired with evidence and a reason, what works, what fails, and why it fails.

Picture a signup flow about to be redesigned. The audit does not start with a new layout; it starts with the data. Analytics show forty percent of users drop at the email-verification step. Session recordings reveal they never see the “resend code” link because it sits below the fold on mobile. Support tickets confirm “I never got the code” is the top complaint. Accessibility testing finds the error message is announced to screen readers but the field that caused it is not, so users cannot tell which input failed. That catalogue tells the redesign exactly what to solve: surface the resend path, tie errors to fields, fix the verification friction. A vision-first redesign might have produced a beautiful new flow that moved the resend link somewhere equally invisible, because nobody had diagnosed where the bleeding was.

The qualifier is that an audit is scoped to diagnosis, not to designing the cure, and it should resist jumping to solutions while the evidence is still being gathered, because a premature fix in mind biases what you choose to look at. An audit can be over-scoped too: spending months cataloguing every pixel when a focused look at the metrics and the top failure points would have pointed the redesign in the right direction faster. The aim is enough evidence to know the real problems, not a complete encyclopedia of the old design.

So before you redesign anything, audit the current design against user needs, real performance, consistency, and accessibility, and write down what works, what fails, and why, with evidence behind each claim. Diagnose the actual problems first, then let that catalogue, not a fresh vision, set the agenda for the redesign. An audit finds the real problems a redesign should solve, and skipping it only guarantees you will redesign around the wrong ones.

Related posts:

  1. How do you keep contrast intact across both light and dark mode? You keep contrast intact by verifying it separately in each theme, because a color pairing that passes in light mode can fail in dark and the reverse, so each mode......
  2. How do you keep a design intact through development without micromanaging? A design survives the build when intent is communicated clearly up front, the developer genuinely understands the why behind it, and review focuses on outcomes against that intent rather than......
  3. When should you roll out a redesign gradually vs all at once? Roll out a redesign gradually when the change is high-risk or high-traffic and you need to measure its impact, catch problems before they reach everyone, and give users time to......
  4. Should you build a color system from one hue or several? Start from one hue and expand only when the product proves it needs more. A single-hue system, built from one color stretched across tints, shades, and a neutral ramp, reads......
  5. Why do some palettes look great in the design tool but wrong in the live product? Palettes that look great in the design tool can come out wrong in the live product because context changes color. On the artboard a palette sits on an empty canvas......
  6. When should headings get their own typeface vs share the body’s? Default to one family for both, and give headings their own typeface only when the brand genuinely needs a distinct voice at display sizes and you can pair the two......
  7. When does centering content help readability vs hurt it? Center short, symmetric content like a headline or a single call to action, and left-align anything that is actually meant to be read. Centering helps when the content is brief......
  8. When is a near-black better than pure black for text and backgrounds? A near-black is the better default for most text and surfaces, while pure black should be reserved for moments you deliberately want at maximum contrast. A slightly off-black, a very......
  9. Why does justified text often read worse on the web than left-aligned? Justified text reads worse on the web because of how browsers achieve the flush edge: they stretch the spaces between words to push each line out to both margins, and......
  10. When does breadcrumb navigation actually help vs add clutter? Breadcrumbs help on deep, hierarchical sites where users need to see and climb the path they came down, and they add clutter on flat sites where there is no meaningful......
  11. Why do users abandon a flow that’s only one step too long? Users abandon a flow one step too long because motivation drains across every step, and the extra step is the one that finally crosses below the threshold where staying feels......
  12. What makes a “back” action predictable vs a trap? A back action is predictable when it returns the user to exactly the state they expect with their context and input preserved, and it becomes a trap the moment it......
  13. What does a good empty state do that a blank screen doesn’t? A good empty state orients the user and hands them a first action, while a blank screen leaves them stranded with no context and no path forward. That is the......

Leave a comment

Your email address will not be published. Required fields are marked *