Your analytics can show a healthy-looking website that customers still cannot use
You launch the new site, check the traffic, and see that people are reaching the service page. Some visit the contact page. A few submit the form. Nothing looks catastrophic.
Then the phone stays quiet.
That is the gap between analytics and customer testing. Analytics can show that visitors arrived, which pages they opened, where they exited and whether a tracked action happened. It cannot reliably show that a customer read “solutions” as software rather than consulting, missed the booking link because it looked like ordinary text, or abandoned the form because the required fields were unclear.
Google’s own documentation describes Analytics data as aggregated or event-level data, with some reports using sampling and behavioral modelling depending on the report and setup. That makes analytics useful for patterns, trends and measured actions. It does not turn a clickstream into an explanation of intent. (support.google.com)
So should a small-business website be tested with real customers before launch? Usually, yes. You do not need a research department or a formal laboratory. You need a few people who resemble the customers you want, realistic tasks, and somebody willing to watch without rescuing them too quickly.
Test before launch because fixing confusion is cheaper than explaining it later
The best time to test is when the structure and wording can still change. That might be a clickable prototype, a staging site or a nearly finished build. Waiting for live traffic feels sensible because the visitors are real, but it also means you are asking real prospects to discover the problems for you.
A launch does not create usability problems. It reveals them at a higher cost.
Imagine a local commercial electrician whose new website has a page titled “Capabilities”. Analytics might show that visitors open it and then return to the home page. A recording might show several people scrolling. Neither tells you whether they were looking for emergency repairs, checking whether the company works in warehouses, or trying to find the service area.
A short test can. Give a likely customer the task: “You have a power fault at a warehouse. Find out whether this company can help, where it works and how you would contact it.” Then stay quiet. If the person asks what “Capabilities” means, that is evidence. If they search for emergency work in the navigation, that is evidence. If they reach the contact form but hesitate over what to write, that is evidence.
This is why analytics and usability testing are complementary rather than competing methods. The UK Government Service Manual recommends combining performance metrics with user research, and specifically says analytics can help identify common tasks to test. (gov.uk)
Analytics finds the weak spot; customer testing explains the failure
| Criterion | Analytics after launch | Real-customer testing before launch |
|---|---|---|
| Best at showing where people leave | Strong. Funnels, page exits and events reveal patterns across many visits. (better) | Limited. A small test is not designed to estimate overall drop-off. |
| Best at showing what people misunderstood | Weak. A click or exit rarely explains the person’s interpretation. | Strong. You can hear the language people use and watch where they hesitate. (better) |
| Best for checking whether a call to action is findable | Useful after enough traffic has accumulated and the action is tracked correctly. | Strong before launch, especially when the action is important but infrequent. (better) |
| Best for measuring a change at scale | Strong when the same event is measured consistently. (better) | Weak for proving population-wide lift from a small qualitative sample. |
| Best for catching a problem before prospects encounter it | None. The site must already be live and receiving visitors. | Strong. Testing can happen on a prototype or staging site. (better) |
Use analytics to choose the tasks, then watch customers attempt them
-
Choose the business-critical journeys
Start with the actions that matter commercially: finding a service, checking fit, booking, requesting a quote, calling or locating the business.
-
Recruit likely customers, not convenient colleagues
The participant does not need to be statistically representative, but should understand the problem your business solves and use the device your customers commonly use.
-
Give a task, not a tour
Say what the person wants to accomplish and why. Do not tell them which page to open or which button to press.
-
Watch before you explain
Record the words they use, where they pause, what they ignore and what they try first. A failed route is more useful than a polite opinion.
-
Fix the repeated or expensive problems first
If several people miss the same action, change the structure or wording. If one person struggles with an unusual edge case, record it without allowing it to derail the whole launch.
-
Check the live version again
After launch, use analytics to see whether the change improved the measured journey. Testing diagnoses the problem; analytics checks its reach and persistence.
A small test is useful, but it is not a vote on your conversion rate
The common advice is to test with five people. That is a reasonable starting point for finding obvious usability problems in a focused journey, not a guarantee that five people represent your entire market.
The Nielsen Norman Group recommends five participants for a qualitative usability study when the purpose is to discover problems and improve the design. (nngroup.com) The UK Government guidance gives a similar range of five to six participants for qualitative usability testing. (gov.uk)
There is an important qualification. Research by MeasuringU found that five users revealed most of the common problems in its combined data, but only thirty-eight percent of all recorded problems. It found that the first five users exposed ninety-one percent of problems affecting the most common frequency tier, while uncovering far fewer less-common issues. (measuringu.com)
That is the right way to interpret a small pre-launch test. You are looking for dangerous confusion in the main journeys, not trying to calculate the exact percentage of visitors who will complete a form. If your customers divide into very different groups, test each important group separately. A homeowner looking for a repair service and a facilities manager looking for a maintenance contract may use the same website but bring different expectations.
For a low-traffic business site, this distinction matters. You may not get enough visitors to make a reliable statistical comparison between two headlines. You can still discover that nobody understands the headline.
The practical numbers support a focused, modest test
GOV.UK, “Usability testing: qualitative studies.” The guidance recommends recruiting 5 to 6 participants for qualitative testing.
GOV.UK, “Using moderated usability testing.” Sessions usually take 30 to 60 minutes depending on task complexity.
GOV.UK Service Manual, “Usability benchmarking a website or whole service.” The guidance suggests no more than 5 tasks per participant, with up to 10 minutes per task.
MeasuringU, “Sample Size in Usability Studies: How Well Does the Math Match Reality?” Five users uncovered 38% of the 406 problems across the analysed datasets.
Baymard Institute, “E-Commerce Cart & Checkout Usability Research.” This is a large-ecommerce finding, not a forecast for a typical small-business brochure site.
Do not test every page when the real risk sits in three decisions
A small-business website rarely needs every page tested with equal attention. Concentrate on the moments where a visitor decides whether the business is relevant, credible and easy to contact.
Test the first route to a service. Can the person tell what you do without translating your preferred terminology? Test proof. Can they find an example, result, qualification or explanation that answers the concern they arrived with? Test the next step. Can they tell what happens after sending the form, making the call or requesting an appointment?
This is also where a redesign can go wrong by removing familiar paths simply because they look old. If existing customers already know how to reach a service or find contact details, preserve that route unless testing shows it creates genuine friction. The useful distinction is covered in Preserve Familiar Paths, Not Broken Friction, in a Website Redesign.
Accessibility deserves its own check rather than being assumed from a visual review. Ask people who use the site in different ways to complete a task, and test keyboard access, readable content, form labels and error recovery. An analytics report can tell you that somebody left. It cannot tell you that the button could not be reached with a keyboard or that an error message was invisible to a screen reader.
Launch with evidence, then let live behaviour refine the evidence
The sensible answer is not to choose between customer testing and analytics. Use each for the job it can actually do.
Before launch, watch likely customers attempt the few journeys that matter most. Fix language, structure and calls to action that repeatedly create hesitation. After launch, confirm that tracking is working and use the traffic data to find patterns you could not see in a small study. If a high-volume page has a meaningful exit rate, return to the task and test that journey with people who match the affected audience.
The order matters. Analytics is better at telling you where to investigate. Real customers are better at showing you what the website means to them. A website that has passed both checks is not guaranteed to convert every visitor, but it has avoided a particularly wasteful mistake: asking prospects to explain a problem the owner could have found before launch.
For most small businesses, that is enough reason to test. Keep the study narrow, use realistic tasks, write down what people actually tried to do and resist treating a small sample as a statistical verdict. The aim is simpler: make sure the important path is understandable before you send more people down it.
