Blog

Author: Dr.-Ing. Marcus Jenke

HCP Recruiting for Usability Tests: Why the Wrong Participants Become a Problem

HCP recruiting for usability tests: figures representing healthcare roles

1 HCP Recruiting for Usability Tests: When the Wrong Participants Become the Problem

Usability tests are a central part of the usability engineering process according to IEC 62366-1 and an essential basis for evaluating the usability of medical devices. Accordingly, many projects put a strong focus on study design, use error analysis or the design of realistic test tasks.

One decisive success factor, however, is often underestimated: selecting the right test participants through HCP recruiting for usability tests.

In practice, a similar pattern keeps appearing: under time pressure and organizational constraints, the recruiting of healthcare professionals is often organized by availability rather than by actual relevance.

Typical consequences:

  • Studies are run with people who happen to be available at short notice
  • The differentiation of target groups remains superficial
  • Relevant contexts of use are not represented sufficiently
  • Critical differences between user groups are ignored

At the same time, the real context of use is often underrepresented. As a result, a gap between the test environment and real-world use arises before the actual study even begins.

This approach is understandable, and in many projects it is initially necessary to run studies at all. At the same time, it leads to a structural problem: the quality of the results is largely predetermined in recruiting, often without this becoming visible during the project.

1.1 Why the wrong participants are critical

The validity of usability tests depends directly on whether the people involved realistically represent the actual users of a medical device. In HCP recruiting for usability tests in particular, this fit is decisive, because clinical use situations can differ greatly.

Differences between healthcare professionals are not superficial. They affect fundamental aspects of use, such as decision-making processes, workflows or priorities under time pressure. A nurse in an intensive care unit works under different conditions than a nurse in outpatient care, and an experienced specialist makes different decisions than a resident in training.

These differences directly influence how a product is used, and therefore which use errors can occur.

If these differences are not taken into account in HCP recruiting, typical distortions arise that only become apparent after the study:

  • Critical use situations are not tested
  • Relevant use errors remain undetected
  • Optimization measures are based on assumptions that are not valid in real clinical use

This creates a deceptive validity. The usability test delivers plausible results, but it does not reflect the reality in which the product will later be used. In medical device development, this can have far-reaching consequences.

Usability engineering for medical devices

1.2 Impact on regulation and risk

The relevance of this issue is particularly clear in the regulatory context. In human factors engineering and usability validation, it is expected not only that use errors are identified and evaluated, but also that the underlying studies were conducted under realistic conditions.

Both the FDA guidance and IEC 62366-1 explicitly require that usability studies are conducted with representative user groups and in realistic contexts of use. What matters is not only that the tests are carried out, but also a traceable rationale for why exactly these participants were selected.

If these requirements are not met in HCP recruiting for usability tests, concrete risks arise. The validity of study results can be limited, regulatory questions occur more often, and in the worst case studies have to be repeated or supplemented. The effort thus shifts from a recruiting approach that initially seems efficient to considerably higher costs later in the project.

Against this background, the role of recruiting changes fundamentally. It is no longer a preparatory step, but a decisive factor for regulatory robustness and ultimately for the safety of the product.

The real blind spot

In many projects, one key point is recognized late or not at all: the most common cause of insufficient results is not the study design, but the selection of the wrong participants.

2 Why HCP recruiting for usability tests is particularly difficult

The challenges in HCP recruiting for usability tests and human factors recruiting rarely occur as isolated problems of individual projects. They are a structural issue that results from the specific conditions of the medical work environment. These conditions fundamentally distinguish the recruiting of healthcare professionals from classic UX recruiting in other industries.

A key factor is the limited availability of medical professionals. Healthcare professionals work in an environment characterized by high workload, time pressure and a consistent focus on patient care. Additional activities such as taking part in usability tests therefore always have to be integrated into existing clinical routines.

This situation is made harder by the fact that access to healthcare professionals is usually not direct. On the contrary: HCP recruiting for usability tests is often shaped by multi-level access structures. Between the people responsible for the study and potential participants there are often organizational layers such as hospital management, administrative processes or internal approvals.

Besides availability and access, the specialization of user groups is another key challenge. While target groups in recruiting are often described at an abstract level, in reality the specific work context determines how relevant the results are.

For HCP recruiting of participants for usability tests, this means: a precise differentiation of user groups is not optional, but a prerequisite for valid studies. This strong dependence on context directly affects the quality of usability tests. Only if test participants credibly reflect real workflows, decision logic and use situations can reliable insights be generated.

In practice, this results in a complex starting situation: limited availability, indirect access and high specialization act at the same time and reinforce each other. As a result, HCP recruiting can only be planned to a limited extent and often requires considerable coordination effort.

This dynamic explains why classic recruiting approaches are often not sufficient in the MedTech context. The real effort therefore lies less in recruiting itself than in building and using access structures.

Interim conclusion: three structural causes

The challenges in HCP recruiting for usability tests can essentially be traced back to three interrelated causes:
• Limited availability of medical professionals
• Indirect and often multi-level access to suitable participants
• High specialization and context dependence of the user groups
These factors do not act in isolation, they reinforce each other, and thus shape the quality of usability studies significantly.

The challenges in HCP recruiting for usability tests can essentially be traced back to three interrelated causes: the limited availability of medical professionals, the indirect and often multi-level access to participants, and the high specialization and context dependence of the user groups.

Only the interplay of these factors shows why recruiting in this environment cannot be considered in isolation. It is not a single process to be optimized, but a complex interplay of access, understanding of context and organizational integration.

Against this background, it becomes clear why many teams see HCP recruiting for usability tests primarily as an operational bottleneck. In fact, the cause lies deeper: not in execution, but in how recruiting is conceptually understood.

3 The real mistake: recruiting is treated as a task

In many projects, HCP recruiting for usability tests follows a seemingly clear and established sequence: first the need is defined, then suitable participants are sought, and in the next step the study is carried out. This approach is efficient and sufficient in many areas, especially where target groups are easy to reach and can be described in a standardized way. In the context of healthcare professionals, however, this model quickly reaches its limits. The assumption that recruiting is a clearly delimited, time-limited process step falls short here. It underestimates the structural complexity of access to medical user groups.

The real mistake lies not in individual recruiting measures, but in the underlying perspective. HCP recruiting for usability tests is often understood as a short-term task that can be “solved” within a project. In reality, it is closely tied to conditions that go far beyond the actual search process.

These include in particular established networks and contacts that have to be built up over longer periods. Relationships with hospitals, organizations and individual professionals also play a central role, as they often provide the decisive access to potential participants. As a result, recruiting in the medical context cannot be understood as an isolated process. It is part of a larger system that connects access, relationships, organizational conditions and professional understanding of context.

