User Needs vs Design Inputs for Medical Devices: How to Translate VOC into Verifiable Requirements

Why the Distinction Between User Needs and Design Inputs Matters

One of the most common audit findings in medical device development is poorly defined design inputs that cannot be traced back to user needs. Engineers often jump from vague customer statements directly into specifications, creating gaps that surface during FDA inspections, notified body audits, or — worse — after the device reaches patients.

The FDA's design control regulation, 21 CFR 820.30, requires manufacturers to establish and maintain procedures to ensure that design requirements address the intended use of the device, including the needs of the user and patient. Under the Quality Management System Regulation (QMSR), effective February 2, 2026, these requirements are now framed through ISO 13485:2016 Clause 7.3, which adds explicit expectations for functional, performance, usability, and safety requirements tied to intended use.

This guide explains what user needs and design inputs are, how they differ, and provides a practical framework for translating Voice of the Customer (VOC) data into verifiable design inputs with full traceability.

User Needs: The Foundation of Every Medical Device

User needs describe what the device must accomplish from the perspective of the people who will use it — clinicians, patients, caregivers, or technicians. They are intentionally high-level and written in the language of the user, not the engineer.

What User Needs Must Address

A well-documented user needs document should cover:

• Intended use and indications for use: What clinical purpose does the device serve, and for what patient population?
• User profiles: Who are the primary and secondary users? What are their training levels, physical capabilities, and work environments?
• Use environment: Hospital operating room, outpatient clinic, home care, emergency vehicle, battlefield — each environment imposes different constraints.
• High-level performance expectations: Speed of operation, accuracy expectations, ease of use, portability, durability.
• Human factors considerations: Will the device be worn, implanted, or operated by hand? Are there ergonomic requirements?
• Target markets: Geographic and regulatory markets drive labeling, language, and compliance requirements.

How to Capture User Needs

The Voice of the Customer (VOC) process provides a systematic method for gathering user needs. Effective techniques include:

• Contextual inquiry: Observe users in their actual clinical environment. Watch how they perform tasks, manage interruptions, and recover from errors.
• Structured interviews: Conduct conversations with representative users about their clinical workflow, pain points, and unmet needs.
• Surveys and questionnaires: Collect quantitative data on user preferences and priorities across a broader population.
• Complaint and adverse event analysis: Review post-market surveillance data from predicate devices or similar products on the market.
• Clinician advisory boards: Engage key opinion leaders who can validate unmet clinical needs.

A practical rule of thumb: aim for 20–30 user need statements before attempting to translate them into design inputs. Too few, and you risk missing critical requirements. Too many, and the translation process becomes unmanageable.

User Needs Example

For a portable infusion pump:

Notice these are qualitative, user-centric statements. They do not contain engineering specifications.

Design Inputs: The Engineering Translation

Design inputs are the detailed, measurable engineering requirements that describe the performance, physical, and functional characteristics the device must exhibit to meet user needs. Every design input must be traceable back to at least one user need.

Under QMSR (incorporating ISO 13485 Clause 7.3.3), design inputs must:

• Be complete, unambiguous, and able to be verified or validated
• Not conflict with each other
• Include applicable regulatory and standard requirements
• Account for risk management outputs (ISO 14971)
• Address functional, performance, usability, and safety requirements

What Design Inputs Must Include

Depending on the device, design inputs typically address:

• Functional requirements: What the device must do (e.g., deliver fluid at programmed rates)
• Performance requirements: How well it must perform (e.g., flow rate accuracy of ±5%)
• Physical characteristics: Dimensions, weight, materials, form factor
• Environmental requirements: Operating temperature, humidity, shock/vibration resistance
• Electrical and electromagnetic requirements: Power supply, EMC compliance (IEC 60601-1-2)
• Software requirements: Response times, user interface behavior, alarm logic
• Biocompatibility requirements: ISO 10993 classification and testing requirements
• Usability requirements: Task completion times, error rates, learning curve
• Sterilization and reprocessing requirements: Method validation, cycle parameters
• Labeling and packaging requirements: Content, language, symbology (ISO 15223)

Design Inputs Example

Translating the user needs from our infusion pump example:

The Translation Process: From VOC to Verifiable Requirements

Step 1: Collect and Organize User Needs

Gather all VOC data into a structured format. Group similar needs and eliminate duplicates. Use an affinity diagram or KJ method to organize needs into logical categories (safety, performance, usability, regulatory).

Step 2: Analyze Intent Behind Each Need

For each user need, ask: What does the user actually mean? The user need "the device must be portable" could translate into requirements for weight, dimensions, battery life, carrying mechanism, and environmental protection. Document the intent analysis to provide traceability context.

Step 3: Identify Applicable Standards and Regulations

Map each user need to applicable standards:

