A friend of mine works in logistics, and our work-related conversations rarely go beyond the usual “How’s it going?” and “Yeah, good thanks.” But recently, we stumbled upon a shared pain point that transcends our respective industries: requirements.
Whether you’re developing a fleet management system or a novel surgical tool, poorly defined requirements can sink even the most promising projects. My friend and I have both seen initiatives falter because user needs were sidelined, often overshadowed by the allure of new technology or a clever engineering solution. In medical device development, this misstep can have serious consequences, not just for project timelines and budgets, but for patient safety and regulatory approval.
Why do user requirements matter for Medical Devices?
From a human factors perspective, defining user requirements early and accurately is not just good practice; it’s essential. According to ISO 13485:2016, design inputs must include functional, performance, usability and safety requirements based on the intended use. These inputs must be complete, unambiguous, and verifiable. Similarly, IEC 62366-1 and FDA HF guidance emphasise that usability engineering should begin with a clear understanding of the intended users, use environments, and user interface characteristics that relate to safety.
This foundational step, known as the ‘use specification’, informs every subsequent phase of design and risk management. It’s also the starting point for your use-related risk analysis (URRA), which is a key regulatory requirement when use errors could result in serious harm.
So why do user requirements get overlooked?
Often, it’s because the development process is driven by technical feasibility rather than user desirability. A novel mechanism or software feature may be pushed forward without anyone asking, “Would this work for the people who actually use it?” This disconnect can lead to devices that are difficult to operate, prone to use errors, or simply not fit for purpose.
Fortunately, more and more medical device developers are recognising the value of early user engagement. Before a designer even puts pen to paper, meaningful insights can be gathered through interviews with representative patients, caregivers, and healthcare professionals. These conversations help uncover real-world challenges and unmet needs or pinch points that might otherwise go unnoticed until late-stage testing or, worse, post-market surveillance.
What does ISO 13485 say about this?
Quite a lot, actually. The standard requires documented procedures for design and development planning, including the definition of design stages, verification and validation activities, and traceability between inputs and outputs. It also mandates that user training requirements be identified and reviewed as part of customer-related processes.
In other words, you need to show that you’ve thought about who your users are, what they need, and how they’ll interact with your device. And you need to document it.
How does this tie into risk management?
ISO 14971:2019 makes it clear that risk management starts with defining the intended use and foreseeable misuse of the device. It then requires identification of hazards and hazardous situations based on user interaction. These are the building blocks of your use-related risk analysis.
Formative evaluations – iterative usability assessments you should do throughout the design process – are a great way to validate assumptions and refine requirements. They’re not just about testing prototypes; they’re about understanding how users behave and where things might go wrong. The data and feedback you can gather from a good formative assessment will help you understand whether you have designed a product that is fit for the users’ purpose.
For example, if you’re asking users to try out a new injection design, why not also ask whether the proposed solution addresses their actual needs? Does the device accommodate limited dexterity? Is the labeling clear under low lighting conditions? Can the user intuitively navigate the interface without training? These questions help ensure that the design is not only functional but usable and safe.
What about traceability?
Both ISO 13485 and ISO 14971 require traceability from user needs to design outputs and risk controls. This means you need to be able to show how each requirement was addressed, how risks were mitigated, and how decisions were made. This traceability is critical for regulatory submissions and helps tell the ‘story’ of your device development.
How do I validate user requirements?
At some stage, prior to regulatory submission, devices need to be evaluated against their user requirements. When writing user requirements, it pays to bear this in mind. Firstly, more requirements obviously require more work to evaluate them. So consideration as to whether the user requirement is truly needed and appropriate is the first step to reduce evaluation efforts towards the end of the development process.
Next, it is key that requirements can be readily evaluated and thus sensible to consider the evaluation method at the point of writing. It is often cleanest if user requirements can be evaluated through design verification data. Sometimes, however, the only way to evaluate user requirement success is as a during your usability study evaluating use risk. This usually consists of running simulated-use scenarios, with recruited participants representing your intended users, with specific end points designed to gather data in support of the user requirements.
Final thoughts
That conversation with my friend in logistics wasn’t simply small talk, it was a reminder that defining user requirements early is not just about avoiding design missteps. It’s good practice, ensuring that the people who use these products – whether clinicians, patients, or caregivers – can do so confidently and without unnecessary risk.
So next time you’re kicking off a development project, take a moment to ask your users: “What challenges do you face?”. Engage users early, define requirements clearly, and validate them thoroughly. It’s not just good practice, it’s the foundation of safe, effective, and compliant design.