Intensive care nurse

International UX research approaches underline this perspective by linking the quality of studies directly to how well participants fit. If unsuitable or only partly suitable people are selected in HCP recruiting for usability tests, this causes not only methodological weaknesses but also considerable follow-up costs, for example through wrong decisions or additional study cycles.

These effects are amplified in the context of regulated products. If critical use situations are not represented by the right user groups, potential risks remain undetected. At the same time, the regulatory validity of the study can be limited if the selection of participants cannot be justified in a traceable way.

Against this background, it becomes clear that the real bottleneck does not lie in recruiting itself but in the lack of structural preparation for it. Organizations that think of HCP recruiting for usability tests only on a project basis inevitably end up in situations where they have to rely on suboptimal solutions under time pressure.

Classification: from an operational step to a strategic capability

The challenges described point to a fundamental shift. Recruiting is developing from an operational project component into an independent capability that has to be built up and maintained continuously.

While an operational understanding aims to find participants in the short term, a structural approach focuses on the long-term build-up of access. This includes stable networks, continuous contact maintenance and a differentiated understanding of relevant user groups.

No longer: “How do we find participants for this study?”,
but: “How do we make sure we have lasting access to the right healthcare professionals?”

HCP recruiting for usability tests is not an isolated process step but a structural prerequisite for valid and robust results. Put more pointedly: the problem rarely lies in recruiting itself, but in the fact that it is considered too late and too much in isolation.

4 Reframing: from recruiting to access

Against the background of the considerations so far, it becomes clear that the challenges in HCP recruiting for usability tests do not arise primarily from operational difficulties. The cause lies instead on a conceptual level: in how recruiting is understood and classified in organizations.

In many cases, HCP recruiting is still seen as a short-term task to be solved within a specific study. This perspective seems plausible at first and matches classic project logic. In the medical context, however, it regularly runs into structural limits. The real challenge is not identifying participants but gaining access to the relevant healthcare professionals.

This fundamentally shifts the focus:

The central bottleneck is not recruiting itself, but access to the right user groups.

This reframing marks a decisive turning point. While a classic understanding of recruiting is geared toward carrying out individual studies, a broader understanding puts the build-up of stable access structures at the center. It is no longer primarily about winning participants in the short term, but about ensuring in the long term that relevant user groups can be reached at all.

4.1 What changes with this shift in perspective

This shift in perspective has a direct effect on the planning and execution of usability tests. It changes not only individual processes but the underlying logic of HCP recruiting for usability tests.

The differences can be summarized as follows:

Classic approachNew approach
Focus on individual participantsFocus on access to user groups
project-based planningcontinuous build-up of networks
single study at the centerlong-term strategy
operational taskstructural capability

This comparison shows that it is not about optimizing existing processes but about a shift to a different level. Recruiting is not replaced, it is reclassified.

4.2 Why this shift in perspective is necessary

The growing complexity in HCP recruiting for usability tests can only be managed to a limited extent with classic approaches. Limited availability, indirect access and high specialization mean that short-term solutions often remain unreliable.

A strategic approach to access, on the other hand, makes it possible to address these factors systematically. Existing contacts can be expanded in a targeted way, target groups are understood in more detail, and organizational conditions can be taken into account early. This creates a more stable basis for future usability tests.

5 What does this mean in practice? First courses of action

The transformation of operational HCP recruiting into a structural capability is not a one-time step but a continuous process. At the same time, practice shows that even comparatively small adjustments in day-to-day project work can have a noticeable effect on the quality of usability tests. What matters is not to look at recruiting in isolation but to improve the conditions under which it takes place.

5.1 Build networks early and continuously

A common pattern is that HCP recruiting only starts once a study is planned in concrete terms. At that point, the necessary access to identify suitable participants is often missing. A sustainable approach starts much earlier. Networks should not be built per project but developed continuously. This is less about activating individual contacts at short notice than about building resilient relationships.

In practice, this means, for example, actively maintaining contacts from previous studies, gradually expanding cooperation with clinical institutions, and using professional events to develop access to relevant user groups. Such a network not only reduces the operational effort of future studies but also increases the likelihood of actually involving representative healthcare professionals.

5.2 Define target groups in a differentiated, context-based way

A second key lever is defining target groups more precisely. General categories such as “physicians” or “nursing staff” are not sufficient in HCP recruiting for usability tests to reflect real use situations.

For reliable results, target groups need to be described along specific contexts of use. What matters is not only demographic characteristics but above all workflows, responsibilities and levels of experience with comparable systems.

A sound target group definition therefore considers aspects such as typical workflows, use situations and the integration into clinical processes. These criteria should be reflected early in the screener, as they largely determine whether the selected participants are actually representative.

5.3 Combine recruiting channels deliberately

Another important step is not to limit HCP recruiting to individual access routes. In the medical context in particular, no single channel is enough to reliably reach all relevant user groups.

Only the combination of different approaches leads to stable results. Direct contacts provide access to real contexts of use, existing participant pools offer short-term availability, and external partners or community-based approaches create additional reach. This combination can both increase the success rate of recruiting and improve the diversity and quality of participants.

5.4 Understand recruiting as a continuous process

Perhaps the most important step is to detach HCP recruiting from the logic of individual projects. As long as recruiting is understood only as preparation for a specific study, it remains reactive and only partly plannable.

A continuous approach integrates recruiting into the ongoing development process. The aim is to build up knowledge about user groups systematically and to maintain existing contacts in the long term.

In practice, this means, for example, building your own participant pool, the structured documentation of participant profiles and regular updating of contacts. This creates a reliable basis for future usability tests and a much lower dependence on short-term solutions.

Small steps with a big effect

The approaches described show that a strategic approach to HCP recruiting for usability tests does not necessarily require extensive organizational change. Targeted adjustments in how networks, target groups and processes are handled can already bring considerable improvements.
The decisive factor lies less in the individual recruiting step than in the continuity with which access to relevant user groups is built and maintained.

The courses of action presented form a first basis for the further development of HCP recruiting in usability engineering. They do not replace a comprehensive strategy, but they show how structural improvements can be integrated step by step into existing processes.

The next section brings together the key findings of this article and places them in a broader context.

6 Outlook: where is HCP recruiting for usability tests heading?

The requirements for usability tests in medical technology keep evolving. In particular, the growing importance of human factors engineering in the regulatory context has led to clearly rising expectations for the quality, traceability and validity of studies. At the same time, access to healthcare professionals remains structurally demanding, and this bottleneck is not expected to change fundamentally in the foreseeable future.

