User Needs vs Design Inputs: It’s About Viewpoint

Ever built the wrong medtech device? I’ve worked at a number of medical device companies and each one took a different approach to writing User Needs and Design Inputs. And it’s no wonder—FDA CFR and EU MDR do not explicitly define how these critical requirements should be documented.

What FDA Design Controls Tell Us (and What They Don’t)

The most specific information we have is found in “FDA Design Control Guidance for Medical Device Manufacturers” (1997). Here, FDA cites “user needs” a mere 10 times, but there is one reference that for me stands above the rest—the graphic defining the Application of Design Controls to Waterfall Design Process.

In the graphic we clearly see that design inputs (DIs) are an output of user needs (UNs). The other important message is that verification is the activity of proving that our design outputs meets the intentions of our design inputs. Correspondingly, validation is the activity of proving that our medical device meets the intentions of our user needs. You might have heard the adage: Validation proves we designed the right product, while Verification proves we designed the product the right way.

How Archimedic Approaches User Needs and Design Inputs

That leaves us with a question of how best to craft a user need statement and the design inputs that spring from it. At Archimedic, we consider the method of V&V at the time we’re crafting our UNs and DIs. It’s a check that we’re being unambiguous and realistic, and at the end of V&V we will have objective evidence the product meets its UNs.

The validation process focuses on the user and their ability to achieve the intended outcome desired, not the device’s performance. So, it follows that the user need should be crafted from the perspective of the user—the object of the validation process to come. That’s why our standardized method for creating our UN statement begins with the user as the noun in a sentence, followed by the action verb needs. So, it reads like this: “The user needs to …(from use of the device)”

Example: Turning User Needs into Clear Design Inputs

Let’s look at an example. Let’s say we’re developing a medical device that needs to be easily cleaned between uses. So, we write our user need without ambiguity: “The user needs to be able to clean the device after each use with disinfecting wipes found in a hospital setting”.

The design input that flows from this need might read: “The device exterior shall be able to be cleaned using disinfecting wipes used in a hospital setting.” A second design input might be: “The device exterior shall be made of materials compatible with disinfecting wipes used in a hospitals”. And there would be a few more DIs to fully translate that singular UN.

Using the term needs specifically in our user need statement reinforces and reminds the PD team of its intent and priority—it’s the driver, the ultimate goal of the product under development. Whereas the DI uses the device as the noun followed by the verb shall and focuses on the device itself and the requirement it must fulfill so the user can successfully meet the need it’s linked to. When we see shall we’re reminded that we will verify through testing that the device output meets the design input requirement in question.

We’re not alone in this philosophy. This methodology is consistent with the recommendation by the International Council on Systems Engineering (INCOSE), the not-for-profit organization founded to advance the state of the art and practice of systems engineering. To my knowledge no other organization has put more thought and effort into establishing best practices for this critical activity in product development, and I highly recommend accessing their Guide to Writing Requirements for a deeper dive into this practice.

The Takeaway: Clear Structure Enables More Efficient V&V

A user need is written: “A <user> needs to accomplish <something specific> with the <device>”, and an associated design input is: “The <device> shall deliver <functionality>”. This structure makes verification and validation activities clear and obvious to the development team and has become best practices at Archimedic. In a subsequent blog, I’ll discuss how we think about V&V activities at the time of crafting our requirements.

Clear user needs and design inputs are the foundation of effective design controls and V&V. Archimedic helps MedTech teams strengthen requirements, traceability, and regulatory readiness. Contact us to learn how Archimedic can support your MedTech development program.

Reference: INCOSE Technical Paper, Guide to Writing Requirements, July 2023