User Needs
User Needs List
Document user expectations providing design compass and regulatory foundation through solution-neutral requirement capture.
Summary
The User Needs List captures what your users expect and require from your medical device, serving as the foundational document that drives all design decisions, requirements development, risk management activities, and validation testing throughout your device development process.Why is a User Needs List Important?
A comprehensive User Needs List provides the regulatory foundation for medical device development by establishing clear user expectations before design begins. Without well-documented user needs, development becomes unfocused and reactive, leading to feature creep, missed requirements, and validation failures that can prevent regulatory approval and market success. This document transforms abstract user expectations into concrete development inputs that guide every subsequent design decision. It establishes the basis for requirements traceability, ensuring that every system requirement, software feature, and risk control can be traced back to a specific user need. This traceability is essential for demonstrating regulatory compliance and design rationale. For medical device development, user needs serve as your design compass by defining what success looks like from the user’s perspective. They prevent over-engineering by focusing development efforts on features that truly matter to users while ensuring safety and effectiveness requirements are captured early. The document also provides the foundation for validation activities that demonstrate your device meets its intended use.Regulatory Context
Under 21 CFR Part 820.30 (Design Controls), the FDA requires:
- Documented user needs as design inputs that establish what the device must accomplish
- Traceability from user needs through design requirements to verification and validation
- Design review of user needs to ensure completeness and accuracy
- User needs validation through clinical evaluation or usability testing
- Change control for user needs updates throughout development
- Based on intended use and user research
- Solution-neutral and focused on user outcomes
- Comprehensive enough to guide design decisions
- Traceable to system and software requirements
- Validated through appropriate testing methods
Special attention required for:
- Software as Medical Device (SaMD) user needs must address clinical workflow integration and decision-making support
- Combination devices require user needs for both hardware and software components with clear interfaces
- Cybersecurity considerations must be reflected in user needs for connected devices
- Usability engineering per FDA Human Factors guidance requires user needs to address use-related risks
Guide
Your User Needs List must comprehensively capture what users expect from your device while providing clear guidance for all subsequent development activities.User Research and Stakeholder Input
Begin with comprehensive user research to understand the problems your device should solve. Conduct interviews with intended users including clinicians, patients, caregivers, and technical staff. Observe current workflows and identify pain points, inefficiencies, and unmet needs. Review complaints about existing devices and analyze competitive products for insights. Engage multiple stakeholder groups throughout the research process. Primary users directly interact with your device and have functional needs. Secondary users may be affected by device use and have different requirements. Technical stakeholders understand integration requirements and system constraints. Regulatory and quality teams provide compliance perspectives.User Needs Development
Write high-level statements that describe what users expect from your device without specifying how those needs will be met. Focus on user outcomes rather than technical solutions. Each user need should be clear, measurable, and focused on the user’s perspective rather than internal technical requirements. Structure user needs to be solution-neutral and broad enough to accommodate future design changes while specific enough to guide development decisions. Avoid technical implementation details or specific feature descriptions. Instead, focus on the fundamental problems users need solved and the outcomes they expect to achieve.Categorization and Organization
Organize user needs into logical categories that reflect different aspects of device use. Common categories include:- Functional needs: What the device must do or accomplish
- Performance needs: How well the device must perform its functions
- Usability needs: How easy and intuitive the device must be to use
- Safety needs: How the device must protect users from harm
- Compatibility needs: How the device must work with other systems
- Environmental needs: How the device must perform in its use environment
Essential vs. Product-Specific Needs
Distinguish between essential user needs that apply to all devices of your type and product-specific needs unique to your particular device. Essential needs often relate to basic safety, regulatory compliance, and fundamental usability requirements that any device in your category must meet. Product-specific needs reflect the unique value proposition of your device and the specific problems it solves differently than existing solutions. These needs drive innovation and differentiation while ensuring your device provides meaningful benefits to users.Validation and Review
Establish review processes to ensure user needs are complete, accurate, and achievable. Involve multidisciplinary teams including clinical, technical, quality, and regulatory representatives. Review user needs against intended use statements and ensure consistency with regulatory requirements. Plan for user needs validation through appropriate methods such as user interviews, surveys, usability testing, or clinical evaluation. Validation should confirm that identified needs accurately reflect user expectations and that meeting these needs will result in a successful device.Traceability and Change Management
Implement traceability systems that link each user need to derived system requirements, software requirements, risk controls, and verification activities. This traceability demonstrates that all user needs are addressed in your design and that all requirements serve a user purpose. Establish change control procedures for user needs updates throughout development. Changes may be driven by new user research, regulatory feedback, or design discoveries. Document the rationale for changes and assess their impact on derived requirements and verification activities.Documentation Standards
Document user needs in a structured format that supports regulatory review and team communication. Include sufficient detail for team members to understand user expectations while maintaining solution neutrality. Provide context about user environments and constraints that influence how needs should be met. Ensure documentation quality through clear writing, consistent terminology, and logical organization. User needs should be understandable to both technical and non-technical stakeholders while providing sufficient detail to guide design decisions.Example
Scenario: You’re developing a wearable stress monitoring device that helps office workers understand and manage their stress levels throughout the workday. The device collects physiological data and provides personalized recommendations through a mobile app. Users include busy professionals who want objective stress insights without disrupting their workflow.User Needs List
ID: UNL-StressWear-2024-001 Device: StressWear Stress Monitoring System Purpose: To provide office workers with objective stress monitoring and personalized stress management recommendations through a comfortable wearable device and intuitive mobile application. User Needs:| User Need ID | Type of User Need | Category | Description |
|---|---|---|---|
| UN001 | Essential | Safety | The device must not cause skin irritation or allergic reactions during extended wear |
| UN002 | Essential | Safety | The device must not pose electrical safety risks to users |
| UN003 | Essential | Usability | The device must be intuitive to use without requiring extensive training |
| UN004 | Essential | Performance | The device must provide accurate and reliable measurements |
| UN005 | Essential | Compatibility | The device must work with common smartphones and operating systems |
| UN006 | Product | Usability | The device must be comfortable for all-day wear during office work |
| UN007 | Product | Performance | The device must accurately detect stress levels through physiological monitoring |
| UN008 | Product | Usability | The mobile app must display stress information in an easily understandable format |
| UN009 | Product | Functionality | The device must provide personalized stress management recommendations |
| UN010 | Product | Performance | The device must operate for a full workday without charging |
| UN011 | Product | Usability | The device must connect to the mobile app automatically without user intervention |
| UN012 | Product | Environmental | The device must be water-resistant for handwashing and light rain exposure |
| UN013 | Product | Usability | The device must be easy to clean and maintain for hygiene |
| UN014 | Product | Performance | The app must provide real-time stress level updates throughout the day |
| UN015 | Product | Functionality | The device must track stress patterns over time to identify trends |
| UN016 | Product | Privacy | The device must protect user health data and maintain privacy |
| UN017 | Product | Usability | The device must be discreet and professional-looking for office environments |
| UN018 | Product | Performance | The device must provide consistent measurements across different users |
| UN019 | Product | Functionality | The app must allow users to log stress-related events and activities |
| UN020 | Product | Usability | The device setup and initial configuration must be simple and quick |
- EU MDR 2017/745
- ISO 13485:2016 - Medical devices Quality management systems Requirements for regulatory purposes
- IEC 62366-1:2015 - Medical devices Part 1: Application of usability engineering to medical devices
| ISO 13485:2016 Section | Document Section |
|---|---|
| 7.2.1 | All user needs |
| 7.3.3 | All user needs |
| IEC 62366-1:2015 Section | Title | Document Section |
|---|---|---|
| 5.2 | Identify user interface characteristics related to safety and potential use errors | UN001-UN005, UN008, UN011, UN013, UN017, UN020 |
| 5.6 | Establish user interface specification | UN003, UN008, UN011, UN020 |
Q&A
How do I determine if my user needs are comprehensive enough?
How do I determine if my user needs are comprehensive enough?
Comprehensive user needs should cover all aspects of device interaction including functional performance, usability, safety, and environmental requirements. Review your intended use statement and ensure every claimed benefit or function has corresponding user needs. Conduct stakeholder reviews with clinical, technical, and quality teams to identify gaps. Consider the complete user journey from device setup through daily use to maintenance and disposal. If you can’t trace a system requirement back to a user need, you may be missing important user expectations.
What level of detail should I include in user need descriptions?
What level of detail should I include in user need descriptions?
User needs should be detailed enough to guide design decisions but broad enough to accommodate different implementation approaches. Include the user’s perspective on what outcomes they expect and why those outcomes matter. Avoid specifying technical solutions or implementation details. For example, write “Users must be able to quickly understand their current stress level” rather than “The device must display stress level as a number from 1-10.” Provide context about user environments and constraints that affect how needs should be met.
How do I handle conflicting user needs from different stakeholder groups?
How do I handle conflicting user needs from different stakeholder groups?
Document all legitimate user needs even when they appear to conflict, then use design reviews and risk management to resolve conflicts. Prioritize needs based on safety criticality, regulatory requirements, and primary user impact. Consider whether conflicts reflect different use scenarios or user types that require different solutions. Some conflicts may be resolved through design features that accommodate multiple approaches. Document the rationale for prioritization decisions and ensure all stakeholders understand trade-offs.
When should I update user needs during development?
When should I update user needs during development?
Update user needs when new information changes user expectations or when regulatory requirements evolve. Common triggers include user research findings, usability testing results, clinical feedback, regulatory guidance updates, or competitive analysis insights. Establish change control procedures that assess the impact of user needs changes on derived requirements, design decisions, and verification activities. Minor clarifications may require minimal impact assessment, while new user needs may trigger significant design changes.
How do I validate that my user needs accurately reflect user expectations?
How do I validate that my user needs accurately reflect user expectations?
Validate user needs through direct user feedback using methods appropriate to your development stage and resources. Early validation can use interviews, surveys, or focus groups with representative users. Later validation may include usability testing, clinical evaluation, or pilot studies. Document validation methods and results to demonstrate that user needs accurately capture user expectations. Consider ongoing validation through post-market surveillance to ensure user needs remain current as markets and technologies evolve.
What's the difference between user needs and system requirements?
What's the difference between user needs and system requirements?
User needs describe what users expect from the device from their perspective, while system requirements specify what the device must do to meet those needs. User needs are solution-neutral and focus on outcomes (e.g., “Users must quickly understand device status”). System requirements are more technical and specific (e.g., “Device must display status using LED indicators visible from 2 meters”). Each system requirement should trace back to one or more user needs, ensuring all technical specifications serve user purposes.