Usability testing starts with who will try to accomplish what, in which context, and what will count as completion or difficulty. Opening a prototype for available people and asking for opinions is insufficient. You need to observe behaviour around a relevant task while accounting for prototype limits and moderator assistance.
If a product serves both customers and staff, do not treat them as one role. A customer may be choosing an appointment for the first time; a coordinator may handle exceptions throughout the day. Staff familiarity with internal terminology does not establish customer understanding.
Translate the product question into recruitment criteria
Write the question first: can a new customer select a suitable appointment and understand its status? Then specify relevant experience, task language, typical device and access needs to support. Age or job title may matter, but cannot replace a connection to the task.
A User Research study requires eligible participants and a skilled moderator, not simply a list of names. Confirm recruitment feasibility, consent and participation arrangements before approving delivery dates. If only the design team is available, use them to rehearse the session, not as evidence about target users.
Do not promise that a fixed participant count will expose every issue. Roles, tasks and contexts affect study design. Research can be divided into rounds, but each round needs explicit questions and coverage. A small round should not become a claim to represent the entire audience.
Write tasks as goals, not instructions for clicking
“Find an appointment that fits these circumstances” is different from “click Book Now and select the branch.” The latter supplies part of the answer and can conceal a discoverability problem. GOV.UK recommends realistic task goals that do not hint at the solution. Moderated-testing guidance.
For every task, prepare an internal sheet the participant will not see: starting state, acceptable outcome, what the prototype genuinely supports, when intervention is allowed and how it will be recorded. If a session skips an unfinished screen, document the skip rather than reporting independent end-to-end completion.
Define whether the study is about first use, repeated use or recovery after an interruption. A returning participant who has learned the interface can provide useful evidence for repeat use, but should not silently substitute for someone encountering the journey for the first time.
Worked hypothetical example: professional appointment booking
A fictional business tests appointments for a non-medical professional consultation service. New customers and appointment coordinators are separate groups. The purpose is to identify obstacles in defined journeys, not establish market demand for the service.
| Task | Participant context | Observation focus |
|---|---|---|
| Select an appointment | New customer needs an evening slot at a suitable branch | Can they distinguish branch and time, and recognize that the request awaits confirmation? |
| Change a request | Customer has a test request and changed availability | Can they find the route and understand its effect on status? |
| Resolve a conflict | Coordinator has two requests for one time | Can they identify and act on the right request without changing another? |
Use controlled test data and reset the environment before each session. Do not let the first participant consume the last available slot and then compare later participants against a different situation. Real customer names are unnecessary to make a test account credible.
Suppose a participant reaches submission but believes the appointment is already confirmed. Correct clicking is not the same as understanding the outcome. Ask what they expect to happen next and record their interpretation without teaching them the answer. The issue may concern status wording rather than button placement. User Experience Design can then propose a revised flow or content treatment for testing.
Another participant may fail because the prototype link is broken. That is evidence about test readiness, not evidence that customers cannot understand the journey. Keeping the categories separate protects both the design decision and the credibility of the report.
Prepare the environment before using participants’ time
Run the tasks internally with an account equivalent to the participant account. Check links, records, starting states and recovery routes. Software Quality Assurance can verify the relevant functional readiness so sessions do not become investigations into broken sign-in.
A UX/UI Audit may identify obvious obstacles worth fixing first or hypotheses worth observing. Do not label those expert observations as user findings. They remain a different source of evidence even when they concern the same screens.
Where the study includes assistive-technology users, agree devices, combinations and necessary support. W3C explains that involving users complements standards evaluation rather than replacing it. User involvement in accessibility evaluation. One successful participant does not establish suitability for every access need, and the study is not a compliance certificate.
Specify task-level evidence
Record the version, date, participant role, task, point of difficulty, assistance and outcome. Distinguish independent completion, assisted completion, non-completion and tasks that cannot be evaluated because of environment failure. These distinctions prevent a headline success percentage from hiding what happened.
Link each finding to task consequence, observed recurrence, limits and a proposed response or further question. Frequency alone should not determine priority. A less frequently observed issue that blocks a critical task may warrant early action, provided the reason is explained.
Study-readiness checklist:
- Roles, groups, languages and devices are specified and justified.
- Recruitment does not reward prior interface knowledge.
- Task wording does not reveal the controls whose discoverability is under test.
- Accounts and data return to a known state for each session.
- Consent, accommodations, assistance and recording are agreed.
- Reporting separates product issues from prototype and setup failures.
Frequently asked questions
Can we test an incomplete prototype?
Yes, if its limits fit the questions and remain visible in analysis. Do not infer a complete journey works from a small clickable fragment.
Can one person test Arabic and English?
That may suit a language-switching question, but repeating a task can teach the route. Design and report the comparison so learning effects are clear.
Is a participant’s visual preference enough?
Not when the study concerns task completion. Record preferences as opinions and observe behaviour and understanding separately.
When should testing pause for a fix?
Agree stop conditions such as environment failure or a barrier that makes remaining tasks unevaluable. Record the reason and revised version before restarting.
Prepare the journeys, questions and test version first. Then recruit people whose experience can provide the evidence the decision actually needs.
