![A Guide to Bridging User Needs and Design Requirements]()
The aim of any medical device company is always to create safe, effective solutions to real problems. Unfortunately, this doesn’t always go to plan.
One common reason for that is because the device was designed perfectly—but it solved the wrong problem.
What I mean by that is, the finished device can meet all its specified requirements (design outputs meeting design inputs), but it still might not meet the needs of its users. And that’s because a lot of medical device companies not only struggle to discover what their users really need, but then to turn those user needs into verifiable design inputs.
Bridging user needs and design requirements is an important piece of the puzzle when it comes to creating the right medical device and solving the right problem. We’ll break down that important bridge in this guide:
Free Download: 10 Questions You Should Ask to Help Define Your User Needs. Click here for PDF.
What are design inputs?
First of all, it’s good to check out how the regulations describe design inputs. Here is an extract from 21 CFR 820.30(c).
(c) Design input. Each manufacturer shall establish and maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. The procedures shall include a mechanism for addressing incomplete, ambiguous, or conflicting requirements. The design input requirements shall be documented and shall be reviewed and approved by a designated individual(s). The approval, including the date and signature of the individual(s) approving the requirements, shall be documented.
Let’s pull out some key terms from the design input regulations and examine them more closely:
-
Appropriate. Generally speaking, this means the requirement is relevant and useful for the particular device. However, it’s clear that the regulation leaves itself open to interpretation by the medical device company in this case. Every company must determine what’s “appropriate” for their own device.
-
Intended use. This is a commonly used (yet often misunderstood) phrase at both industry and FDA levels. Intended use often gets mixed up with “indications for use” and causes problems during submissions to FDA. While “indications for use” is about the patient (the condition or symptoms being treated), “intended use” focuses on the product. What does the device do? What is its mechanism of action?
-
Needs of user and patient. Historically, medical devices have been operated by physicians or other trained professionals; however, these days the user and patient can be one and the same. This presents further challenges for activities like human factors and usability testing. You may need to consider users who are trained professionals as well as those who are not.
-
Mechanism for addressing incomplete, ambiguous, or conflicting requirements. While having a mechanism in place for addressing these issues with requirements is important, problems often occur because no one recognized a requirement was incomplete, ambiguous, or conflicting at the time. Ideally, your processes should be set up to identify and prevent these issues from occurring.
What’s the relationship between design inputs and user needs?
Typically, we collect our user needs first, then translate those into design inputs. An important point here is to ensure that you’re getting those needs from actual users, rather than simply relying on internal brainstorming.
If you’re not the ideal user, how will you know that you’ve truly identified “user” needs? Even if you can make some assumptions internally, it’s important to verify those with people who fit your criteria as an ideal user.
The intent behind the regulation for this is to ensure we start out with the needs of the user, before translating those into engineering terms. Interestingly, there is no definition for “user need” in the regulation, however.
The closest thing we get is this, from CFR 820.30 (g):
Design validation shall ensure that devices conform to defined user needs and intended uses and shall include testing of production units under actual or simulated use conditions.
The assumption seems to be made that the user already knows what they really need, but years of development prove this is not the case. They might think they know, but it’s up to us to be able to look beneath the surface and carefully define those needs.
How to translate user needs into design inputs
When you’re translating those user needs into design inputs, it’s important that you understand the real meaning behind what people are telling you.
Let’s say, for example, a doctor tells you, “The device must be portable.” In engineering terms, what exactly does that mean? You might be looking at the maximum weight of the device, its size or volume, and where it needs to fit (on a cart, for example). You would need to know if it needs to connect to power, or use wifi.
Your design inputs need to be specific and detailed. It’s okay if your user needs are more fuzzy, as long as those inputs are clear! You should have sampled a wide enough range of your customer base so that you can be sure you’re headed in the right direction.
All of this is required because the designer is not (usually) the end user. The regulation recognizes that most designers are not physicians or using the devices in real-world settings.
Here’s a list of some potential design inputs to consider for your medical device:
- Device function
- Physical characteristics
- Safety and performance
- Reliability
- Regulations and standards
- Human factors
- Labeling & packaging
- Maintenance
- Sterilization
- Compatibility (materials/devices)
- Environmental factors
An important point to remember is that, much like your risk management plan, design inputs should be a “living” document, to be revisited over time. It’s up to you how frequently, but this is in the spirit of the regulation—things change and it’s important that appropriate updates are made. Realistically, this is common sense and prudent engineering, and should be done regardless of regulation.
An example of user needs driving design inputs
Imagine you're developing an advanced insulin pump. You engage with endocrinologists and diabetic patients to gather user needs. They tell you they need a compact, easy-to-use pump that integrates seamlessly with their smartphones. They're sharing what they believe is needed, based on their current understanding.
There's a saying that applies here: “If the only tool you have is a hammer, all of your problems look like nails.”
What solutions have you overlooked? What questions have you not asked? Instead of focusing solely on how to improve the pump's connectivity, ask broader questions like, "How can we ensure accurate insulin dosage under varying conditions?"
This reframing opens up new solutions. For example, incorporating AI-driven algorithms to predict blood sugar levels or developing a dual-chamber pump for more precise dosing. The quality of your answers depends on the depth of your questions.
As an insulin pump manufacturer, remember your competition isn't just other insulin pump makers. Your real competition includes companies that thoroughly assess user needs early on and develop disruptive technology to meet them. This approach applies to any medical device manufacturer.
Consider recent issues with automated external defibrillators (AEDs). Thousands of people rely on these devices in emergencies to restore heart rhythm. However, a study found that some AEDs fail due to battery malfunctions, leading to critical delays in treatment.
This underscores the importance of clearly defining user needs. Is the primary goal device portability or reliable performance? Medical devices should be grounded in scientific evidence rather than assumptions.
Frequently asked questions about bridging user needs into design inputs
Whenever we talk about bridging user needs and design requirements, it prompts several questions from the audience. Here are some common questions:
Do all design inputs need to have a corresponding user need?
Design Inputs had to come from somewhere - otherwise, why are you including them? Even regulatory requirements are there for a reason.
User needs don’t have to come just from the user. They might come from marketing, engineers, physicians, patients, people who assist users, etc. However, the engineer should always go back to the user and verify the need.
Take, for instance, the case of insulin pumps a few years ago. Some models had issues with their software that caused incorrect dosages, leading to severe health complications for patients.
Everyone wondered, how did this issue arise? Do we need stricter regulations? But new regulations weren't what was necessary. The core issue lay in understanding user needs. The vital question was, “Who is the user?” For an insulin pump, the user isn’t just the patient but also the healthcare provider who sets it up and maintains it. This must be integrated into the design process. How will you include them and ensure the interface is intuitive and safe?
Fundamentally, manufacturers need to understand the spirit of the regulation and take all of these things into account when gathering user needs, and translating into design inputs.
What about design inputs stemming from your risk analysis?
So as a result of your risk analysis, you’ve identified some risks of the device, and you’re using them as design inputs in order to mitigate or eliminate future risk. This is a great example of design inputs that don’t originate from user needs (or you could argue that risk mitigation is like a user). This is a helpful approach to look at design in a more holistic fashion, and account for other areas that make your device safer.
Can design inputs include business needs? (e.g. color, cosmetics, cost)
All elements of your quality system should be defined and attached to the product and company. You can define user needs to include these “non-conventional” categories if you like.
If you have a wonderful device, but no one can afford to buy it, how many people can you help? Considerations like cost can definitely enter the equation.
Sometimes people prefer to cite the source of their user needs, and there’s nothing wrong with saying “this is a business need” or that it came from elsewhere inside the company. Some companies are hesitant to include non-traditional items in their QMS, thinking that they will be questioned for it during an inspection.
However, this is an opportunity to let the inspector see your dedication to making a safe and effective product, and not solely focused on compliance.
If you’re simply documenting your design controls to meet a regulatory need, then you’ve missed the point of their purpose. These are a way for you to collaborate and communicate within your company. Your design history file (DHF) will eventually become a record identifying why these decisions were made.
How strong should your justification be for changing design input or user needs?
Frankly, it has to be strong enough to justify making a change to your device. The biggest risk is a business risk—is it worth the time and money to do it? FDA is ultimately concerned with the safety and efficacy of the product and that it does what it says on the label, so it shouldn’t be a concern for them.
To document a design change, as with any other change you need to explain the rationale and ensure you’ve done proper due diligence. You should also take into account upstream and downstream activities that could be affected. Document why the change was made, and determine whether anything else needs updating to support the change.
What is the best method of demonstrating traceability?
Traceability is an absolute necessity. It’s a basic tenant of good manufacturing practice. You need traceability to demonstrate that you can connect the dots between all your design controls.
As for the best method of tracking, “Show the flow.” How did things progress through the design and development process? Everything we do changes, as much as we might not like that! You have to know how the dots are all connected.
This is the biggest reason Greenlight Guru's QMS software platform exists—it makes it easy to show that flow and keep a handle on traceability. It is specifically built with medical device manufacturers in mind.
Free Download: 10 Questions You Should Ask to Help Define Your User Needs. Click here for PDF.
Get seamless a seamless design control solution with Greenlight Guru Quality
Ensuring that your user needs are driving your design inputs isn’t just about the way you think—it’s also about the way you work. It’s about making sure that you have traceability throughout your system and you can document, track, and trace every aspect of your design controls process.
When you use Greenlight Guru Quality, you’ll get design control software that also seamlessly integrates with risk management. You’ll be able to create your design control objects, link complex configurations, and attach related documents with a single click. Traceability won’t be a struggle—it will come standard.
If you’re ready to check out how it works, then get your free demo here →
