Test Whether Customers Can Find Answers on Your Website

Choose one decision and verify its answer

Pick a decision customers need to make, such as whether an item can arrive before a date or whether a service covers their location. Confirm the approved answer and its exceptions with the business owner before recruiting anyone. You cannot fairly judge a participant against an unsettled policy.

Write the starting page, task, correct evidence and permitted next step on a task card. Decide what would count as independent success, partial success or failure. Keep assistance separate: a participant who succeeds after a moderator points at the footer has revealed a different experience from someone who found it unaided.

GOV.UK's moderated usability guidance recommends realistic goals and instructions that do not reveal the route. The protocol here applies that approach to buyer answers. It is not a claim that a particular number of sessions will discover every problem.

• GOV.UK: designing and running moderated usability tasks

Recruit people who resemble the intended visitors

A colleague who built the menu already knows where the answer lives. Recruit likely customers who have not learned the site, and ask about the task context before the session. Include the devices and access needs relevant to the service rather than assuming everyone uses your desktop setup.

For a business serving the US and Canada, select scenarios that match the regions you actually serve. Record the policy region independently from the participant's location. Someone browsing from Canada might be buying for a US delivery address; country alone does not determine which shipping rule applies.

Explain the session, any recording and how observations will be used. Use safe fictional purchase details where appropriate, and avoid making real purchases or requests merely to complete the exercise. Rehearse the protocol with a colleague to catch broken test links and confusing instructions before customer sessions begin.

Ask for the goal without teaching the route

Say, 'You need to decide whether this item is suitable for delivery to your address next week. Show me what you would check.' Do not say, 'Open Shipping in the footer.' The second version tests whether someone can follow instructions, while hiding whether they would recognize the route themselves.

Ask participants to describe what they are looking for and what they think a page means. Listen for uncertainty, repeated scanning and assumptions. If someone pauses, a neutral prompt such as 'What are you thinking?' is usually more informative than suggesting another menu.

Do not require an answer the website cannot legitimately provide. If timing needs a live quote, success may be recognizing that limitation and finding the correct enquiry route. A participant should not fail because the business appropriately avoids guaranteeing an unverified delivery date.

Record behavior before interpreting the cause

Record the first click, pages visited, labels interpreted, backtracking and the participant's final explanation. Separate an observation such as 'opened Services twice' from your interpretation that the menu is unclear. The distinction helps the team challenge an explanation without discarding what happened.

If you measure time, define when the clock starts and stops. Preserve incomplete or time-limited tasks as incomplete rather than dropping them from a completion average. A fast wrong answer is not a successful task, and a longer careful check may be appropriate for a complex policy.

Keep the sample size and task conditions beside any counts. Four successful tasks in six sessions is a description of those sessions, not a reliable estimate for every visitor. Use the observations to choose and test a specific design change.

Worked example: the right page, the wrong conclusion

Consider a fictional furniture store. Its approved policy says standard chairs may be returned within thirty days; made-to-order upholstery is excluded. The task asks a participant to decide whether they could return a made-to-order chair. The participant finds Returns, reads the opening sentence and says yes.

This is a comprehension failure in the illustrative scenario, even though navigation reached the correct page. The exclusion appeared below an unrelated heading, away from the broad thirty-day statement. A proposed repair is to place the exception beside the general rule and link it from made-to-order product pages.

Retest that decision with new participants. Reusing the same people can reveal whether the revised text is understandable, but they already know the answer and route. Label that learning effect instead of presenting their faster second attempt as proof of a conversion improvement. No customer sessions or commercial results are claimed in this example.

Match the repair to the observed obstacle

A label problem needs a clearer route. A hidden exception needs better placement. A missing rule needs an owner-approved content decision. An individual situation may need a person. Adding chat can be a useful additional route, but it does not settle an incorrect policy or make a broken destination work.

Test the underlying page path separately from any assistant path. If chat supplies the answer, record whether the evidence is current and whether the visitor can inspect it. Preserve a direct route for people who prefer browsing or cannot use the chat interface comfortably.

Finish with a short finding: task, observed obstacle, proposed change, owner and retest conditions. Keep screenshots or notes attached to that finding. A useful research round leaves the team knowing what to change and how to check it, rather than a vague instruction to simplify the website.

• Check whether the underlying answers exist
• Decide whether an FAQ or chat is appropriate