How to test your website redesign with real users
The fastest way to test a website redesign is to put the new design in front of 6–8 target users before go-live, give them the same real tasks on the old and new versions, and compare completion and hesitation. Two short rounds catch the regressions a launch-day analytics dip would only confirm.
There’s a ready-made template for this — skip to itThe method: an old-vs-new usability test before go-live
A redesign is one of the most expensive changes a website ever goes through, and it usually ships on faith: months of work, one launch day, and then a nervous week watching analytics. The test below moves that verdict earlier. You give 6–8 people from your target audience the same handful of real tasks — the three to five things the site exists to make happen — on both the current site and the redesign, and you watch where each version helps and where it hurts. To be clear, this isn't a QA pass: broken links and rendering bugs belong to your dev checklist. This test answers the question QA can't — can people still **do things** on the new site, and did the new navigation, labels, and layout make those things easier or harder?
One honest caveat about what you'll hear: people initially prefer whatever they already know. Existing users will grumble at any change for the first few minutes — researchers call it change aversion, and it fades; genuine usability regressions don't. That's why this method leans on behavior over opinion: a participant saying "I liked the old one better" is weak signal, but six of eight participants failing to find pricing under its new label is a finding you fix before launch, not after.
Pick the 3–5 tasks the redesign must not break
Pull them from what the site is actually for: find pricing, contact sales, locate a product, start a trial, find support docs. Your analytics and support tickets will tell you the top ones. Write each as a scenario ("You're comparing tools for your team — find out what this costs"), never as a route ("go to the pricing page") — routes test obedience, scenarios test the design.
Recruit a mix of fresh eyes and existing users
6–8 people total. Fresh eyes — people who match your audience but have never seen either version — tell you whether the new site explains itself. A couple of existing users tell you what the redesign silently moved or removed that regulars depend on. Screen out colleagues and anyone who worked near the redesign; they can't un-know the new structure.
Run the same tasks on old and new, alternating which goes first
Each participant attempts the same tasks on both versions, thinking aloud. Alternate the starting version across participants — half see the old site first, half the new — so practice doesn't flatter whichever design comes second (running the same task twice makes the second attempt faster no matter which design it's on). The redesign can live on a staging URL or a Figma prototype; it doesn't need to be live.
Probe hesitations, then ask for a preference with a reason
Right after the tasks, walk back through the moments they stalled: what were you looking for, what did that label mean, where did you expect that to be? Only then ask which version made the tasks easier — and don't accept "it looks nicer." A preference only counts when it comes attached to a specific task moment.
Compare per task, fix regressions, retest before go-live
Score each task on each version: completed, struggled, failed. Any task where the new design loses to the old is a launch blocker — that's the regression your post-launch dip would have been. Fix those, re-run the same tasks with fresh participants, and ship when new beats or matches old on every task that matters.
What to measure
- Task completion, old vs new — same task, both versions — did the redesign help, hurt, or tie?
- Time on task — where the seconds pile up on each version, not just the total
- First-click accuracy — did their first click land on the right path? First clicks predict task success better than almost anything else
- Findability of moved items — can people locate what the redesign renamed or relocated?
- Hesitation points — pauses over ~5 seconds, pinned to a page and element
- Comprehension of the new homepage — can a first-time visitor say what the site offers, unprompted?
- Preference with a reason — which version they'd choose, and the specific moment behind it
- Change-aversion signals — complaints about unfamiliarity ("where did it go?") vs. genuine dead ends — the first fades after launch, the second doesn't
- 1. Walk me back through that task on each version. Where did you slow down, and what were you looking for at that moment?— Ask this before anything specific — it surfaces the friction they remember, in their words, before you plant yours.
- 2. You were trying to find [the thing they struggled with] — where did you expect it to be on the new site? What made you expect that?
- 3. In your own words, what does this company do, and what would you do here first?— Asked on the new homepage with fresh-eyes participants. Redesigns often trade clarity for polish — this catches a homepage that got prettier but stopped explaining the business.
- 4. Which version made these tasks easier for you — and what, specifically, was easier?— The word "specifically" does the work. "It's cleaner" is an aesthetic vote; "the menu names matched what I was looking for" is a finding.
- 5. Is there anything from the old site you'd miss if it disappeared tomorrow?
- 6. If you landed on the new site for the first time with no task from me, what would you click first, and why?
What’s in the ready-to-run study
This is the exact study Sera drafts when you paste your current URL and your redesign link below. Every piece is editable before launch.
Website redesign usability test
Moderated · Think-aloud · Live URL or Figma prototype
Screener
4 questions that admit your target audience with a deliberate mix — mostly fresh eyes who've never seen either version, plus a couple of existing users — and reject professional testers and anyone connected to the redesign.
Tasks
3 scenario-based tasks run on both versions, with the starting version alternated per participant, plus a conditional follow-up that triggers when a participant abandons a task on the new design.
Interview questions
6 post-task questions with probe instructions — the AI moderator digs into the hesitations it actually observed on each version and pushes past "it looks nicer" to the task moment behind every preference.
Participants & timing
N = 8 recommended — enough to see every serious regression twice across both versions. 20–25 minutes per session. Recruit-to-readout is typically 24–72 hours on the Sera panel, same-day with your own list.
Try this template
See your redesign through your users' eyes — before it goes live
Paste both links — the AI drafts your full old-vs-new study in ~2 minutes. You review everything before it runs.
- Works with live URLs and Figma prototypes
- First 7 interviews free
- No credit card required
How it works in Sera
1 · Paste your flow
Drop in the live URL or Figma prototype. Sera reads the flow, drafts the screener, tasks, and questions, and shows you the whole study for review.
2 · Interviews run
Participants attempt the task on their own device while the AI moderator watches, listens, and probes hesitations in real time. You can sit in on any session.
3 · Readout, cited
Friction moments ranked by how many participants hit them, each linked to the exact clip. Share the readout; skeptics can click through to the evidence.
Frequently asked questions
How do you test a website redesign before launching it?
Give 6–8 target users the same real tasks — find pricing, contact sales, locate a product — on the current site and the redesign, and compare completion, first clicks, and hesitation per task. The redesign can run from a staging URL or prototype. Any task where the new design loses to the old is a launch blocker.
Should I A/B test my redesign instead of usability testing it?
They answer different questions. An A/B test tells you which version converts better after launch, and needs thousands of visitors to say so. A usability test tells you why the new design helps or hurts, with 6–8 people, before launch. Most teams usability-test first to fix regressions, then A/B test to confirm the numbers.
How many users do you need to test a website redesign?
6–8, as long as they match your audience. Serious problems repeat fast — if five of eight people can't find pricing under its new label, the ninth won't change the conclusion. Since each person tries both versions, eight participants gives you sixteen task runs per task to compare.
Can I test a redesign that isn't live yet?
Yes — that's the ideal time. Point the study at a staging URL or a Figma prototype of the new design while the current live site plays the "old" side. Testing before go-live is the whole point: you fix the regressions while they're still cheap to fix.
Why do users say they prefer the old website design?
Mostly change aversion — people initially favor whatever they've already learned, and the reaction fades within days of launch. That's why preference alone is weak evidence in a redesign test. Trust behavior instead: if users complete tasks faster on the new design while saying they miss the old one, ship it.
What tasks should I use to test a website redesign?
The three to five things the site exists to make happen — check your analytics for top user journeys and your support inbox for what people fail to find. Phrase each as a scenario with a goal, not a route: "you're evaluating this for your team — find out what it costs" beats "go to the pricing page."
Keep reading
Find out why people abandon
your website redesign — this week.
Paste your URL, review the study Sera drafts, and watch the first interview yourself.
Your first 7 interviews are on us — no credit card required.