Discovery Interface Usability Testing

Far fewer than people expect. Nielsen's problem-discovery model shows that the probability of catching a given usability problem rises sharply with each user, so roughly five to eight participants per user group typically surface the majority of serious problems. The point of the method is efficient problem discovery, not statistical estimation, so adding many more users yields diminishing returns; it is usually better to spend that effort on additional iterations, testing again after fixes, than on enlarging a single round. When precise prevalence estimates are needed, a survey is the right tool instead.

They answer different questions. Usability testing observes a small number of users performing concrete tasks to discover specific interface problems and measure task success, time, and errors, behavioral, diagnostic, and interface-focused. A satisfaction survey such as LibQUAL collects attitudinal ratings from a large representative sample to gauge overall service-quality perceptions and gaps. Testing tells you why users fail and what to fix; the survey tells you how the user population feels about the service at large. Strong library UX programs use both, with testing driving redesign and surveys tracking aggregate perceptions.

Because the purpose is to see what the interface supports on its own. The moment an observer nudges a participant toward the right facet or explains a label, the design's failure to communicate that on its own is hidden, and the success metric becomes a measure of the observer's help rather than the interface's usability. Disciplined non-intervention, paired with a think-aloud protocol so confusion is verbalized, is what makes the findings honest. Help and explanation belong in a later debrief, after the task data have been collected, not during the task itself.