Against this background, a development is already emerging in which HCP recruiting for usability tests is increasingly closely linked to the entire development process. Instead of being seen as a preparatory step of individual studies, recruiting is becoming an integral part of usability engineering and product development.

In parallel, there is a growing professionalization in how networks and participant structures are handled. Organizations are beginning to build relationships with healthcare professionals, hospitals and care facilities in a targeted way and to maintain them over longer periods. The focus is shifting away from the mere number of potential participants toward the quality and differentiation of user groups.

At the same time, digital tools are gaining importance that allow structured organization, segmentation and long-term use of participant data. Looking ahead, data-based approaches and systematic segmentation of user groups are expected to play a central role in further development.

Overall, it is clear that HCP recruiting for usability tests is increasingly developing from an operational task into an independent competence. Organizations that start early to build such structures and to continuously develop access to relevant user groups create a stable basis for future studies.

The decisive difference will not lie in individual methods or tools, but in the ability to build access to healthcare professionals in a lasting and sustainable way.

HCP recruiting for usability tests thus becomes less a question of short-term execution and increasingly a strategic advantage that develops over time.

Conclusion

HCP recruiting is far more than an organizational step in a usability study. It is increasingly becoming a key success factor, both for the quality of the insights gained and for their regulatory robustness.

The real challenge is not the operational execution of individual recruiting measures. What matters is access to the right user groups. Only if real contexts of use are reflected by suitable healthcare professionals can usability tests reach their full validity.

Organizations that see recruiting in this sense not as an isolated task but as a strategic capability create the basis for consistent and reliable study results. They can not only respond more efficiently to new requirements but also systematically involve more complex and specialized user groups. You can find more information on the process of a systematic recruiting and management process for healthcare professionals here:

HCP Recruiting

Further articles will build on this and look in more depth at how concrete methods, channels and structures can be designed, with the aim of establishing HCP recruiting as a robust and scalable capability in usability engineering.

Frequently asked questions about HCP recruiting for usability tests

HCP recruiting describes the targeted selection and approach of healthcare professionals who take part in usability tests as representative user groups. The aim is to reflect real use scenarios validly and to generate reliable insights.

A usability test is only as valid as the participants who take part in it. If they do not represent the real users and their contexts of use, critical use errors can remain undetected and the results lose their regulatory weight.

  • Selection by availability instead of relevance
  • unclear definition of target groups
  • missing differentiation by clinical context
  • insufficient screening of participants

The number depends on the type of study. While formative tests work with smaller groups, summative evaluation according to IEC 62366-1 requires representative participant groups per user profile. For FDA human factors validation, the guidance recommends at least 15 participants per user group.

  • Building a structured participant pool
  • clear definition of user profiles
  • systematic screening
  • long-term recruiting strategy instead of ad hoc project-based solutions

Further reading

Read more

How do you create hazard-related use scenarios and a use-related risk analysis?

Hazard-related use scenarios

Hazard related Use Scenarios

How to identify hazard‑related use scenarios and perform a use‑related risk analysis

What manufacturers need to know about the IEC 62366‑1 requirements

April 2026

Executive Summary

Kopie von auditive Visual Haptical Feedback 3

Hazard-related use scenarios according to IEC 62366‑1 translate use and use errors into a structured and testable form and are therefore a core element of the use-related risk analysis.
The starting point is a systematic task analysis to identify safety‑critical user interface characteristics and potential use errors. Building on this, foreseeable and known hazardous situations are consolidated to cover risks arising from both plausible interaction paths and known problem areas. Hazard-related use scenarios describe sequences of events, including potential use errors, that may lead to hazardous situations. Methodologically, a sufficient level of detail in the description and a clear derivation from the identified use scenarios are essential. For the summative evaluation, a justified, risk‑based selection of the relevant scenarios is required.

The foundation: Identification of foreseeable and known hazardous situations

Use-related risk analysis establishes the connection between the user interface and risk management. It should systematically integrate two sources:

  • Foreseeable hazardous situations: Situations that may plausibly result from potential use errors.
  • Known hazardous situations: Situations known from existing data (e.g., literature, databases, post‑market information).

 

Combining both perspectives is essential: An analysis based solely on internal project knowledge may overlook typical error patterns, while research without an interaction model often leads to vague statements that are difficult to test.

From a methodological standpoint, it is advisable to compare both sources early in the process: Known hazardous situations can serve as a “reality check” (do typical patterns observed in the field correspond to similar UI or workflow structures?), while foreseeable hazardous situations help translate known risks into product‑specific, verifiable event chains. What is crucial is that hazardous situations are not treated as abstract labels but as concrete situations in which a hazard becomes effective — for example, due to incorrect parameter combinations, wrong patient association, missing monitoring response, or delayed alarm perception.

Identification of potential use errors: Systematically describing interaction as a factor contributing to risk

While the identification of known hazardous situations is more similar to a diligence task, a methodical approach is essential when developing the foreseeable hazardous situations. This involves first identifying potential use errors that could lead to hazardous situations, systematically evaluating them, and controlling them through appropriate measures. Methodologically, it is crucial that risks are not formulated in abstract terms but become traceable through concrete interaction sequences and use contexts.
The starting point, therefore, is a systematic description of use as a factor contributing to risk:
Which user groups perform which tasks, with which objectives, under which conditions, based on which information, and under which temporal or organizational constraints?

Risk Analysis

Only once this use situation is described in concrete terms can relevant use errors be derived in a reliable manner. This includes not only what is being done, but how the interaction unfolds:
Which displays are read, which controls are actuated, which decisions are made, which feedback is expected, and which system states are critical in this context. Interaction steps that appear trivial under normal circumstances can, under realistic conditions (e.g., stress, interruption, gloves, limited visibility, noise, time pressure, or concurrent tasks), lead to systematic use errors.

Task analysis as the basis for the use scenarios

A structured starting point is a task analysis based on anticipated tasks. The human–machine interaction is analyzed step by step in order to identify safety‑critical UI characteristics and potential use errors. A robust task analysis considers not only what is being done, but also under which conditions and with which cognitive demands.

To derive safety‑relevant statements, it is helpful to translate tasks into a consistent structure. This makes it possible to identify points at which users rely on critical information (e.g., status indications, limit values, warnings), where values are entered or confirmed, or where similar options may be confused. Typical risk‑contributing factors particularly arise where

  • multiple pieces of information must be integrated,

  • actions are irreversible,

  • time pressure or interruptions occur, or

  • user interfaces allow multiple states without clear state visibility.

A solid task analysis therefore explicitly incorporates existing use environment conditions and cognitive demands. This can be facilitated, for example, by applying the PCA (Perception, Cognition, Action) methodology.

