Verification (German: Verifizierung) is the objective demonstration that specified requirements have been met. In usability engineering, it can refer, for example, to testable technical requirements of the user interface specification. In the design and development process for medical devices, verification answers in particular the question: Do the design outputs meet the specified design inputs?
In usability engineering, verification can concern, for example, requirements for displays, alarms, controls, operating logic, labeling, or instructions for use. It must be clearly distinguished from validation: While verification checks the conformity of development results with specified requirements, validation examines whether the resulting medical device meets the requirements of its intended purpose (intended use) and the needs of its intended users.
Verification in the development process
Verification activities are a central part of the design and development process. They provide objective evidence that the developed design outputs meet the underlying design inputs. In usability engineering, this can include, for example, checking the following elements:
- Indicators and displays
- Alarm signals
- Controls
- Operating and interaction logic
- Software functions
- System feedback
- Labeling
- Instructions for use
- Protective and interlock mechanisms
Robust verification requires that the requirements to be checked are formulated unambiguously and in a verifiable way. Requirements such as "clearly visible," "easy to understand," or "intuitive to operate" do not, without further specification, make clear by which criteria their fulfillment is to be assessed. For each verification activity, the following should therefore be defined, among other things:
- Requirement to be verified
- Test item
- Test method
- Acceptance criteria
- Required test environment
- Required test equipment
- Where applicable, sample size and its rationale
- Responsibilities
- Handling of deviations
The results and any required follow-up actions must be documented and linked in a traceable way to the underlying requirements.
Distinction between verification and validation
Verification and validation are often treated as equivalent in development projects but pursue different goals. Verification asks: Were the specified requirements implemented correctly? Validation asks: Does the resulting product meet the requirements of its intended use and the needs of its intended users?
Example: A design input requires that an alarm reach a defined sound pressure level within a specified frequency range. Measuring the generated alarm against these specifications is verification. Investigating whether the intended users perceive the alarm under representative conditions of use, understand it, and respond appropriately is part of the validation of safe use.
The distinction does not depend on the method used alone, however. Verification can also involve users if a specified requirement is checked against objective acceptance criteria. Conversely, validation can include other evidence besides user studies. What matters are therefore: the underlying question, the link to design inputs or to the requirements of the intended use, the maturity of the product, and the role of the evidence in the development process.
Verification of individual requirements does not replace validation of the resulting medical device or of its safety-relevant user interface.
| Verification | Validation | |
|---|---|---|
| Guiding question | Were the specified requirements implemented correctly? | Does the resulting product meet the requirements of its intended use and the needs of its intended users? |
| Alarm example | Measuring the generated alarm against the design input specifications (frequency range, sound pressure level) | Investigating whether the intended users perceive the alarm under representative conditions of use, understand it, and respond appropriately |
| Involvement of users | Possible if a specified requirement is checked against objective acceptance criteria | Can include other evidence besides user studies |
Typical verification methods for user interfaces
The suitable verification method depends on the respective requirement and the design output to be checked. Typical methods are:
- Inspections
- Document reviews
- Expert reviews
- Checklist-based conformity checks
- Measurements of physical properties
- Software, integration, and system tests
- Functional tests
- Simulations and calculations
- Analysis of drawings and specifications
- Review of labeling and instructions for use
- Traceability analyses
- Comparison with specified standards and acceptance criteria
- Where applicable, evaluation-based tests with users
Examples of verifiable properties of a user interface are:
- Size and spacing of controls
- Character size and contrast
- Sound pressure level and frequency of an alarm
- Required actuation force
- Response time of the user interface
- Permissible input ranges
- Presence of defined system feedback
- Behavior on invalid input
- Consistency of the instructions for use with the product specification
- Correct implementation of defined operating sequences
Many of these checks do not require representative users. For requirements related to perception, comprehension, or action, however, an evaluation with suitable participants may be necessary. The mere involvement of users does not automatically make a test a validation. What remains decisive is whether a defined product requirement is being checked or the suitability for the intended use is being assessed.
Link to use-related risks
Many requirements for the user interface arise from the use-related risk analysis. If, for example, the unambiguous distinguishability of two connectors is specified as a risk control measure, concrete design inputs can result from it, for example regarding shape, mechanical coding, position, or labeling. The subsequent verification must demonstrate that the specified measure has been implemented. Whether it is actually effective in interaction with the users is demonstrated according to IEC 62366-1 in the summative evaluation.
Checking the implementation can often be done by inspection, measurement, or technical tests. Checking effectiveness, by contrast, can require additional methods. For use-related risk control measures, it can be investigated, for example, whether the intended users reliably distinguish the connectors under representative conditions and connect them correctly.
According to ISO 14971, both the implementation and the effectiveness of risk control measures must be verified. Checking effectiveness is not automatically equivalent to design validation. Depending on the measure, however, it can require a formative or summative evaluation with users. A traceable link should exist between the following elements: hazard → hazardous situation → risk control measure → design input → design output → verification evidence. For use-related risks, a link to hazard-related use scenarios and to the summative evaluation may additionally be required.
Verification of usability requirements
Usability-related requirements must be formulated so that their fulfillment can be assessed objectively and in a traceable way. Statements such as "The alarm must be clearly perceivable," "The display must be easy to understand," "Operation must be intuitive," or "The product must be easy to use" are generally not sufficient as stand-alone design inputs.
They should be translated into concrete requirements and suitable acceptance criteria. These can relate, for example, to:
- Character size
- Contrast
- Viewing distance
- Lighting conditions
- Volume and frequency
- Spatial arrangement of controls
- Required operating forces
- System response times
- Unambiguous presentation of units
- Separation of critical functions
- Permissible input ranges
- Behavior on invalid or contradictory input
Not every usability-relevant requirement can be verified solely through technical measurements. Requirements for recognizing, understanding, or correctly carrying out an action can require evaluation-based tests. Careful distinction is needed here as to whether a specific requirement is being verified, a design solution is being investigated formatively, or the safe use of the final user interface is being validated summatively.
Error rates, task completion times, and task success can be suitable metrics. Their regulatory significance, however, depends on the objective of the investigation, the participants, the conditions of use, the product status, and the specified acceptance criteria. Such metrics are therefore not automatically pure verification criteria.
Typical weaknesses in practice
A common mistake is to understand verification exclusively as a technical check and not to include usability-relevant requirements in verification planning. Other typical weaknesses are:
- Unclear or non-verifiable design inputs
- Missing acceptance criteria
- Acceptance criteria that are defined only after the test has been carried out
- Missing traceability between design input, design output, and verification evidence
- Verification against outdated requirements or product versions
- Insufficiently defined test conditions
- Missing justification of sample sizes
- Unsuitable or uncalibrated test equipment
- Missing testing of boundary and error cases
- Insufficient documentation of deviations
- Missing repeat testing after design changes
- Mixing of verification and validation objectives
- Checking only the implementation of risk control measures without assessing their effectiveness
- Missing coordination between development, human factors, risk management, and quality management
The claim that a particular method is fundamentally assignable to either verification or validation is also problematic. An expert review can, for example, be a verification activity if conformity with specified requirements is checked. It can also be a formative evaluation if the aim is to identify previously unknown weaknesses of the user interface. Likewise, a test with users can, depending on its objective, check a requirement, investigate a design solution formatively, or be part of the summative evaluation.
Regulatory reference
ISO 13485:2016 requires that design and development verification be performed according to planned and documented arrangements. It must be demonstrated that the design outputs meet the design inputs. Verification planning must include suitable methods and acceptance criteria. If statistical methods or sampling are used, the underlying rationales must also be taken into account. The results and any necessary actions must be documented. The design and development requirements are anchored in Section 7.3 of ISO 13485.
IEC 62366-1 describes a process for the analysis, specification, development, and evaluation of the usability of a medical device in relation to safety. This produces, among other things, requirements and specifications for the user interface, whose implementation must be checked in the design and development process. However, the standard does not focus exclusively on the verification of technical requirements but also requires a summative evaluation of the safety-relevant use of the user interface.
ISO 14971 requires verification of the implementation and the effectiveness of risk control measures. For use-related measures, suitable evidence must be selected. Depending on the measure, technical tests, inspections, analyses, or evaluations with users may be required.
As of October 2026, the FDA Quality Management System Regulation (QMSR) applies to the US market (effective February 2, 2026). The QMSR incorporates ISO 13485:2016 into 21 CFR Part 820. The design and development requirements result in particular from 21 CFR 820.10(c) in conjunction with ISO 13485:2016, Section 7.3. Earlier references to 21 CFR 820.30(f) as a stand-alone FDA requirement for design verification therefore no longer reflect the current regulatory structure.
The European Medical Device Regulation (MDR) requires, as part of the technical documentation (the set of documents with which a manufacturer demonstrates conformity of its device), among other things, evidence of the verification and validation of the product. For usability-relevant requirements, this results in practice in a combination of technical verification evidence, risk management activities, and the evaluation of the user interface.
Verification checks whether documented development results meet the specified requirements: design input → design output → verification evidence. Validation, by contrast, examines whether the resulting medical device meets the requirements of its intended use and the needs of its intended users.
The distinction does not depend on the method or on the involvement of users alone. What matters are the question asked, the reference requirement, and the regulatory function of the evidence. A measured alarm volume is a typical example of verification. Whether the intended users perceive the alarm under representative conditions, understand it, and respond appropriately is a question of validation.
Frequently asked questions (FAQ)
Is a summative usability test a verification?
No. A summative usability evaluation or human factors validation examines whether the final or production-equivalent user interface can be used safely by the intended users under representative conditions. It therefore primarily serves the validation of safe use and not merely the checking of individual design inputs. Individual technical or documentary properties of the test item can, however, be verified beforehand, for example the product version, certain alarm parameters, or conformity with the user interface specification.
Can an expert evaluation constitute a verification?
Yes. If experts check, against specified requirements and acceptance criteria, whether a design output meets the design inputs, the expert evaluation can constitute a verification activity. If an expert review is instead used to discover weaknesses, derive new requirements, or assess alternative solutions, it is rather a formative evaluation. An expert evaluation does not replace a required summative evaluation with representative users.
Do all usability requirements have to be verified?
Documented design inputs must be covered by suitable evidence. Different verification methods may be required for this. Some requirements can be verified completely by inspections, measurements, or technical tests. Others require evaluation-based methods or additionally a validation with representative users. What matters is complete, traceable linkage between requirements, development results, and evidence.
Why is verifying the implementation of a risk control measure not enough?
Because the correct implementation of a measure does not yet prove that it actually reduces the risk in question as intended. For example, it can be verified that a warning is present in the instructions for use. This does not yet demonstrate, however, that the intended users find it, understand it, remember it, and follow it in the specific situation of use. Both the implementation and the effectiveness of a risk control measure must therefore be verified.
Can users take part in a verification?
Yes. The involvement of users does not automatically make a test a validation. If a clearly defined requirement is checked against predefined acceptance criteria with suitable participants, this can be part of verification. If, by contrast, user needs, the intended use, or the safe use of the final user interface are assessed under representative conditions, it is validation.
Does verification have to be repeated after every design change?
Every design change must be assessed for its effects on requirements, risks, and verifications and validations already performed. The affected requirements and development results must be verified again. In addition, it must be checked whether regression tests or a new validation are required. The scope depends on the nature, significance, and possible safety-related effects of the change.
Do you want to separate verification and validation activities for your user interface cleanly, plan them on a risk basis, and document them in a traceable way? We support you throughout the usability engineering process according to IEC 62366-1.
More about our usability engineeringSources
- IEC 62366-1:2015+AMD1:2020, Medical devices, Part 1: Application of usability engineering to medical devices
- ISO 14971:2019, Medical devices, Application of risk management to medical devices
- ISO 13485:2016, Medical devices, Quality management systems, Requirements for regulatory purposes
- Regulation (EU) 2017/745 on medical devices (MDR)
- 21 CFR Part 820, Quality Management System Regulation (QMSR)