Usability Testing Before Redesign: What to Validate First

A product manager at a 180-person B2B SaaS company kicked off a six-month redesign of the core reporting flow. The design team spent three weeks on wireframes. Engineering estimated nine sprints. The project shipped. Six months later, support tickets about the reporting flow were up 40%.

The friction was in a step no one had tested before the rebuild. The redesign addressed things the team assumed were broken, not what users were actually struggling with.

Usability testing before redesign prevents this. Not as a formality, but as the specific act of mapping which interactions fail, where users stall, and which assumptions the team is carrying into the build. This article gives you the checklist and the reasoning behind it.

Why Pre-Redesign Testing Gets Skipped Even When Teams Know Better

Teams skip usability testing before redesign for one reason: getting results takes too long. Across the industry, 63% of teams cite time and bandwidth as their top challenge in user research (2025 industry data). When redesign planning is already underway, adding a multi-day research cycle feels impossible.

The result is a predictable failure mode: insights arrive after the roadmap is locked. By then, the design is already directionally committed and the team is optimizing details rather than validating structure. A practitioner in a September 2025 usability tool discussion noted that getting enough usable results from a traditional panel can take 2-5 days per study. Across four flows, that timeline makes pre-redesign testing impractical.

This is the exact problem pre-redesign testing is designed to prevent, which means the question is not whether to do it but how to do it fast enough to matter.

What Usability Testing Before Redesign Reveals That Stakeholder Feedback Doesn’t

Usability testing before a redesign identifies which specific interactions cause friction, not just that friction exists. Stakeholder feedback gives you opinions about what to change. Pre-redesign testing gives you evidence of where the current flow fails and, equally important, where it doesn’t.

Across the industry, 39% of research studies are now run by PMs without dedicated researcher support (2026 industry research). That means most pre-redesign validation is happening without someone who has a protocol for what to test. Teams run one session, catch one obvious problem, and treat it as sufficient.

A structured pre-redesign testing process answers four different questions. Each one shapes a different category of redesign decision.

Four Questions Usability Testing Before Redesign Must Answer

Before any design work begins, your testing should answer:

1. Where do users stall in the current flow? These are the moments where navigation breaks down: users look at the screen and don’t know what to click next. Map every stall point in the existing flow before designing around them.

2. Which labels and UI patterns confuse users? Confusion about terminology, iconography, and navigation labels is the most common source of friction in mature B2B products. Identify these specifically so the redesign replaces them with something clearer, not just something different.

3. What do users try to do that the current design doesn’t support? Observe workarounds: export sequences, copy-paste workarounds, and repeated back-navigation. These signals point to missing functionality or misconfigured information architecture that the redesign needs to address directly.

4. Which friction reflects the design vs. the underlying concept? Some friction is fixable with better UI. Other friction comes from the product model itself. Knowing the difference before a redesign saves you from rebuilding the surface while leaving the structural problem untouched.

These four questions produce a friction map: a prioritized list of what is broken and what is not. The redesign should be constrained to fixing what the friction map identifies.

The Flows Worth Testing Before Any Redesign

Not every flow needs pre-redesign testing. Focus on the ones that carry the highest conversion, retention, or support cost.

Onboarding and activation path. First-run experience is the highest-leverage flow in any B2B SaaS product. If you are rebuilding onboarding, test the current state against new-user personas before designing the replacement. A designer at a 200-person B2B SaaS company configured a new-user AI persona and found that the activation step everyone assumed was clear stalled most users at the CTA: the button was visible, but users did not understand what completing it would do.

Core workflow. The primary task users return to the product to perform. Test completion rate, time-on-task, and where users reach for help or abandon the flow.

Navigation and information architecture. Card sorting and tree testing reveal structural problems, but an AI persona running real tasks will surface navigation failures faster because it shows what users do when they cannot find what they are looking for.

Error and edge case handling. Test what users do when the flow does not proceed normally: incorrect input, empty states, permission errors. Redesigns that skip error handling ship new problems alongside new layouts.

How to Run Pre-Redesign Usability Testing Without Waiting for Participants

Tessary runs AI personas on your current live URL instead of recruiting participants. You configure a persona that represents your target user (role, product familiarity, goals, patience level), assign the task you want tested, and get structured findings in minutes: where the persona hesitated, what it missed, what it tried that did not work.

For pre-redesign testing, this means you can map friction across all four flows before a single design decision is made. No recruiting overhead, no scheduling delay, no waiting for results that arrive after the roadmap has already locked.

The need for faster validation is real: 91% of designers now report working faster in AI-enabled environments, yet only 15% feel much more confident in the quality of their output (2026 industry research). Teams are redesigning more often and faster, without proportionally more validation grounding each rebuild. Traditional panel-based testing, which can take several days per study, makes that gap worse.

If you want to understand how to fit this into a sprint cycle, the article on running usability tests in a two-week sprint covers the workflow in detail.

Map Friction Before the First Design Session

The consistent failure mode in redesigns is starting from assumptions instead of evidence. Teams rebuild flows that were working and leave broken ones untouched because no one tested the current state before committing to a direction.

Usability testing before redesign does not require a research team or a long lead time. It requires knowing which four questions to answer and a way to answer them before the roadmap locks.

Tessary is free to start, no credit card required.

Try Tessary on your current flow before your next redesign. Configure a persona, paste your live URL, and get friction findings before your first design session.