A team can agree on every screen of a booking service and still disagree about whether it works. The designer knows why the options are grouped together; the engineer knows what happens after submission; the customer arrives with neither explanation. Usability testing brings that last perspective into the room by asking people to attempt realistic tasks while the team observes what happens.

The useful evidence often sits between an apparently successful click and an apparently satisfied answer. Someone may reach a confirmation screen without noticing that they booked the wrong date, or abandon a task they could have completed because they no longer trust the price. Watching the attempt lets a researcher examine those differences instead of treating completion as a simple yes or no.

What usability testing can tell you

Usability testing examines how people use a particular design in particular circumstances. It can reveal misunderstood language, missing information, difficult interactions and places where the product behaves differently from what someone expects. It can also measure outcomes such as successful completion, errors and perceived ease, provided the study defines and records them consistently.

It does not establish demand merely because participants manage to use the product. A person can complete a carefully assigned task without ever wanting to do it in daily life. Questions about the underlying need belong alongside evidence from user interviews, existing behaviour and other research; questions about the interaction belong in the test itself.

GOV.UK’s guidance on moderated usability testing describes the central arrangement: people try tasks, and a researcher observes. Keeping that arrangement intact takes more discipline than it sounds, particularly when the observer helped build the design.

Give people a reason to use the design

Start with the decision the study needs to inform. “Test the new website” leaves almost everything open. “Find out whether occasional visitors can choose the right ticket and understand the refund conditions” gives recruitment, tasks and analysis a common purpose.

Imagine a fictional theatre testing its booking journey. A useful task might ask someone to arrange an evening out for a group that includes a wheelchair user, with a fixed budget and a possible change of date. The scenario creates reasons to examine accessibility information and ticket conditions without instructing the participant where to click. Whether that scenario is appropriate depends on the intended audience: participants should have relevant experience, and the study should include people whose access needs the service must support.

Before recruitment, decide what a successful outcome would contain. Buying any ticket is different from buying suitable tickets, understanding the total cost and knowing what can be changed later. A well-written task scenario gives participants a goal while leaving the route to them.

Choose the format around the uncertainty

Moderated testing puts a researcher in the session, allowing follow-up questions and practical support. Unmoderated testing asks participants to work through instructions independently, which makes the wording and technical setup especially consequential. Either format can produce observations or measurements; the presence of a moderator does not decide whether the sample supports a numerical claim.

For a new interaction, a small exploratory round can identify problems worth changing. Estimating a success rate precisely or comparing versions requires a study designed for that purpose, including a suitable sample and treatment of uncertainty. Avoid turning “four of five participants struggled here” into an estimate of how four-fifths of all customers behave.

Separate the observation from the explanation

In the theatre example, a participant might repeatedly open the seating plan while looking for access information. Record the sequence and what they say before deciding that the navigation label is at fault. They may expect accessibility details to sit beside seats, misunderstand the wording elsewhere, or need information the website never provides.

A finding becomes useful when it connects that evidence to a consequence and a next decision. “The page was confusing” gives the team little to act on. “Participants could select seats but could not establish whether the route to them was step-free” identifies a specific unanswered need. The next design can address that need, and a further test can show whether the change helped.