Usability testing shows whether people in the target audience can accomplish their tasks in a product and what gets in their way. A working button and a correct API response establish functionality. Yet a person may not find the button, may misunderstand the final price, or may abandon the form. These are separate, observable quality problems.
QA contributes knowledge of scenarios, states, and errors. Testers help prepare reproducible conditions, identify technical causes of difficulties, and verify fixes. However, an experienced tester's opinion does not replace observing actual or likely product users.
Start with a specific question
Research should answer a concrete question: does a new customer understand delivery terms, can an operator correct an error, or can a person find the required document? A broad question such as "is the website easy to use?" turns a session into a collection of general impressions.
Describe the audience and context: experience, device, time constraints, language, and assistive technologies. Someone who uses the system daily approaches a task differently from a newcomer. Examine their results separately where useful; an average can conceal different causes of difficulty.
Tasks without hints
Describe the user's goal rather than a click sequence. Instead of "open Delivery and select courier," say "you need your order delivered home after work; find a suitable option." This checks whether the interface and required information are understandable and discoverable.
Prepare realistic data and define completion. For a purchase, this may be the test order confirmation screen rather than an actual payment. The expected result describes an achieved goal; do not restrict acceptable paths in advance to the interface author's preferred route.
Participants and conditions
Recruit people from the segment being studied, rather than only available colleagues. Before the session, check the device, environment, account, and prototype limitations. A broken prototype link may look like a comprehension problem if observers do not know about it.
Obtain informed consent for recording and agree on material storage. Use test data when real data is unnecessary for the research question. Explain that the product is being evaluated: anxiety and a desire to "pass the test correctly" change behavior and the quality of observations.
The moderator's role
The moderator presents a neutral task, observes, and clarifies actions through open questions. Thinking aloud helps reveal expectations but also affects speed. Timings from such sessions therefore cannot be compared directly with ordinary work without accounting for the method.
Avoid pointing out the button at the first pause. If help is needed to continue, record when and what assistance was given. Completion with assistance differs from independent success. "What did you expect to see at this step?" is more neutral than "why didn't you click here?"
What data to collect
Define measurement rules before starting and apply them consistently to all participants. Otherwise, a disagreement over results becomes a disagreement over what the team meant by success.
- →Completion: independently, with assistance, partially, or unsuccessfully.
- →Time: from presenting an understood task to the agreed completion point.
- →Errors and recovery: incorrect actions, backtracking, lost data, and the need for support.
- →Understanding: what the person believes the outcome is and which conditions they can explain.
There is no universal rule that a task must take three clicks. Criteria depend on the task, risk, and product baseline. An additional confirmation can prevent a costly mistake in a complex operation.
Practical example: rescheduling an appointment
A service lets users reschedule a visit without calling. The research question is whether new users understand that changing the time replaces the previous appointment. Prepare a test profile with an appointment and several available slots.
- 1.Ask the person to move the appointment to the next available evening. Do not name the section or action. Expect them to discover an appropriate path independently.
- 2.Observe time selection and final confirmation. Record whether the person sees the old and new times and can explain the operation's consequences.
- 3.After completion, ask them to show the current appointment. Expect one active appointment at the chosen time and clear confirmation of the change.
- 4.In a separate attempt, trigger a controlled save error. Expect a clear state: the original appointment is preserved, the user can retry, and they understand the result.
If someone completes the flow but believes they now have two appointments, formal success conceals a comprehension problem. Checking understanding therefore complements observing clicks.
Distinguishing causes
When difficulties arise, compare behavior with technical data. A button may be hard to notice, unavailable because of a validation error, or visually active before the API has loaded. These are different problems even if the participant describes each as "unclear."
Screen recordings and request timelines help establish causes, but avoid turning the session into live debugging in front of the participant. Preserve context and investigate the technical details afterward. Separate observations from hypotheses about causes in the report.
Assessing findings
Record the goal, action, difficulty, consequences, and evidence. "Three participants did not notice the final fee before confirmation" is more useful than "bad design." Include frequency within the observed group and potential harm without presenting a small sample as a precise estimate for the entire audience.
Priority depends on more than frequency. A rare irreversible action may need fixing before a frequent unnecessary navigation step. Quantitative comparisons between versions require comparable groups, identical tasks, and an adequate measurement plan; qualitative research alone does not provide that.
Mistakes and verifying improvements
Common mistakes include testing colleagues instead of the audience, teaching the interface through task wording, arguing with participants, and collecting only satisfaction scores. Positive feedback after an unsuccessful attempt does not negate the observed problem. Nor can accessibility be considered verified simply because one person finds a scenario easy.
After a change, repeat the problematic scenario and check adjacent paths. Improvement means more confident goal completion under agreed conditions. The outcome is verified difficulties, their consequences, and evidence that helps the team choose and verify a specific fix.