When creating the analysis, consider the following questions:

  • Which work steps are performed, and which actions do they require?
  • What level of attention is necessary (e.g., monitoring in parallel with an intervention)?
  • What memory load arises (e.g., remembering parameter values before entering them)?
  • What level of interpretation is required (e.g., trend curves versus single values)?
  • What perceptual conditions apply (e.g., glare, limited visibility, gloves)?
  • Which team or handover situations are typical (e.g., shift changes, handovers in the OR)?

 

In addition, deviations should systematically be considered as “anticipated” variations:

Which steps are typically shortened in practice, which workarounds are plausible, which routines develop among experienced users — and which risks are facilitated as a result?

Developing hazard‑related use scenarios

The derivation of hazard‑related use scenarios serves to translate use‑related risks into a verifiable form.

A use scenario describes the interaction of a user with the medical device in order to achieve an outcome within a specific use environment.

A hazard‑related use scenario expands this representation by adding a sequence of events, including potential use errors, that may lead to a hazardous situation. In short:

A hazard‑related use scenario according to IEC 62366‑1 is a use scenario that can lead to a hazardous situation, particularly as a result of a use error or a reasonably foreseeable misuse (as defined in ISO 14971).

 

Essential quality criteria include:

  • Perspective: Formulation from the viewpoint of the user and the use context.

  • Level of detail: Sufficiently detailed to allow the underlying causal chains and interaction requirements to be understood.

  • Methodological sequence: First define correct use scenarios, then derive hazard‑related use scenarios from them. This makes it clear where the deviation path emerges and which UI characteristics or contextual factors are contributing.

A hazard‑related use scenario should be structured in a way that it can be directly transferred into test design and risk documentation. In practical terms, this means: 

  • clear starting conditions (system state, user role),
  • the expected correct interaction,
  • the underlying use errors and the related UI characteristics,
  • the resulting hazardous situation, hazards, and harms,
  • the assessment of the severity level in consultation with risk management,
  • the existing and additionally required risk control measures.

This results in a scenario format that is both defensible (for ISO 14971) and testable (for IEC 62366‑1).

Selection of hazard‑related use scenarios for the summative evaluation

Not every hazard‑related use scenario must necessarily be included in the summative evaluation. What matters is a transparent, risk‑based selection process with documented rationale. The selection must demonstrate that the scenarios addressed are those that are critical to the safety of use. IEC 62366‑1 specifies three permissible selection pathways:

  1. All hazard‑related use scenarios are selected for the summative tests.
  2. A subset of hazard‑related use scenarios is selected based on the severity level of the expected harm.
  3. A subset of hazard‑related use scenarios is selected based on the severity level and on additional circumstances specific to the medical device and the manufacturer.

The importance of the severity of harm becomes evident. Its classification is performed in accordance with ISO 14971. In the most recent revision, the standard developers have allowed substantial flexibility for comprehensive justification. A robust selection process makes explicit why a scenario is included in the summative evaluation. What is essential is that the selection is transparently documented and clearly demonstrates that the safety‑critical use scenarios have been covered in the summative testing, thereby aligning with the usability engineering process for medical devices.

Disclaimer

The information presented in this technical article regarding standards and regulations has been prepared to the best of the author’s knowledge and expertise. It solely reflects the author’s opinion. No guarantee can be given for the completeness, currency, or accuracy of the information provided. Standards and regulations are subject to regular revisions and changes, which may not always be reflected here immediately. This article does not constitute binding advice and does not replace the review of the applicable standards and regulations by qualified professionals or official bodies. For the application and interpretation of standards and regulations, the currently valid original documents and the respective competent organizations are always authoritative.

Contact e1749215510462

As usability engineering specialists, we at USE‑Ing. are happy to support you in the planning, execution, and documentation of use‑related risk analyses. Do you have any questions? Feel free to contact us.

Get in touch

The USE-Ing. Compass

Stay on course with our newsletter

Subscribe to the newsletter

Read more

How do you conduct formative usability evaluations in accordance with IEC 62366-1?

Formative usability evaluation

OR Formative Testing

How to conduct formative usability evaluations in accordance with IEC 62366‑1

What manufacturers need to know

February 2026

Executive Summary

Kopie von auditive Visual Haptical Feedback 3

Formative usability evaluations are a methodological core component of iterative user interface design in accordance with IEC 62366‑1, the normative reference for implementing the European Medical Device Regulation (MDR). They serve both the continuous improvement of the user interface (design focus) and the early identification of safety‑relevant use errors (safety focus). Suitable methods range from expert reviews and cognitive walkthroughs to early simulated‑use usability tests. A user interface evaluation plan supports consistency by defining objectives, methods, and criteria for formative and summative activities.

The evaluation should systematically link observations of use errors, close calls, and use difficulties with root cause analyses. What is essential is the feedback of the results into design iterations and—if safety‑relevant—into the use‑related risk analysis. Clear documentation ensures transparency and traceability across development stages. This article explains how to proceed in a targeted and efficient manner.

1The role of formative evaluations in the development process

Formative usability evaluations serve the iterative improvement of the user interface and are therefore an integral part of the user interface design methodology. In contrast to summative evidence, formative activities do not focus on final validation but on a structured cycle of learning and optimization. The aim of formative evaluations is to identify interaction problems as early as possible and to derive user interface design improvements before they become entrenched in later development stages and can only be corrected with considerable effort.

Formative evaluations also serve a risk‑oriented function. They support the early identification of potential use errors that could contribute to hazardous situations and thereby enable targeted further development of the user interface before a summative evaluation takes place. In this way, formative evaluations contribute not only to usability in terms of efficient and satisfactory operation, but also to the robustness of use in safety‑critical situations.

OR Formative Usability Test

2The dual objective framework: design focus and safety focus

Formative evaluations can be methodologically structured along two objectives that complement each other in practice and are often addressed in parallel. Clearly distinguishing these perspectives supports precise study planning, targeted data collection, and a transparent interpretation of the results.

  • Design focus
    The objective is to gain insights that support improving the user interface during development. The emphasis is on aspects such as clarity, consistency, orientation, information presentation, workflow support, and the reduction of unnecessary cognitive load. The design focus examines, in particular, whether the user interface adequately supports the users’ expected mental models, whether interaction logics are intuitively comprehensible, and whether feedback, status indications, and system responses are designed in a way that enables users to make action decisions satisfactorily, effectively, and efficiently. Results from this perspective typically lead to design adjustments that improve usability, efficiency, and error tolerance, without necessarily requiring a direct safety relation in the narrower sense.
  • Safety focus
    The objective is the identification of previously unknown use errors that could lead to hazardous situations. While the design focus often aims at optimizing “normal” use, the safety focus specifically examines those points of interaction where incorrect actions are plausible and may have potentially safety‑critical consequences. In this context, not only actually observed use errors are considered, but also close calls, use difficulties, or strategies that indicate an increased likelihood of error. Methodologically relevant here is, in particular, the question of which contributing factors promote the occurrence of the use error (e.g., unclear feedback, ambiguities, unfavorable sequences, insufficient error prevention or detection), and how these factors can be reduced through UI design measures or accompanying risk control measures.

