Web App Redesign Checklist: What to Audit Before You Touch a Pixel

Key takeaways

• Most failed redesigns skip the audit and ship a fresh skin over broken flows.
• Run four parallel audits: behaviour data, qualitative research, code and design debt, accessibility plus performance.
• Lock a design system migration plan before any new screen ships, or you will live with two systems forever.
• Ship behind feature flags with cohort rollout and a rehearsed rollback.
• Define success metrics in week one. If you cannot name the number that proves the redesign worked, do not start.

Every web app redesign starts the same way. The dashboard looks dated, support tickets repeat themselves, a competitor shipped something prettier, and somebody on the leadership team is asking why the product cannot feel like Linear. Six months later, half of these projects ship a coat of paint and the metrics that mattered have not moved. Before you brief a designer or open Figma, run a pre-redesign audit that tells you what is broken, what is loved, what costs money to keep, and what you cannot change without breaking power users. The checklist below is what our web application development team walks through before quoting a redesign.

Why most web app redesigns underperform

A redesign is a product change with effects on conversion, onboarding, support load, training cost, and renewals. Treat it as a Figma exercise and the rest of the system fights back. Engineers ship new screens on top of a tangled component library, navigation gets reshuffled without telling sales, and NPS dips because power users cannot find the export button. Two patterns show up in almost every salvage job we take on. The team had no baseline metrics, so they cannot prove the new version is better. And they did the visual work in isolation from engineering, so the design system rollout stalls at 40 percent and the codebase grows a second set of components instead of replacing the first. Both are preventable with a written audit, which is the point of a web design engagement that respects the existing product. Our notes on web app design contract questions pair well with this checklist.

The pre-redesign checklist (use this in order)

Run the seven audits below in sequence. Analytics and research feed every later decision, so do not let design start until those two are written up.

1. Analytics audit: prove what people do in the product

Pull the last 90 days of product analytics and answer five questions in writing. What are the top 10 actions by frequency? Which flows generate the most support tickets? Where do free users drop out of activation? Which features are used by under 2 percent of paying accounts? Which screen has the highest exit rate that is not a logout? If your team cannot answer these, you have a measurement problem before a design problem. Lock baseline numbers for task completion time, weekly active accounts, activation rate, and any revenue-linked event, then pin the dashboard somewhere boring. Teams building SaaS products often find their event tracking has decayed, which is itself a finding.

2. User research: stop guessing about pain

Run 8 to 12 interviews with a mix of power users, recent churners, and trial users who never converted. Walk them through tasks the analytics flagged as expensive. Do not show mockups. Find the gap between what people are trying to do and what the product makes easy. Triangulate with heatmaps and session recordings from Hotjar, FullStory, or PostHog. The output is a short document naming the top 10 friction points, the jobs the product is hired to do, and one sentence per persona. This is the brief the design lead works from. If your in-house team is light here, our guide to hiring a design team covers how to staff the gap.

3. Technical debt review: find the load-bearing mess

Get every developer who shipped to the codebase in the last 12 months into a two-hour session. List files they are afraid to touch, components with three slightly different versions, and API endpoints no one is sure are still used. Cross-reference with static analysis and a dependency audit. Sort findings into three buckets: must fix before redesign, fix as we touch the screen, document and leave alone. Skipping this is how teams rebuild the same modal for the third time. If you are weighing extension versus a fresh start, the trade-offs in our MVP versus full product strategy piece apply.

4. Accessibility audit against WCAG 2.2 AA

Run an automated pass with axe or Lighthouse, then a manual screen reader review on the 10 most-used screens. WCAG 2.2 added criteria automation cannot catch: 24 by 24 CSS pixel target sizes, focus appearance, dragging alternatives. Document each failure with severity, screen, and owner. Anything that blocks keyboard or screen reader use is a redesign blocker, not a backlog ticket. For products in healthcare, fintech, or education, get this signed off before design opens. The WCAG 2.2 reference is the source of truth.

5. Performance baseline and Core Web Vitals

Capture field data from real users, not just lab tests. Core Web Vitals targets at the 75th percentile are LCP under 2.5s, CLS under 0.1, INP under 200ms. INP replaced FID in March 2024 and is stricter, measuring responsiveness across the whole session. Pull a month of CrUX data, segment by route, and pair it with a bundle analyzer pass and a slow query log. Web apps usually fail INP first because hydration and client state pile up after page load. Set a written budget: 200 KB of gzipped JavaScript at first paint, 400 KB route ceiling. The web.dev INP guide is the clearest reference. Treat performance as downstream and the new design ships slower than the old one.

6. Design system migration plan: the one most teams fumble

