User needs describe what a medical device must accomplish for patients, clinicians, caregivers and other users within its intended use environment. They are the starting point for design and the benchmark against which verification and validation ultimately evaluate the finished device.
What are user needs?
User needs capture the real-world problem a device must solve, expressed in the user’s language rather than as an engineering solution.
Examples include:
- A surgeon needs to see clearly inside a body cavity.
- A nurse needs to set up an infusion quickly during an emergency.
- A home user needs to read a result without assistance.
- A technician needs to identify when maintenance is required.
User needs sit above detailed requirements. Through systems engineering, teams translate them into measurable design inputs covering performance, safety, usability and regulatory requirements.
For example:
- User need: The operator must be able to read the result in a brightly lit room.
- Design input: The display must achieve a specified contrast ratio under a defined illumination level.
Verification confirms that the measurable input was implemented correctly. Validation confirms that representative users can achieve the original need under realistic conditions.
Why user needs matter
A device can pass every engineering test and still fail its users if the original needs were incomplete or incorrect. That gap can lead to use errors, complaints, recalls and unsupported regulatory claims.
Under the FDA QMSR, effective February 2, 2026, design and development requirements apply through ISO 13485:2016 Clause 7.3. Auditors expect traceability from user needs to requirements, design outputs, risk controls and validation evidence.
In Europe, user needs must remain consistent with the intended purpose, clinical evaluation and EU MDR technical documentation. Vague or missing needs often surface late, when correction requires redesign and repeated testing.
How user needs flow through design controls
1. Identify the users and environment
Determine who interacts with the device and where use occurs. Consider the intended population, clinicians, caregivers, service personnel and other relevant stakeholders.
Account for:
- Training and experience
- Physical and cognitive abilities
- Language and health literacy
- Hospital, clinic, ambulance or home environments
- Noise, lighting, distractions and time pressure
2. Gather user needs
Use multiple sources rather than relying only on internal sales or engineering opinions:
- User interviews
- Contextual observation
- Clinical input
- Complaint and adverse-event data
- Comparable-device analysis
- Workflow studies
- Formative usability research
3. Write solution-neutral statements
Describe the required outcome without prematurely choosing the design.
“The device shall use a 3.5-inch touchscreen” is a solution. The underlying need may be that an operator must read and confirm results at arm’s length.
4. Translate needs into design inputs
Convert each need into specific, measurable and testable requirements. Inputs may cover:
- Function
- Performance
- Safety
- Reliability
- Environmental conditions
- User-interface behavior
- Labeling
- Applicable standards
5. Connect needs to risk and usability
Usability engineering under IEC 62366-1 helps identify needs involving users, tasks, environments and foreseeable use errors. ISO 14971 risk management connects those needs to hazards and necessary risk controls.
6. Verify and validate
Verification demonstrates that design outputs meet approved inputs. Validation confirms that production-equivalent devices satisfy user needs and intended use under actual or simulated-use conditions.
A Requirements Traceability Matrix should connect every user need to its derived inputs, risk controls, outputs, verification and validation evidence.
Common challenges and best practices
Common problems include:
- Writing design solutions as user needs
- Consulting internal teams instead of actual users
- Ignoring the use environment
- Combining several needs into one statement
- Writing needs that cannot be validated
- Failing to update traceability after a change
Good needs are clear, solution-neutral, connected to a named user and use scenario, and written so that an appropriate validation method is evident.
Review needs with clinical, engineering, quality, regulatory and human-factors representatives before approval. Revisit them whenever intended use, users, claims or environments change.
Manage approval and changes through a controlled Phase-Gate Process. A change to a user need should trigger an assessment of affected requirements, risks, verification and validation evidence.
How SJML helps with user needs
SJML incorporates user-needs analysis into its medical device design and engineering process, translating stakeholder input into structured requirements across mechanical, electronics, embedded and software disciplines.
IEC 62366-1 usability engineering and ISO 14971 risk management connect needs to use-related requirements and hazards. SJML’s medical device compliance services help keep intended use, regulatory strategy, technical documentation and validation evidence aligned.
Phase-gate management and change control maintain traceability as the product progresses from concept through verification and design transfer.
Frequently asked questions
User needs describe the problem in the user’s terms; design inputs are the engineering and regulatory requirements derived from them. A need might state that a nurse must start an infusion quickly in an emergency. The matching input specifies the exact setup time, force, and interface behavior. Inputs are testable and measurable; needs set the target those inputs must satisfy.
No. User needs are the requirements; design validation is the activity that tests whether the finished device meets them. Under ISO 13485 Clause 7.3.7, validation uses production-equivalent units under actual or simulated use conditions. It answers whether the team built the right device, while verification checks whether the device was built to its design inputs correctly.
User needs come from the people and settings that interact with the device: patients, clinicians, caregivers, and service staff, in their real use environment. Teams gather them through interviews, contextual observation, clinical input, and analysis of similar devices. Human-factors and usability work under IEC 62366-1 helps surface needs tied to the use environment that stakeholders may not state directly.
Yes. The QMSR, effective February 2, 2026, enforces design controls through ISO 13485:2016 Clause 7.3, and user needs remain the foundation of that process. Although 21 CFR 820.30 is now reserved, the substance is unchanged: teams must define needs, trace them to inputs, and validate the device against them. Auditors still expect that traceability to hold.