Watch someone use your website before you ask whether they like it
Usability testing asks people to complete realistic tasks on a website while you observe what happens. Start with the decisions the site needs to support, use neutral prompts and record actions separately from opinions. The useful output is a prioritised set of evidenced problems and proposed changes.
Put the advice into practice
Give your next major prospect a clearer reason to choose you
Plan the content, design and enquiry pathways around the work you want to win.
Discuss your website projectChoose tasks that matter to the service journey
Asking whether someone likes a website can reveal a preference, but it may not show whether they can find the right service or complete an enquiry. A task makes the interaction observable. You can see where the person starts, what they expect and where the route becomes difficult.
Choose tasks around real responsibilities: checking whether a service is suitable, finding a relevant project, locating a document or understanding what is required before contacting the team. Include direct arrivals on important service pages, rather than starting every task on the homepage.
Use a small set of priorities for a session. A long tour can turn into a demonstration, particularly when the facilitator wants to show everything the design includes. The purpose is to observe the participant’s route.
Write prompts without revealing the answer
| Leading prompt | More useful task |
|---|---|
| Open Services and choose Risk Reviews | Your organisation needs an independent review before renewing an agreement. Find out whether this firm could help. |
| Click the case studies button | Find an example that would help you assess experience with a comparable brief. |
| Use the contact form below | You have decided to discuss a project. Show how you would make contact and what you would send. |
| Find the downloadable capability statement | You need to share a summary of this organisation with a colleague. Find something suitable. |
Give enough context for the task to make sense, without inserting the navigation label or desired route. If the service is specialist, recruit people who can reasonably assess the situation or acknowledge the limits of using stand-ins.
Ask participants to describe what they are looking for as they work. Avoid turning that request into constant questioning that distracts from the task.
Observe without becoming the navigation system
Before the session, explain that you are assessing the website, rather than the participant. Give permission to stop or express uncertainty. Ask consent for any recording and handle the resulting information under the organisation’s agreed process.
During a task, allow a reasonable pause before intervening. If someone asks whether a choice is correct, a neutral response such as “What would you do if I were not here?” can help preserve the observation. Note where assistance was necessary rather than counting the task as independently completed.
Do not request real confidential material in a test enquiry. Provide a harmless scenario and test information. Check beforehand that submitting the form will not create an unwanted customer record, notification or booking.
Separate the observation from your interpretation
| Record | Hypothetical example |
|---|---|
| Task and context | Assess suitability for an independent supplier review on mobile |
| Observed action | Participant opened About, returned, then used search |
| Participant explanation | Expected “Reviews” to be under the team’s credentials |
| Interpretation to investigate | Service label may be ambiguous |
| Proposed change | Test a more specific service label and revised summary |
| Priority and owner | Core enquiry route; content lead and designer to review |
“The navigation is confusing” combines an observation and a conclusion. Recording the actual route makes the finding easier to discuss and retest. One participant’s difficulty can identify an issue worth investigating, without proving every visitor will behave in the same way.
Prioritise by consequence and recurrence. A blocker preventing contact deserves different treatment from a minor preference about an illustration. Consider the importance of the affected task and the effort needed to check a proposed change.
Retest the change and retain other checks
After a revision, repeat the task with a suitably neutral prompt. Look for whether the original difficulty has changed and whether the new design introduces another issue. Keep the evidence attached to the decision so later discussions do not revert to unrecorded opinion.
Include people with relevant access needs where possible. W3C’s guidance on involving users explains why user evaluation complements standards-based accessibility checks. A few successful sessions do not establish accessibility conformance across the website.
Usability sessions work best alongside content review, keyboard and assistive-technology testing, technical checks and reliable enquiry measurement. Each answers a different question. Together they give the team a more defensible basis for deciding what to improve.
If a website is being redesigned, agree the priority tasks early in the design scope. They can guide the structure and provide a useful basis for reviewing the finished pages.