This differentiation is helpful in practice because it guides the selection, depth, and timing of appropriate methods. An early concept review is typically more strongly anchored in the design focus: it examines the fundamental interaction logic, consistency, terminology, information architecture, and potential cognitive loads, often before high‑fidelity prototypes are available. A formative usability test (e.g., simulated use at a more advanced development stage), by contrast, can be more strongly oriented toward the safety focus: it addresses risk‑relevant use paths, evaluates the robustness of the user interface in critical situations, and makes safety‑critical incorrect actions as well as close calls empirically visible.

In practical implementation, this means that formative evaluations should not be understood as “a type of test,” but rather as a methodically tiered sequence of activities. Depending on the development phase, the emphasis may shift between the design focus and the safety focus. An explicit assignment of objectives also facilitates appropriately weighting the results: while design‑related findings often lead to incremental optimizations, safety‑related findings regularly result in prioritized actions that directly feed into risk justification and subsequent evaluation planning.

3Team and set of methods for formative evaluations

The analysis of formative evaluations is typically conducted in a multidisciplinary manner, as use‑related problems are rarely attributable solely to “usability” in the narrow sense, but often arise from an interplay of clinical application context, technical constraints, information presentation, work processes, and training. Accordingly, the involvement of relevant stakeholders—such as engineering, clinical/medical, quality/regulatory, risk management, and design—is methodologically advantageous in order to classify observations correctly and translate them into actionable design and risk measures. In addition, the involvement of representative users is useful and often necessary, provided that the development stage, accessibility, and study setting allow for it. Representative users enable, in particular, the validation or refutation of assumptions regarding mental models, routines, contextual factors, and typical error strategies, which are often only partially identifiable through internal reviews alone.

From a methodological standpoint, it is also important to recognize that formative evaluations can vary in their level of rigor depending on the development phase. In early stages, rapid, analytical methods are often prioritized, as they can be conducted even when prototypes are still low‑fidelity. As the user interface matures, the emphasis shifts toward empirical methods that make interaction patterns observable under more realistic conditions. As a result, a combined approach is often most effective: analytical methods for broadly identifying weaknesses, and empirical methods for confirming, prioritizing, and analyzing root causes.

Suitable methods include, among others:

  • Expert reviews for the rapid identification of obvious interaction weaknesses. They enable a structured examination of the user interface for inconsistencies, ambiguities, missing feedback, potential paths to incorrect use, and generally known interaction principles or heuristics.
  • Cognitive walkthroughs for analyzing workflows and mental models, particularly for complex operating sequences or safety‑critical decision points. They specifically address the question of whether users can plausibly infer the intended action steps from the user interface.
  • Early‑stage usability tests (simulated use) for observing real interaction behavior using prototype setups. Early‑stage tests allow empirical observation of interaction behavior—including use difficulties, close calls, and potential use errors—under realistic (simulated) conditions. They are especially valuable for capturing actual user strategies that are often underestimated in analytical methods (e.g., workarounds, shortcuts, error‑prone routines, responses to stress or distraction). Depending on the development stage, such tests can be conducted with low‑ to high‑fidelity prototypes, with increasing prototype maturity improving the meaningfulness of results regarding timing, feedback, and interaction dynamics. For risk‑relevant use paths in particular, simulated‑use tests provide an opportunity to empirically verify hypotheses derived from task analysis and hazard‑related use scenarios and to derive prioritized design changes.

4The formative workflow model: planning, execution, iteration

An effective workflow model for formative evaluations typically follows a repeatable cycle of planning, execution, analysis, and iteration. What matters is that formative activities are not viewed as isolated actions, but as a guided sequence whose results are transparently fed into design decisions and—where relevant—into risk‑based justification. The methodological aim is to combine the exploratory nature of formative evaluations with sufficient structure so that insights can be reliably compared, prioritized, and documented.

Step 1: Establish the user interface evaluation plan

A user interface evaluation plan provides the organizational and methodological framework for formative (and typically also summative) activities. It should define the objectives of each evaluation, the methods to be used, the evaluation criteria applied, and how the evaluation is embedded within the overall development and risk logic. Particularly important is the explicit connection to risk‑ and scenario‑based requirements, as formative evaluations often focus on specific interaction paths, UI characteristics, or use situations that are relevant in the risk context.
A consistent plan prevents results from remaining isolated findings and instead establishes a traceable structure: Which question was addressed by which method? Which version of the design was examined? Which user groups and use contexts were included? This clarity is essential for subsequent iterations, as it is the only way to determine whether improvements were truly effective or whether problems merely shifted elsewhere.

Step 2: Conducting the evaluation with appropriate realism

Formative tests also benefit from realistic tasks and plausible contextual conditions, though always within an intentionally exploratory logic. Here, realism is not primarily aimed at regulatory demonstration but at validating assumptions about use, decision‑making processes, and environmental conditions. A suitable setup reflects typical workflows and relevant contextual factors sufficiently well without losing the focus on learning and optimization goals.


During the execution of the evaluation, it is especially important that task descriptions are formulated in a way that triggers real decision‑making rather than simply “checking UI functions.” Depending on the prototype’s maturity, realism can be achieved through various means—for example, by simulating relevant use situations, providing appropriate materials (e.g., draft Instructions for Use (IFUs)), incorporating typical time and attention constraints, or designing realistic transitions between steps. At the same time, the formative logic remains flexible: if it becomes apparent during the execution of the evaluation that critical issues lie in a different interaction point than initially expected, adjusting the focus is methodologically acceptable as long as it is transparently documented.

Step 3: Analyzing the identified use problems

The analysis of formative evaluations should not be limited to a simple list of problems, but should instead be consistently root‑cause oriented. The central question is which observations are actually relevant for design decisions and which factors explain the difficulties that were observed. This includes the structured consideration of:

  • use errors (actions or omissions with potentially risk‑relevant consequences),

  • close calls (near misses that often indicate an increased likelihood of error),

  • use difficulties (challenges, delays, misunderstandings, or workarounds).

