Reframing the problem
If we only ask: How can we complete a usability test?
The more useful question: Which design assumptions need checking while changes are still possible? Place testing within development so findings can inform the next design.
The initial request
Some teams start discussing usability when a product is nearly fixed: recruit users, run tasks, and produce a test report. A finding at that stage may affect hardware, software, instructions, and training together.
I bring another question into the discussion: which design assumptions remain untested, and when should we examine them? That changes the timing, tasks, and outputs of the study.
My role
I work on developing the practice, designing methods and proposals, delivering key projects, and preparing the team. This includes turning relevant standards into project steps, designing tasks and records, and coordinating manufacturers, testing organizations, and researchers.
This work is carried out through Noldus. I also contribute functional definitions and methodological input to usability-engineering software. The full output of the team and product is broader than my individual contribution.
How I approach it
We first map users, environments, tasks, and potential use errors, then identify what the current evaluation needs to answer. While the design can still change, we look for confusion, errors, and assistance, and bring findings back to design discussions.
A pilot checks whether equipment, task wording, or the setting interferes with observation. During execution, video timestamps connect actions with participant accounts and researcher judgments. The report separates what happened, possible causes, and what needs another check.
Gaze or other measurements are added when they answer an additional question. Task design and analysis of the actual error remain essential.
What the work has produced
The practice has served 25+ medical-device companies and related institutions across ventilators, monitoring equipment, surgical devices, and IVD. Experience feeds into study plans, recording templates, training, and later evaluations. I also maintain an internal index of standards and cases for preparation and source lookup.
This page describes my scope and approach. Individual results, device details, raw records, and regulatory files are confidential. Service counts do not establish a product’s safety or submission outcome.
- InsightDefine the assumption to examine
- Design ⇄ ObserveReturn feedback while changes are possible
- ConfirmationCheck whether the question was answered
Insight → Design & observation in a loop → ConfirmationConceptual model
