How to Define Your Design Inputs and Design Outputs

In the FDA’s classic waterfall diagram of design controls, design inputs and design outputs are linked by the process of verification.

To put it simply, a crucial part of your design controls process is verifying that the design outputs you’ve created meet the design inputs you specified earlier in the design process. In other words, did we build this device right?

While this may seem simple enough, the verification process sometimes becomes a big problem for teams that rush through defining their design inputs and outputs. To make sure this doesn’t happen to you, let’s take a look at design inputs and design outputs, along with how to define them to avoid issues during verification.

Free Bonus Resource: Need help defining your user needs? Grab our free tips here.

What are design inputs?

FDA has described design inputs as the most important part of the entire design control process. Here’s what the agency says in their guidance document on design controls:

Design input is the starting point for product design. The requirements which form the design input establish a basis for performing subsequent design tasks and validating the design. Therefore, development of a solid foundation of requirements is the single most important design control activity.

The design inputs are the most critical aspect of the overall medical device product development effort. Why? They determine functional and performance criteria, which define everything that your device needs to do. Essentially, they provide the foundation for your device.

You’ll probably hear people within MedTech use the terms “design requirements,” or simply “requirements,” when referring to design inputs. These terms are all synonymous when we’re talking about medical device design and development. 

When a device that’s already on the market has issues, you can almost guarantee there will be an underlying cause in its design inputs. And it’s often the case that they simply weren’t sufficiently defined. Everyone is keen to get their device onto the market as soon as possible, but it’s worth spending some extra time defining your design inputs. There’s even a common school of thought that says design inputs should take up about 30% of your project timeline.

How should you write your design inputs?

Well-crafted design inputs are stated in a way that is measurable and provides clear objective criteria. As you write them, keep in mind some of the goals that you’re trying to meet with these requirements. Your design inputs should:

• Use clear and objective language
• Be measurable—so that you can prove (or disprove) them later on
• Build upon your user needs and intended use
• Capture all performance, regulatory, functional, and safety requirements

As you consider how to define your design inputs, it may be helpful to look at regulations, industry standards, and prototypes, but the best place to start is always with your user needs.

What does it mean for a requirement to be verifiable?

It’s important to think ahead when you determine design inputs. Think about the design verification process (even though that may be months ahead). You’ll do yourself a huge favor if you consider how you will need to verify the requirements later in the development process. This doesn’t mean you need to go ahead and design all of your testing protocols early, but just be aware of creating clear, objective criteria.

This doesn’t have to be complicated, either. Some of your design inputs may be related to simple criteria like the length of the design. To verify that, you’ll just need to go ahead and measure the device! Certainly, many other design inputs will be more complicated and require a lot more thought about how you plan to verify them. My point is simply that you should think ahead as you write them because it will save you an enormous amount of time later on. 

Many companies define great design inputs but don’t think about design verification. Then a few months down the road, they realize they’ve painted themselves into a corner because they can’t prove some of their inputs or doing so will require extensive testing. Of course, the more complicated or extensive the testing, the more costly the exercise becomes, too. Your boss will appreciate knowing this sooner rather than later. So will your project manager!

What are design outputs?

You can think of design outputs as the preliminary recipe for your device. That’s because the design outputs describe everything that goes into the medical device. These descriptions may include drawings, components, materials, parts, pieces, specifications, manufacturing instructions, and inspection procedures. Your design outputs are the documentation you would need should you be tasked with assembling this medical device from scratch.

Remember, your design outputs will need to be verified against your design inputs. This is why I’ve been harping about thinking ahead and creating verifiable design inputs. If you said that one of your requirements was that the device must have specific dimensions, you should be able to verify that your design outputs include those dimensions. 

And keep in mind, the outputs must be proof of your stated inputs. You can’t simply reword a statement like, “The device is five centimeters long.” Instead, your design outputs should be something that describes the device in more detail, like a drawing or specification. And your outputs will need to refer to acceptance criteria, and the design verification process will determine whether those criteria are met and your outputs meet your inputs.

What is the relationship between design outputs and your Device Master Record?

If your design outputs are the preliminary recipe for your device, the Device Master Record (DMR) is the final recipe. Your DMR will contain everything you need to know to build and test your device. 

Your design outputs are a preliminary round for your DMR. Design outputs are captured and documented initially during the design and development process as you’re figuring out parts, pieces, materials, and how you’ll manufacture the product.

Free Bonus Resource: Need help defining your user needs? Grab our free tips here.

Spend less time documenting and more time designing with Greenlight Guru

Documenting your design controls process on a paper-based QMS is a complex and manual process that’s riddled with chances for errors and broken traceability. At Greenlight Guru, we knew there had to be a better way, which is why we built our Design Control Software specifically for medical device professionals. 

With Greenlight Guru Quality, you can quickly create design control objects, link complex configurations, and attach related documents with a few clicks. You’ll also be able to create and update your traceability matrix and schedule design reviews in minutes—instead of hours or days. On top of that, your design controls are seamlessly integrated with risk management, giving you a complete and accurate picture of risk throughout the entire product lifecycle.

If you’re ready to see how a MedTech-specific QMS can accelerate your design and development process, then get your free demo of Greenlight Guru→