Design Inputs for Combination Products: Turning User Needs Into Testable Requirements
22 Sep 2026
A combination product can have an excellent drug formulation, a technically capable delivery device, and a well-established manufacturing process—and still fail to meet the needs of the person who will ultimately use it. The problem often starts much earlier than verification or validation. It starts with requirements.
If the user’s needs are vague, the design inputs will usually become vague. If design inputs are vague, engineers have difficulty knowing exactly what to design, testers have difficulty determining what to verify, and the development team may discover late in the project that an important user expectation was never properly translated into a measurable requirement.
This is important for drug-device combination products, where pharmaceutical, engineering, human-factors, quality, regulatory, and manufacturing considerations must come together. So, how can an organization turn a statement such as “the device should be easy to use” into something that can actually be designed, tested, and validated?
The answer begins with a disciplined connection between user needs, requirements, design inputs, risk controls, and verification.
What Are Design Inputs?
Design inputs are the documented requirements that define what the product is expected to achieve or what characteristics it must have.
User needs generally describe the what from the user’s perspective, while design inputs translate those needs into more specific and measurable requirements that can guide engineering and later verification activities.
For example:
User need:
The patient should be able to activate the autoinjector easily.
Design input:
The activation force of the autoinjector shall not exceed a defined maximum value under specified operating conditions.
The first statement communicates an important expectation, but it cannot easily be tested.
The second provides an objective requirement against which the design can be evaluated.
This distinction is critical because design inputs eventually become the foundation for design outputs, verification, validation, and traceability.
Why Are Design Inputs More Challenging for Combination Products?
For a conventional medical device, design inputs primarily address the device and its intended use.
For a combination product, the organization must consider the drug, device, user, interfaces, and intended therapeutic use together.
A delivery device may need to accommodate:
- the viscosity of the drug formulation;
- the required dose volume;
- the intended route of administration;
- storage and environmental conditions;
- shelf life;
- user capabilities;
- dose-delivery accuracy;
- packaging requirements;
- human-factors considerations; and
- applicable regulatory requirements.
This means that a requirement developed by an engineering team may have consequences for the pharmaceutical development team, and vice versa.
For example, a change in drug viscosity may affect the force required to deliver the dose. A change in the device mechanism may affect dose delivery. A change in the target user population may introduce new usability requirements.
This is why combination-product requirements need to be developed through cross-functional collaboration, rather than being handed from one department to another.
1. Identify the Intended Users
The first step is to understand who will actually use the combination product.
The intended user could be:
- a patient;
- a caregiver;
- a nurse;
- a physician;
- a pharmacist;
- a technician; or
- more than one of these groups.
Different users can have very different needs.
Consider an autoinjector intended for both younger and elderly patients. The younger user may be concerned about discreet administration, while an elderly user may experience reduced dexterity or vision. These differences can influence grip, activation, instructions, feedback, packaging, and other product characteristics.
User needs should therefore be established using appropriate research rather than assumptions. Human-factors research can include observation, interviews, contextual investigation, and usability activities to understand how users actually interact with products.
The question is simple:
Does the development team know what users actually need, or only what the team assumes they need?
That distinction can have a significant effect on the final design.
2. Define User Needs Clearly
User needs should describe the expected outcome without unnecessarily prescribing the technical solution.
For example:
“The patient should be able to administer the prescribed dose without assistance.”
This describes the desired outcome.
It does not yet say whether the product should use a button, lever, spring mechanism, electronic interface, or another technology.
Keeping the user need at the appropriate level allows the engineering team to evaluate different possible solutions.
A common problem occurs when organizations write a technical solution as though it were a user need.
For example:
“The product shall have an automatic spring-loaded activation mechanism.”
That is already a design decision.
A better user need might be:
“The patient should be able to initiate administration without requiring excessive manual force.”
The technical solution can then be developed and justified through the design process.
3. Break Broad Needs Into Specific Requirements
One user need can generate several design inputs.
Consider the statement:
“The device should be suitable for home use.”
What does suitable actually mean?
Does it mean:
- easy to operate?
- easy to store?
- safe to transport?
- usable without professional assistance?
- resistant to foreseeable misuse?
- understandable through the instructions?
- operable under normal household conditions?
A broad user need should therefore be decomposed into its relevant requirements.
This is an important step because requirements that appear simple can contain several underlying expectations. A structured decomposition process helps prevent important requirements from being lost during development.
4. Convert Requirements Into Measurable Design Inputs
This is where a user expectation becomes an engineering requirement.
A good design input should be sufficiently clear that different people can interpret it in the same way and determine objectively whether it has been met.
Compare:
Weak:
“The device should be lightweight.”
Better:
“The device shall have a maximum mass of X grams.”
Or:
Weak:
“The device should be easy to activate.”
Better:
“The activation force shall not exceed X N under defined operating conditions.”
The exact numerical value must come from the product’s intended use, user research, risk analysis, applicable standards, engineering evaluation, and other appropriate evidence. It should not simply be invented to make a requirement appear measurable.
The principle is:
If a requirement cannot be objectively verified, it may not be a sufficiently developed design input.
5. Include Combination-Product Interface Requirements
This is where combination products differ significantly from many conventional device-development projects.
The development team should identify requirements that exist specifically because the drug and device are being used together.
For example, requirements may address:
- drug-device compatibility;
- dose delivery;
- container closure;
- material compatibility;
- drug stability;
- device performance;
- delivery force;
- dose accuracy;
- storage conditions;
- transportation;
- shelf life; and
- interaction between the formulation and delivery mechanism.
Ventura Solutions emphasizes that combination-product development requires attention to the device strategy, technical compatibility, human factors, design controls, and manufacturing readiness, with drug characteristics such as viscosity, dose volume, and stability potentially influencing device selection and performance. (Ventura Solutions)
This interface should not be treated as an afterthought.
If the drug and device are developed independently and only tested together late in the program, problems can become expensive to correct.
6. Connect Design Inputs With Risk Management
Design inputs should not exist independently from risk management.
A significant risk may require one or more design requirements to reduce that risk.
For example:
Hazard: Incomplete dose delivery.
Potential cause: Excessive injection force.
Risk control: Establish an acceptable delivery-force requirement.
Design input: The device shall deliver the specified dose within the defined force range under specified conditions.
Verification: Test the delivery force and dose delivery using an approved test method.
This creates a logical chain:
Risk → Risk Control → Design Input → Design Output → Verification
Such connections are particularly valuable during design reviews and regulatory inspections because they demonstrate why a requirement exists.
7. Make Every Design Input Verifiable
A design input should ultimately have an appropriate method of verification.
This is one of the most useful questions a development team can ask when reviewing requirements:
How will we prove that this requirement has been met?
If the answer is unclear, the requirement may need to be rewritten.
For example:
Requirement: The device shall be intuitive.
How will this be verified?
The term intuitive is subjective unless it is translated into defined user-performance criteria.
A more useful requirement might relate to specific user tasks, critical errors, completion criteria, or other measurable characteristics established through the human-factors program.
User needs can be validated through appropriate simulated-use or clinical-use activities, while technical design inputs may be verified through testing, inspection, analysis, or other suitable methods. The selected method should be appropriate to the requirement.
8. Maintain Traceability From User Need to Verification
A strong requirements structure should allow the organization to trace the development logic from beginning to end.
A simplified traceability chain may look like this:
User Need
↓
User Requirement
↓
Design Input
↓
Risk Control
↓
Design Output
↓
Verification / Validation
For example:
| Development Element | Example |
| User Need | Patient needs to administer the dose without assistance |
| User Requirement | Device should be operable by intended home users |
| Design Input | Activation force shall be ≤ defined limit |
| Design Output | Selected activation mechanism and components |
| Verification | Activation-force testing |
| Validation | Representative-user simulated-use evaluation |
Traceability is not merely a documentation exercise. It allows the development team to answer important questions:
Why does this requirement exist?
Which user need does it support?
Which risk does it control?
How was it verified?
And perhaps most importantly:
What happens if this requirement changes?
Software similarly emphasizes that traceability between user needs and design inputs provides the evidence that the design is directly driven by user requirements and supports verification and regulatory compliance.
9. Review and Control Requirements Throughout Development
Design inputs are not necessarily static documents that are written once and forgotten.
As development progresses, new information can emerge from:
- feasibility studies;
- risk assessments;
- formative usability studies;
- engineering testing;
- regulatory feedback;
- clinical development;
- manufacturing studies; and
- changes to the drug formulation or device.
A new finding may require a requirement to be clarified, or an existing requirement to be changed.
However, changes should be controlled and their impact assessed.
For a combination product, a slight change can have consequences across multiple functions.
A change in formulation could affect the delivery mechanism. A change in the delivery mechanism could affect usability. A change in the intended user population could affect human-factors requirements.
This is why requirements management should remain connected to the broader design-control system.
Conclusion
Design inputs are where user expectations become controlled engineering requirements.
For combination products, this process is important because the final product must bring together the performance of a medicinal product, delivery device, packaging, manufacturing process, and user experience.
A robust approach therefore requires the organization to:
- Identify intended users and their needs.
- Define user needs without prematurely prescribing a technical solution.
- Decompose broad needs into specific requirements.
- Convert requirements into measurable and verifiable design inputs.
- Address drug-device interface requirements.
- Connect requirements with risk management.
- Define how every important requirement will be verified or validated.
- Maintain traceability throughout the design and development process.
- Control requirements as the product strengthens.
The objective is not to create a large requirements document simply because the development process requires documentation.
The objective is to create a clear development logic in which every important requirement has a reason, every critical risk has an appropriate control, and every requirement can ultimately be demonstrated to have been satisfied.
When this discipline is established early, design inputs become more than engineering paperwork. They become the foundation that connects user needs, design control, risk management, verification, validation, and ultimately patient safety.
How TS Quality & Engineering Can Help
Developing clear and traceable design inputs for a combination product can require coordination between pharmaceutical, engineering, quality, regulatory, and human-factors teams. TS Quality & Engineering can support organizations with combination-product design controls, user needs and design inputs, risk management, design verification and validation, traceability, and broader product-development activities. If your organization is developing a new drug-device combination product or needs to strengthen an existing design-control system, contact TS Quality & Engineering to discuss your requirements and development needs.