A robust analysis examines which UI characteristics, which information presentations, which interaction sequences, or which contextual conditions contribute to the observed problems. Particularly valuable is the identification of recurring patterns: Do several participants encounter difficulties at the same point? Do different users exhibit similar error strategies? Are there typical corrective actions (e.g., backtracking, repeated attempts, aborting) that indicate insufficient system transparency or inadequate error prevention?
The cause‑and‑effect reasoning should be formulated in a way that allows concrete design measures to be derived from it. In this way, formative results become a methodological decision‑making tool rather than merely a collection of observations.

Step 4: Design modifications and feedback into risk‑related activities

The central output of formative evaluations consists of prioritized design changes and a transparent rationale explaining why these changes are suitable for reducing the observed problems. In practice, it is helpful to document design actions not merely as “fixes,” but as part of a structured iteration: Which change addresses which root cause? Which assumption does it modify? Which interaction point does it stabilize?
In parallel, feedback into risk activities is required whenever the results indicate new or confirmed use errors that could be safety‑relevant. This particularly applies in cases where close calls or use difficulties can be interpreted as precursors to potential hazardous situations. In such cases, the insights should be fed back into the use‑related risk analysis to maintain consistency in the risk logic and to strengthen the basis for risk‑based planning of subsequent evaluations.

This creates a closed learning cycle: formative evaluations not only improve usability but also strengthen the safety‑related rationale by making risk‑relevant insights visible early and translating them into targeted design and risk measures.

5Documentation requirements

The guideline requires careful selection of participants, training where appropriate, and data collection with a focus on the critical tasks. It also emphasizes that individuals who frequently participate in usability tests of the same device or other devices from the same manufacturer should be excluded. Notably, compared with other guidelines, the NMPA guideline explicitly expects a justification when no device‑specific training is required for test participants. The test reports should include detailed information on the objectives, simulation conditions, results related to use errors and their associated root causes, as well as any deviations.

Formative evaluations must be documented in a way that makes the results traceable, methodologically reproducible, and usable for subsequent activities. In practice, this is typically achieved through evaluation protocols and evaluation reports that not only capture individual observations but also establish a consistent line of reasoning from objectives to methods to resulting actions. Here, the decisive factor is not the sheer level of detail, but structured transparency: third parties should be able to understand why the evaluation was conducted, how it was conducted, what was observed, and which conclusions were methodologically derived from it.

 

A complete documentation set typically includes the following elements:

  • Objectives and research questions: Clear specification of whether the evaluation was primarily design‑oriented, safety‑oriented, or a combination of both, and which UI aspects or use scenarios were the focus.

  • Methodology and study design: Description of the method(s) applied (e.g., expert review, cognitive walkthrough, usability test (simulated‑use)), including justification for the method selection in relation to the maturity level of the user interface.

  • Sample and representativeness: Characterization of the users or experts involved, including relevant attributes related to the intended user profiles (e.g., experience, qualification, potential limitations), and—where applicable—a justification of the representativeness and its limitations.

  • Test object and versioning: Clear indication of which version of the user interface or which prototype stage was evaluated, including relevant supporting materials (e.g., draft IFUs, training assumptions).

  • Tasks and scenarios: Description of the tasks, use scenarios, and conditions used—ideally in a way that makes the logic of task derivation and the intended triggering of specific interaction paths recognizable.

  • Data collection and analysis logic: Explanation of which data were collected (e.g., observations, error classification, qualitative notes), how observations were structured, and which criteria guided interpretation and prioritization.

  • Results presented in a structured form: Consistent documentation of use errors, close calls, and use difficulties, including context, observed action sequence, and—where possible—a root cause analysis or contributing factors.

  • Derived measures and design decisions: Concrete, transparently justified actions derived from the results, including prioritization and rationale explaining why the measure is suitable for addressing the observed root cause.

What is essential here is the ability to build on prior results: the subsequent development documentation should clearly show how formative findings have informed design decisions and the use‑related risk analysis. This includes, in particular, the connection between the observed problems, their interpretation in terms of root causes, and the design changes that have been implemented or planned.
In addition, the documentation plays an important steering function throughout the project. It enables assessment across iterations of whether measures were effective, whether issues have shifted, or whether new risks have emerged. Clear versioning and a consistent results structure also facilitate later preparation for summative evaluation activities, as they make it evident which risk‑relevant interaction points have already been addressed and which aspects remain critical.

Disclaimer

The information presented in this technical article regarding standards and regulations has been prepared to the best of the author’s knowledge and expertise. It reflects solely the author’s opinion. No guarantee can be given for the completeness, currency, or accuracy of the information provided. Standards and regulations are subject to regular revisions and changes, which may not always be reflected here in a timely manner. This article does not constitute binding advice and does not replace the review of the applicable standards and regulations by qualified professionals or official bodies. For the application and interpretation of standards and regulations, the currently valid original documents and the respective competent organizations are authoritative.

Contact e1749215510462

As usability engineering specialists, we at USE‑Ing. are happy to support you in the planning, execution, and documentation of formative usability evaluations. Do you have any questions? Feel free to contact us.

Get in touch

The USE-Ing. Compass

Stay on course with our newsletter

Subscribe to the newsletter

Read more

How do you conduct human factors validation tests in compliance with FDA requirements?

Human factors validation for FDA submissions

fda zulassung medizinprodukte

FDA approval for medical devices: Human factors validation explained in simple terms

What manufacturers of medical devices need to know for FDA approval

January 2026

Executive Summary

Kopie von auditive Visual Haptical Feedback 3

In the FDA context, human factors validation testing serves as a component of design validation in accordance with the FDA design control requirements (formerly 21 CFR Part 820.30, incorporated into ISO 13485:2016, clause 7.3, by the Quality Management System Regulation, QMSR, since February 2026), with the specific objective of demonstrating that the medical device can be used safely and effectively by the intended users in the intended use environments. The FDA has outlined its expectations for this in the guidance document “Applying Human Factors and Usability Engineering to Medical Devices.” In May 2026, the FDA additionally finalized its guidance on the content of human factors information in marketing submissions. A central foundation is the risk‑based identification and categorization of critical tasks based on the severity of potential harm, all of which must be fully covered in the test. The FDA typically expects usability tests to be conducted as simulated‑use testing with the final user interface, realistic use conditions, representative user populations (generally at least 15 participants per relevant user group), and a test execution that enables independent and natural use without moderator influence. Data collection should combine observational data, knowledge task data where applicable, and post‑use interviews. The analysis is qualitative and requires a root cause analysis for use errors, close calls, and use difficulties, as well as a robust justification of residual risk. This article explains in detail how to proceed with this process.

1Regulatory context and objectives