Pick your design system position before design starts: extending, replacing, or migrating from no system to a real one. Build a parity matrix listing every current component, its planned replacement, and the migration path. Components without a replacement are the highest risk: build them, drop the features that need them, or postpone those screens to phase two. Lock token strategy early so colour, spacing, typography, radius, motion, and elevation live in code with Figma libraries generated from them. That shared language is what lets engineers and designers ship in parallel rather than in sequence. A website development handoff fails or succeeds on this decision. Our notes on custom development pricing show how design system maturity changes the bid.

7. Rollout strategy: ship cohort by cohort, not big-bang

The riskiest moment in a redesign is the cutover. Default to a phased rollout behind feature flags: internal team for a week, then 1 percent of accounts, then 10 percent, then 50 percent, then everyone. Each gate has pass and fail criteria from the baseline in step one: no regression in activation rate, no increase in p95 latency, no spike in support tickets per 100 sessions, Core Web Vitals at or above the old version. Rehearse the rollback on production before launch week. Pair the rollout with an in-app announcement, an opt-back-to-classic toggle for 30 days, and a feedback widget that writes into a triage queue. Our deployment strategy for mobile apps piece covers the same pattern from the mobile side, and LaunchDarkly's feature flag primer is a useful reference.

How to score and act on the audit

Score every finding on impact (1 to 5) and effort (1 to 5), then plot a two-by-two. High impact, low effort is phase-one. High impact, high effort is phase two with explicit funding. Low impact, low effort is the polish bucket to ration. Low impact, high effort is the kill list. Lock phase-one in a one-page document with success metrics, rollout gates, and the date you pull the plug if gates fail. Teams needing outside help often bring in a fractional product lead or a staff augmentation partner.

What this should cost

Redesign budgets vary, but the audit phase does not. Most mid-size SaaS apps land in one of three tiers. Use this as a sanity check, not a quote.

The audit phase is the cheapest part of the project and the highest value. Spending 5 to 10 percent of the budget here saves 25 to 40 percent of the build cost by killing the wrong scope before it gets drawn. The Tamreeni and Rise Up Kings case studies show how this plays out on real projects.

Common ways teams sabotage their own redesign

• No success metric. If activation, time on task, or churn is not named in week one, nobody can grade the work.
• Designing without engineering. Figma files that ignore the current stack create unbuildable screens.
• One big launch. Big-bang cutovers spike support volume and erode trust.
• Ignoring export, settings, and admin screens. Power users live there and breaking them quietly costs renewals.
• Skipping the design system decision. Two systems running side by side becomes permanent.

If you are weighing redesign versus rebuild, our teardown of web apps that get the basics right is a useful gut check.

Recap

• Audit before you design. Analytics, research, tech debt, accessibility, and performance set the scope.
• Pick the design system position in week one.
• Lock baseline metrics and rollout gates in writing before any screen ships.
• Use feature flags and cohort rollouts. Rehearse the rollback before launch week.
• Spend 5 to 10 percent of the budget on the audit and save 25 to 40 percent of the build.

FAQ

How long should a pre-redesign audit take?

For a mid-size SaaS app, plan three to five weeks with two to four people part-time. Analytics and research run in parallel first, then debt, accessibility, and performance audits overlap. Design system and rollout plans get drafted once findings land. Smaller apps compress to two weeks. Enterprise apps with multiple teams take eight.

Do I need user research if I already have analytics?

Yes. Analytics tells you what happened, not why. A 30 percent drop-off could be a copy problem, a trust problem, or a missing feature. Interviews answer the why. Skipping research is the most common reason a redesigned screen looks better and converts worse than the old one.

How do I budget for accessibility if it was never scoped?

Treat WCAG 2.2 AA as in-scope for every new screen and ring-fence 10 to 15 percent of the design and build budget for remediation on screens you are not redesigning. Catching issues at design stage costs roughly a quarter of fixing them after launch.

What is the right rollout cadence?

Internal team for a week, then 1 percent of accounts for three to seven days, then 10 percent, then 50 percent, then 100 percent. Each gate needs pass criteria tied to step one's metrics. If a gate fails, flip the flag back, fix the issue, and re-enter. Plan three to six weeks even when things go well.

How do I avoid breaking power users?

Include at least three power users in the research interviews and the beta cohort. Keep keyboard shortcuts, URLs, and export formats stable. Offer an opt-back-to-classic toggle for 30 days after GA. Power users fund renewals and will tell you what you broke if you give them a channel.

If you want a partner to run the audit or take the redesign through rollout, the Brandrums team has shipped this pattern across SaaS, fintech, and on-demand products. Start a conversation on the contact page or review scope tiers on the pricing page. The audit is the cheapest week of the project, and the one that decides whether the next six months are worth it.