Design Inputs Have Two Categories. Two.

Most Design Input problems start with overcomplication. Teams invent five or six categories of input. Marketing inputs. Engineering inputs. Stakeholder inputs.

Most Design Input problems start with overcomplication.

Teams invent five or six categories of input. Marketing inputs. Engineering inputs. Stakeholder inputs.

The list grows. The trace breaks.

There are two categories. That is the whole list.

User Needs and Intended Uses. Qualitative. What the user requires and the conditions of use.

Product Requirements. Quantitative. Testable, with tolerance and units.

The catheter shall reach the target lesion is a User Need.

Catheter working length shall be 86 plus or minus 3 cm is a Product Requirement.

One is the why. One is the measurable what.

Every Product Requirement should trace back to a User Need.

If it does not, you are designing to a requirement nobody asked for.

Every User Need should resolve into at least one Product Requirement.

If it does not, you are validating against a need you never specified.

21 CFR 820.10(c) and ISO 13485 Section 7.3 ask for inputs that are complete, unambiguous, and verifiable.

Two clean categories get you there. Six muddy ones do not.

Keep the list short. Keep the trace intact.

rmForge builds the Hazard Analysis on top of this structure, so risk controls land as real Product Requirements with IDs, not loose notes.

#MedicalDevices #DesignControls #ISO13485 #DesignInputs #QMSR #MedTech