In the context of FDA approval, the FDA Guidances emphasize the risk‑based nature of human factors and usability engineering and focus primarily on ensuring that the user interface is designed such that use errors with potentially harmful consequences are eliminated or reduced as much as possible. Human factors validation testing is conducted at the end of development to demonstrate that the final user interface supports safe and effective use under expected conditions of use and that the implemented risk control measures are effective.

FDA Devices

2Critical tasks as the guiding test unit in human factors validation

Within the context of FDA approval, a central structural principle is the definition of critical tasks. These are tasks for which incorrect performance or failure to perform the task could result in serious harm to the patient or user, including compromised medical care. The identification and justification of these critical tasks is relevant not only for the test design but also shapes the evaluation approach and the argumentation presented in the report.

With respect to critical tasks, the following principles apply:

  • all critical tasks must be performed during the validation test.
  • critical tasks are derived in advance from the risk analysis.
  • the list is dynamic and may expand as understanding of user–device interaction increases.

The FDA recommends identifying critical tasks through a combination of analytical and empirical approaches:

  • Analytical approaches include task analysis (including PCA‑based methods), failure mode and effects analysis (FMEA), or fault tree analysis (FTA), ideally conducted by a multidisciplinary team.
  • Empirical approaches include contextual inquiry, interviews, and formative evaluations (including cognitive walk‑throughs and simulated‑use formative testing).

An important aspect of the FDA’s reasoning is that the probability of occurrence of use errors is difficult to quantify reliably in actual use; therefore, the severity of potential harm is the primary factor used to prioritize tasks.

3Development of the human factors validation test protocol

To plan the study in a methodologically correct manner, the development of a test protocol is required. The FDA typically requires that human factors validation be conducted as a usability test in the form of simulated‑use testing and specifies clear minimum requirements for the study design. The validation test is not an exploratory format; rather, it is a purposefully constructed demonstration intended to show that the final user interface can be used safely and effectively by the intended users in the intended use environments, particularly with respect to the critical tasks.

Key FDA requirements for the study design

At its core, the FDA requires that human factors validation testing ensures that:

  • the test participants represent the intended users,

  • all critical tasks are actually performed during the test,

  • the user interface reflects the final design,

  • and the test conditions are sufficiently realistic so that the findings can be generalized to actual use.

These requirements must not merely be stated in the protocol but defined operationally. This means that it must be documented in a traceable manner which user characteristics are considered representative (and why), how full coverage of all critical tasks is ensured, which design version is considered “final” (including labeling and the instructions for use (IFU)), and which environmental and contextual factors are relevant for achieving realistic test conditions.

Principle of realism and test environment

Simulated‑use conditions must be realistic enough for the results to be generalizable to actual use. The FDA emphasizes that relevant environmental factors must be incorporated into the simulation based on risk, insofar as they could affect user interaction with the device. The guidance cites examples such as dim lighting, distractions, and multitasking.

For protocol planning, this means that realism is not achieved through superficial “scenery,” but through the targeted representation of those conditions that are plausible contributing factors to use errors. The protocol should therefore explicitly define:

  • which environmental parameters are relevant for realism (e.g., lighting, noise, spatial constraints, device setup, typical distractions),

  • which of these parameters will be controlled, which will be varied, and which will intentionally not be addressed in the test,

  • and how these decisions are justified with respect to the use‑related risk analysis and the critical tasks.

At the same time, the simulation must remain methodologically stable: realism must not introduce uncontrollable confounding variables. Therefore, the FDA requirement focuses on “sufficient realism,” not on a full replication of a clinical environment. What matters is the logical justification that the essential interaction conditions have been adequately represented.

Methodological distinction: No moderator influence, no think‑aloud

For validation, participants must use the device independently and naturally. The FDA explicitly states that think‑aloud techniques are not acceptable in validation studies, as verbalization alters behavior and therefore does not represent real‑use conditions. The protocol must therefore be structured so that relevant data are derived primarily from observation. Interactions should not be influenced by prompts, questions, or “assistance” from the study environment. If questions are necessary (e.g., for root‑cause clarification), they should generally be shifted to a post‑use interview to avoid distorting actual task performance.

Labeling and IFU as part of the final user interface

The FDA considers labeling—including the instructions for use (IFU), device labels, packaging, quick‑start guides, and comparable informational components—to be part of the user interface. Accordingly, the final versions of these materials must be used in the validation test. This is methodologically relevant because many critical tasks depend not only on interaction design but also on the clarity, accessibility, and applicability of the information provided. Human factors validation therefore implicitly assesses whether users, under realistic use conditions, can make correct decisions and perform critical tasks accurately using the provided labeling. At the same time, the FDA makes clear that labeling or training must not serve as a default compensation for design‑related use errors on critical tasks. If use errors on critical tasks occur during validation, relying solely on labeling or training modifications—without additional evidence demonstrating their effectiveness—is not acceptable.

Components of the test protocol typically expected under the FDA’s logic

Although the guidance does not prescribe a rigid structure, we recommend that the following aspects be described in the test protocol:

  • test objectives with explicit reference to safe and effective use and the critical tasks,

  • description of the final user interface, including the labeling set,

  • use scenarios and task sets from which the test cases are derived to ensure full coverage of the critical tasks,

  • success criteria for each task, clearly defining what constitutes successful task performance,

  • training requirements consistent with real‑use conditions,

  • test environment and realism parameters,

  • data collection methods (primarily observational, supplemented by interviews and knowledge tasks),

  • rules for moderator behavior and handling of deviations.

A systematically developed test protocol demonstrates that the study was not merely “performed,” but methodologically constructed to truly meet the FDA’s requirements for human factors validation as a risk‑based demonstration.

4Sample and training

In the context of FDA approval, the FDA recommends a practical minimum of 15 participants for human factors validation tests; if multiple relevant user groups are involved, at least 15 participants per user group must be included. User groups differ particularly when characteristics or task responsibilities vary in ways that are likely to affect interaction with the device (e.g., lay users versus healthcare professionals, pediatric versus adult users). When selecting test participants, it is essential that they are U.S. residents.

Representativeness and relevant variability in user characteristics

Participants should represent the relevant range within the user group, particularly with regard to characteristics that may influence interactions (e.g., sensory, physical, or cognitive limitations, literacy/language skills, experience). For certain medical conditions that may cause functional limitations, corresponding representativeness considerations must be explicitly taken into account. Employees of the manufacturer should not serve as participants in human factors validation tests (exceptions apply only in rare, highly specialized cases).

Training and real‑use consistency (including training decay)