• FDA recognition statements and guidance documents
• ISO/IEC standards (IEC 60601 series, ISO 10993, IEC 62366-1)
• EU MDR GSPRs (Annex I)
• Country-specific requirements for target markets

Step 4: Conduct Hazard Analysis

The user needs document provides the basis for conducting hazard analysis per ISO 14971. Results from the hazard analysis feed into design input requirements. For example, a user need about portability may introduce hazards related to dropping the device, which generates design inputs for drop testing and impact resistance.

Step 5: Write Measurable Design Inputs

Each design input must satisfy these criteria:

1. Specific: Exactly one requirement, not compound statements
2. Measurable: Quantified with limits, tolerances, or acceptance criteria
3. Verifiable: Capable of being confirmed through test, analysis, inspection, or demonstration
4. Traceable: Linked to at least one user need
5. Non-conflicting: Does not contradict any other design input

A common mistake is writing design inputs that are actually design outputs (describing how the device will meet the requirement rather than what it must achieve). Design inputs define what the device must do; design outputs describe how it does it.

Step 6: Resolve Conflicts and Ambiguities

The regulation explicitly requires addressing incomplete, ambiguous, or conflicting requirements. A classic example: one user need calls for the device to be "lightweight" while another requires it to be "rugged." Engineering must resolve what weight limit satisfies both needs, document the resolution, and update both design inputs accordingly.

Step 7: Establish Traceability

Build a requirements traceability matrix (RTM) that connects:

• User needs → Design inputs → Design outputs → Verification → Validation

This matrix is one of the first documents an FDA investigator or notified body auditor will request.

The Traceability Matrix in Practice

A well-constructed traceability matrix demonstrates that every user need has been addressed through the design control waterfall. Here is a simplified example for a blood glucose monitoring system:

QMSR Changes That Affect User Needs and Design Inputs

The transition from 21 CFR 820 to QMSR (effective February 2, 2026) brings several changes relevant to this topic:

• ISO 13485 terminology: "Design inputs" are now discussed under "design and development inputs" (Clause 7.3.3). The substance is equivalent but terminology has shifted.
• Risk management integration: QMSR requires risk management outputs to be explicitly accounted for in design inputs. This was previously only addressed in design validation under 21 CFR 820.30(g).
• Customer communication: ISO 13485 Clause 7.2.3 introduces formal requirements for documenting customer communications — a new element that directly supports VOC capture.
• Documented information: ISO 13485 uses "documented information" rather than "records," broadening what must be maintained.

Common Pitfalls and How to Avoid Them

1. Writing Design Inputs That Are Actually User Needs

A design input that says "the device shall be easy to use" is not a design input — it is a restated user need. Rewrite as: "The average user shall complete the primary operation sequence within 30 seconds with zero critical use errors, as measured during summative usability testing."

2. Creating Orphan Design Inputs

Every design input must trace to a user need. If you have a design input with no parent user need, either the user need is missing (indicating incomplete VOC) or the design input is unnecessary.

3. Ignoring Foreseeable Misuse

ISO 14971 and IEC 62366-1 require analysis of reasonably foreseeable misuse. User needs should capture not only intended use but also foreseeable off-label use scenarios, which then generate additional design inputs for protective measures.

4. Conflicting Requirements

When two user needs produce conflicting design inputs (e.g., "lightweight" and "drop-resistant from 2 meters"), document the trade-off analysis and resolution in the DHF. Do not simply pick one and discard the other.

5. Static Requirements in an Agile Environment

For software-based devices following agile development, user needs remain relatively stable but design inputs may evolve across iterations. Maintain version control and impact assessments each time a design input changes.

Checklist: Audit-Ready User Needs and Design Inputs

• User needs are written from the user's perspective, not the engineer's
• User needs address intended use, user profiles, and use environment
• VOC data is documented and traceable to specific user interactions
• Each design input is specific, measurable, and verifiable
• No design input conflicts with another
• Hazard analysis results are incorporated into design inputs
• Applicable standards and regulations are identified and addressed
• Traceability matrix covers user needs → inputs → outputs → V&V
• Incomplete, ambiguous, or conflicting requirements are resolved and documented
• Risk management outputs feed into design input updates
• All documentation is stored in the Design History File (DHF)

Key Takeaways

User needs and design inputs serve different but complementary purposes in the design control process. User needs capture what the device must accomplish from the user's perspective; design inputs translate those needs into measurable engineering requirements. The translation process — informed by VOC methods, hazard analysis, and applicable standards — must produce traceable, verifiable requirements that demonstrate to regulators that the device was designed to meet real clinical needs. With the QMSR transition incorporating ISO 13485 by reference, the emphasis on risk management integration and documented customer communication makes rigorous requirements management more important than ever.