How usability testing works
You give somebody a realistic task — find the price for this service, book an appointment for next week, work out whether you deliver to their town — and you watch them try. You do not explain the site, you do not hint, and you do not defend it. You ask them to think out loud, and you write down every place they pause, misread something or take a wrong turn.
It can be moderated, with you present and asking questions, or unmoderated, with the person recording themselves while working through instructions. Either way the value comes from the same source: watching the attempt rather than asking for an opinion. What people say about a website and what they do on it are frequently different, and only one of the two costs you enquiries.
Why usability testing matters
Everybody who built the site knows where everything is, which makes them the worst possible judge of whether it can be found. Testing replaces that blind spot with evidence, and it does so before money is spent driving traffic to a page that does not work.
It explains things numbers only report. Analytics can tell you that people leave the booking page; a person talking through their confusion tells you it was the date field, or the word you used for a service that customers call something else. That kind of finding is usually cheap to fix and immediately useful.
It needs very little traffic, which makes it the right method for sites that cannot support formal testing. A new business with few visitors can still learn a great deal from a small handful of honest attempts.
Where usability testing goes wrong
Testing on colleagues is the usual shortcut, and it fails because they know the offer, the jargon and the layout. The next fault is leading: asking whether the button was easy to find teaches you nothing, because most people will say yes to be polite. Set the task and stay quiet.
Testing on the wrong device matters more than people expect. If your customers arrive on mid-range phones over mobile data, a test conducted on a laptop over office broadband will miss the problems that actually cost you enquiries. And a session that turns into a demonstration, where you rescue the participant every time they stall, produces a pleasant conversation and no findings at all.
How to act on it
Start with one task that matters commercially, recruit people who resemble your customers rather than your team, and run the session on the device they would really use. Record what they do if they agree to it, note the exact moment of each hesitation, and resist explaining until the task is over.
Fix the problems that stopped somebody completing the task first, then the ones that merely slowed them down. Re-test after the changes, because fixes create new confusion often enough to be worth checking. Pair the findings with session recordings to see whether real visitors behave the same way, and feed the conclusions into the build rather than the backlog — this is the cheapest input available to web design and development work, and the easiest to skip.