The training approach applied in the testing must reflect real‑use conditions: if actual users receive minimal or no training, test participants must not receive more extensive training. Training immediately before the test is problematic; the FDA highlights training decay and expects a time interval (depending on the device, up to a day) to realistically represent retention.

5Data collection – observational data, knowledge tasks, post‑use interviews

For successful FDA approval, the FDA expects that data collection in human factors validation testing is based primarily on observable task performance, supplemented by information that cannot be reliably inferred from behavior (e.g., comprehension, interpretation, decision‑making knowledge). Accordingly, the data collection approach in the protocol should clearly define which data sources will be used (observational data, knowledge task data, interviews).

Observational data as primary evidence for task performance

According to the FDA, successful performance of critical tasks must be assessed primarily through observation. Observational data therefore constitute the key source of evidence for determining whether the user interface supports safe and effective use under the intended conditions.

From a methodological perspective, this means that the test record (observation log) must precisely document:

  • What constitutes task completion (success criteria for each task, including required subtasks, correct system states, and correct decisions).

  • Which deviations are to be classified as use errors (e.g., incorrect selection, incorrect setting, omission of a safety‑critical action, improper response to feedback/alarms).

  • Which observable indicators must be captured as close calls or use difficulties (e.g., search behavior, repeated attempts, inconsistent strategies, hesitation at decision points).

The FDA also notes that timing measurements are only meaningful when speed is clinically relevant; otherwise, no timing criteria should be introduced, as this can distort the validation logic (e.g., shifting the focus from “correct” to “fast”). 

Systematically capturing use errors, close calls, and use difficulties

During the execution of the simulated‑use test, it is essential to document in detail any problems that occur during user interaction. The FDA categorizes these issues as use errors, close calls, and use difficulties.

Use errors are defined as “a user action or lack of action that was different from that expected by the manufacturer and that resulted in an outcome that (1) was different from the outcome expected by the user, and (2) was not caused solely by device failure, and (3) did or could result in harm.” The term “harm” explicitly includes compromised medical care.

Close calls are errors that did not lead to an incorrect final outcome due to self‑correction or accidental recovery. Close calls are methodologically important because they often indicate an increased likelihood of error, even when the task was formally completed successfully.

In addition, use difficulties must be captured—not as incidental notes, but as systematic indicators, particularly when they occur repeatedly or cluster around safety‑critical points of interaction. The FDA identifies the following typical observable markers, among others:

  • Repeated attempts

  • Hesitation

  • Confusion

  • Search behavior

Knowledge task data for non‑observable comprehension tasks

Part of the critical use safety depends not only on physical operation but also on knowledge and comprehension, for example with respect to:

  • contraindications,

  • warnings,

  • environmental conditions/vulnerabilities,

  • maintenance or safety‑critical preparatory steps.

Such aspects cannot often be reliably inferred from observable behavior alone—particularly when the test setup cannot practically represent every rare contextual condition. For this purpose, the FDA recommends knowledge tasks, i.e., knowledge and comprehension questions designed to assess whether participants can correctly interpret relevant information and make appropriate decisions.

Key methodological requirements include:

  • Use of open‑ended, neutrally phrased questions (no leading questions, no multiple‑choice prompts as the default).
  • Separation of observation and knowledge inquiry: knowledge tasks should be placed so that they do not pre‑condition participant behavior during the use scenarios.
  • Documentation of the information basis: if knowledge related to labeling or the IFU is being assessed, it must be clear whether and how participants had access to the material and whether they were able to find and interpret the information.

Post‑use interview as a complement, not a substitute

In the FDA approach, post‑use interviews are a complementary data source. They are intended to deepen the observational data but must not replace it. Interviews serve in particular to:

  • systematically explore the root causes of observed use errors or problems,

  • capture subjectively experienced use difficulties that may not have been clearly observable,

  • and understand the interaction logic from the user’s perspective (e.g., mental models, expectations, interpretation of information).

The FDA recommends conducting interviews after the completion of the use scenarios to avoid influencing task performance. Methodologically, it is essential that the exploration of each observed use error or problem is conducted systematically—using open, neutrally phrased questions (e.g., “What did you expect at this point?”, “How did you interpret this information?”, “What led you to this decision?”) rather than confirmatory or leading formulations.

In addition, interviews should explicitly provide space for:

  • subjectively reported difficulties (even when no errors were observed),

  • perceived ambiguities in terminology, symbols, or feedback,

  • and the reasons for recovery strategies used in close calls.

6Analysis – root cause analysis and residual risk

In the context of FDA approval, the FDA positions human factors validation testing as primarily a qualitative approach: the goal is not to estimate statistical frequencies, but to identify design‑related root causes of use errors or problems and to derive effective risk controls.

Data aggregation with the aim of root cause analysis

The analysis aggregates observational data, knowledge task data, and interview data and derives from them a root cause analysis and prioritization relative to the potential severity of harm. Key FDA expectations include:

  • Use errors or problems that could result in serious harm require a clear analysis of which user interface component was involved and how the interaction led to the error.
  • Seemingly obvious causes must still be explored in the interview; the user’s perspective can provide critical insights.
  • If modifications are implemented, retesting may be required to demonstrate their effectiveness and to rule out new risks.

Residual risk – when “acceptable” is regulatory defensible

The FDA makes it clear that devices cannot be entirely free of risk; some residual risk will remain. However, persistent serious use errors are generally not acceptable in premarket submissions unless there is a robust justification demonstrating that further reduction is not practicable and that the benefits outweigh the risks.

Disclaimer

The information presented in this technical article regarding standards and regulatory guidance has been prepared to the best of the author’s knowledge and expertise. It reflects solely the opinion of the author. No guarantee can be given for the completeness, currency, or accuracy of the information provided. Standards and regulations are subject to regular revisions and updates, which may not always be reflected here in real time. This article does not constitute binding advice and does not replace a review of the applicable standards and regulatory requirements by qualified professionals or official bodies. For the application and interpretation of standards and regulatory guidance, the currently valid original documents and the respective authoritative organizations are always decisive.

Contact e1749215510462

As specialists in human factors and usability engineering, we at USE‑Ing. are pleased to support you in the planning, execution, and documentation of human factors validation tests in the United States. Do you have questions? Feel free to contact us.

Get in touch

The USE-Ing. Compass

Stay on course with our newsletter

Subscribe to the newsletter

Read more

Blog Directory

Latest Posts

Would you like to receive more information about our services or know how we can support your company with our expertise?

Contact us

Frequent Keywords

AI-enabled Medical Devices Formative Usability Evaluation Hazard-related Use Scenario HCP Recruiting Human Factors Validation NMPA Usability Guidance Packaging Usability Usability Engineering Process
Go to blog