Usability Testing Before Redesign: What to Validate First

Most redesigns we see start from a stakeholder list, not an evidence list. Someone hates the nav. Someone else has a screenshot of a competitor. Sales wants the upgrade modal moved. The team kicks off a six-month project and then discovers, after launch, that the friction was in a step nobody had thought to test.

Usability testing before redesign is the step that separates “what people complain about” from “what users actually fail at.” The two lists overlap less than most teams expect.

The reason this step gets skipped

Recruiting. The UserTesting State of UX survey lists recruiting as the hardest phase of any study at 47%, and the 21-day average from study design to findings is mostly the recruiting and scheduling pieces. The User Interviews 2025 Research Budget Report puts 29% of teams under $25,000 a year for everything. Pre-redesign testing is the easy thing to cut when those two numbers collide with a roadmap deadline.

So teams skip it, build against the loudest assumption, and learn what was actually broken from support tickets after launch. The redesign ships, the metrics do not move, and a second round of fixes follows.

What usability testing before redesign is supposed to answer

Four questions, not one. The redesign brief should not start until each has an answer grounded in a real session, not a meeting.

1. Where do users stall in the current flow? Stalls are the moments where someone looks at the screen and does not know what to click. These are the spots most teams already feel but cannot point to with evidence.
2. Which labels and patterns confuse them? Vocabulary drift accumulates in mature B2B products. Buttons get renamed, sections get moved, and the language slips out of sync with what users call the same thing.
3. What are users trying to do that the product does not support? Repeated back-navigation, copy-paste workarounds, and weird export sequences are signal. They point at missing functionality the redesign should add or absorb, not at things to repaint.
4. Which friction is the design, and which is the underlying model? Some friction goes away with a better screen. Some is structural and a redesign cannot fix it. Knowing which is which before the rebuild keeps the team from repainting a flow that was always going to confuse the user.

The output is a friction map. The redesign brief should be constrained to what the map says is broken.

Which flows actually warrant a check before the rebuild

Not every flow earns one. Test the ones where a wrong assumption is expensive.

Onboarding and first-session activation. The flow with the highest leverage on retention. If onboarding is on the rebuild list, run the test against the current state with a new-user persona before any wireframe.

The core task path. The two or three actions a target user repeats every session. Time-to-task and abandonment points here predict where the redesign will help or hurt most.

Navigation and information architecture. Card sorting answers structural questions. A persona running a real task answers the more useful one: what does someone do when they cannot find what they came for. Both are worth running before the IA gets locked.

Error and edge-case states. Empty states, permission errors, malformed input. These get cut from redesign scope and ship as new versions of the same problems. The pre-redesign session is where they get added back to the list.

What “fast enough to matter” looks like

Speed is the constraint. A redesign brief usually wants the friction map within a week, not a month. Two recent shifts make that possible.

The Maze Future of User Research 2026 report cites 63% of teams reporting faster turnaround from AI tooling, and the share of organizations treating research as essential to all business decisions tripled from 8% to 22% in a year. Demand has gone up. Headcount has not. Teams are looking for ways to shorten the cycle without dropping it.

The Nielsen Norman Group’s classic comparison of moderated and unmoderated testing puts unmoderated at 20 to 40 percent cheaper, with about 20 hours saved on facilitation. The math holds, but only if recruiting works. When the panel is cold, the cost difference is not what you are choosing between.

Where AI personas fit

Tessary runs an AI persona against the current live URL or staging build in a real browser. You configure the persona by role, expertise, and the context the user would actually bring (a finance lead reviewing a renewal, an admin auditing permissions, a new user signing up cold). The persona runs the task and returns structured findings: where it hesitated, what label it misread, where it tried the wrong path first.

For pre-redesign testing, the value is in running it across all four flows on the same day. You get the friction map before the design brief is written, instead of after the wireframes are signed off. For sprint-cadence tests after the redesign ships, the continuous usability testing post covers the per-sprint setup.

We do not yet know how often a persona’s findings will disagree with what a moderated session would have caught on the same flow. The pattern we see is that the persona surfaces the same kind of structural friction that shows up in support tickets a month after launch. For the redesign brief, that is usually the directional answer the team needs.

Run the friction map before the first design session

Paste your current production or staging URL, configure a persona that matches your target user, and read the findings before the redesign brief is written. Tessary is free to start, no credit card.

Try Tessary on your current flow