User needs are the documented requirements that describe what a medical device must accomplish for the people who use it, including patients, clinicians, and caregivers, in its intended use environment. They are the starting point of design controls and the benchmark that design validation later tests the finished device against.
What are user needs?
User needs to capture the real-world problem a device has to solve, stated in the language of the user rather than the engineer. A surgeon might need to see clearly inside a body cavity; a home patient might need to read a glucose result without help. These statements sit at the top of the design control waterfall, the model the FDA published in its 1997 Design Control Guidance and still references today.
From user needs, a team derives design inputs: the specific, testable engineering and regulatory requirements the device must meet. Verification later confirms those inputs were built correctly. Validation confirms the finished device satisfies the original user needs under real conditions. Getting the needs right early shapes everything downstream.
Why user needs matter in medical device development
A device can pass every verification test and still fail its users if the needs were wrong or incomplete. That gap is where recalls and use errors come from. Regulators treat user needs as the foundation of a defensible design, so weak needs undermine the whole file.
Under the FDA Quality Management System Regulation (QMSR), effective February 2, 2026, design controls are enforced through ISO 13485:2016 Clause 7.3 rather than the older text of 21 CFR 820.30, which is now reserved. Auditors expect a clear trace from each user need to the requirements, tests, and validation records that address it. In the EU, users need to feed the intended purpose stated under EU MDR 2017/745 and the clinical evaluation that supports it. Vague needs tend to surface late, when fixing them costs the most and can delay a submission.
How does the user need to flow through the design controls
Design controls turn user needs into a finished, validated device through a defined sequence. The core steps:
- Capture needs. Gather input from clinicians, patients, and other stakeholders through interviews, observation, and market analysis. Record each need in clear, unambiguous language.
- Translate to design inputs. Convert needs into measurable requirements per ISO 13485 Clause 7.3.3, covering function, performance, usability, safety, and applicable regulations.
- Assess use and risk. Map needs to use-related requirements under IEC 62366-1 (usability engineering) and to hazards under ISO 14971 (risk management).
- Verify outputs. Confirm design outputs meet the design inputs (Clause 7.3.6).
- Validate against needs. Prove, on production-equivalent units and under actual or simulated use, that the device meets the user’s needs and intended use (Clause 7.3.7).
A requirements traceability matrix links each user need to its inputs, verification, and validation evidence. It is one of the most heavily sampled artifacts in an audit, so build it as you go rather than reconstructing it before an inspection. The 1997 FDA guidance allows iterative and agile development; the traceability just has to hold.
Common challenges and best practices
The most common mistake is writing needs that are really solutions. “The device shall use a 3.5-inch touchscreen” is a design decision, not a need; the underlying need might be that the operator must read the result at arm’s length in a bright room. Solutions written as needs quietly lock in choices before the tradeoffs are understood.
Other frequent problems: needs gathered from a sales team instead of actual users, needs that skip the use environment, and needs that no one can test. A need that cannot be validated is not finished.
What good looks like: needs traceable to a named user and use scenario, written so a validation method is obvious, and reviewed with clinical or human-factors input before they freeze. Revisit them when the intended use changes, and treat any change as a trigger to check downstream verification and validation, since a shift in user needs can invalidate earlier work.
How SJML helps with user needs
SJML runs user-needs analysis as the front end of its device design and engineering work, translating stakeholder input into structured design inputs across mechanical, electronics, embedded, and software domains. Usability engineering to IEC 62366 and risk management to ISO 14971 are built into that flow, so they need to connect to use-related requirements and hazards from the start. Phase-gate program management with change control keeps the resulting requirements traceable through verification and design transfer. As an end-to-end CDMO, SJML carries that thread from early concept into manufacturing under one quality system.
Talk to SJML’s engineering team →
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.
Related terms
- Design Inputs
- Design Validation
- Design Controls
- Intended Use
- Usability Engineering (IEC 62366-1)
