Part 5 of 5-Part Series: Design Input and Output Matrix - One Table That Holds Design Control Together

rmforge.io | Part 5 of a 5-Part Series on Design Controls | May 23, 2026
Design Inputs tell the team what to design. Design Outputs are the specifications that detail what is to be built. Design Verification and Design Validation (DV&V) prove the outputs met the inputs. Risk management techniques assess hazards and failure modes to create risk control measures through requirements (inputs), implementation (outputs), and verification (DV&V) thereby reducing risk. Each of these lives in its own document, and that is exactly where projects can lose the thread. The Design Input and Output Matrix along with a comprehensive Hazard Analysis is the design table that ties all of it together, row by row, with a traceable identifier on every requirement.
This article gives the working structure of the matrix, what belongs in each column, and the issues that show up in a review when a column is skipped or filled out wrong.
What the Matrix Does
The matrix answers one question: can you trace each User Need and Intended Use to its Product Requirement, to the Design Output, to the Hazard or Failure it mitigates, and to the DV&V record that resolves it? When that answer is one table, a reviewer's scan builds the cognitive context in a single pass, the frame that lets an experienced eye catch the missing control or the requirement with no output before anyone points to it. Spread the same answer across five disconnected documents, or isolated cells in a digital QMS, and that context never forms. The trace is reconstructed by hand every time or stitched together in yet another document. That is creating the potential for design dissonance: technically traceable on paper, never absorbed and too disconnected. The matrix makes the trace the structure of the record itself.
Bottom line: It’s about finding design gaps to make the product safer.
Per 21 CFR 820.10(c) (Quality Management System Regulation, or QMSR) and ISO 13485:2016 Section 7.3.3, design input documentation shall be complete, unambiguous, and traceable. The matrix is the artifact that demonstrates that trace.
The Column Set
The matrix runs in four section blocks: Design Input, References and Justifications, the Bridge to Risk (Risk ID) and Evidence (DV&V), and Design Output. The exemplary column order below matches a working matrix.
Section 1. Design Input Columns
- User Requirement ID: unique identifier for each User Need and Intended Use. Naming convention is fixed early and never reused.
- User Requirement Category: Design, Functional, or similar classification used to organize and filter inputs.
- Design Input, User Requirement: the qualitative, high-level need. One or two sentences in usability, clinical, biological, or market terms. "The disc replacement shall endure the patient's activities of daily living."
- Product Requirement ID: unique identifier for each quantitative requirement. A single User Requirement can spawn several Product Requirements, each with its own ID.
- Design Input, Product Requirement: the quantitative, testable requirement with tolerance and units. "Catheter working length shall be 86 +/- 3 cm."
Section 2. Reference and Justification Columns
- Reference: the standard, guidance, or regulation that supplies the test method, preparation, or requirement. List the specific reference (for example ISO 25539-2 for cardiovascular implants), not the high-level QMS standard. ISO 13485 and 21 CFR Part 820 do not belong here.
- Justification: the why behind the requirement. Clinical or scientific literature, bench data, a standard, or a controlled Technical Document. Industry-fundamental values may carry "N/A"; an open question carries "TBD" during early phases. The Justification is important because it is providing a rational basis for a risk-reducing design requirements. This reduces requirement selection by fiat.
Section 3. The Bridge: Risk and Evidence
- Risk Control (Risk Output, e.g., Risk ID): the alphanumeric identifier assigned in the Hazard Analysis or FMEA for the risk control measure that this Design Input implements, per the Risk Management procedure. If a risk control requirement is not a Design Input with an ID, it is less traceable and would be indicative of a preliminary Hazard Analysis or an incipient design control system.
- Evaluation Method, DV&V Record: the identifier of the verification or validation record that demonstrates the output met the input. List the alphanumeric ID of the protocol (if no report to date), report, or QMS-released inspection record, and not just a description.
Section 4. Design Output Column
- Design Output, Production Specification: the design output evidence. Device Master Record (DMR), component, subassembly, final assembly, finished good, label, Instructions for Use (IFU), or packaging specification identifiers.
The Matrix in Practice
A single row threads one requirement through the full set of columns. The example below is a condensed view of how one User Requirement and its Product Requirement read across the matrix.
UR ID | Design Input: User Requirement | PR ID | Design Input: Product Requirement | Reference | Risk Control ID | DV&V Record | Design Output |
UR-006 | Catheter working length shall be capable of reaching the target anatomy for stent delivery. | PR-008-001 | Catheter working length shall be 86 +/- 3 cm. | ISO 25539-2, ISO 10555 | HA-0001, FMEA-00001 | TR-00202 | Stent & Delivery System: FA00001 |
UR-005 | Catheter tip shall be atraumatic during advancement. | PR-006-001 | Distal catheter tip shall be 50±10 Shore A durometer material, and minimum of 0.010” rounding on OD edge. | ISO 10555 | HA-0001, FMEA-00001 | TR-00203 | Delivery Tip Assembly: SA00028 |
Read left to right: the qualitative User Requirement, its quantitative Product Requirement, the Reference standard that supplies the industry framework, the Risk Control ID that the requirement mitigates, the traceable evidence that DV&V Record proves the resolution of output to input, and the Design Output (production specification) that realizes it. Every cell carries an identifier or an explicit "N/A" or "TBD according to development phase." An empty cell is a gap; fill it with a meaningful and traceable record. Justification is not shown here.
Where Matrices Fail
Inputs With No Output
A Product Requirement with a populated DV&V column but an empty Design Output column means the team verified a production specification that does not formally exist. The protocol was written against a moving target. Fill the Design Output along with the DV&V record referencing it. Along with a lot history record, this proves the DV test was done with a traceable Design Output.
Risk Controls That Never Became Inputs
Per ISO 13485:2016 Section 7.3.3, design inputs shall include applicable outputs of risk management. A risk control selected in the Hazard Analysis but absent from the Risk Control column is a control that exists on paper and potentially nowhere in the design. It cannot be verified, and anyone tracing the Hazard Analysis into the matrix will find the gap.
References That Govern Instead of Specify
Listing ISO 13485 or 21 CFR Part 820 as a Reference for a specific requirement is a category error. Those are QMS-governing standards, not the standardization or method behind a tensile load or a leak rate. The Reference column is for the standard or guidance that defines how the requirement is detailed, met, or measured.
Open Cells Left Unmarked
An empty cell reads as an omission. A cell that is genuinely not yet applicable reads as "TBD"; one that is not applicable at all reads as "N/A." The difference tells a reviewer whether the project is incomplete or the requirement simply does not apply. Silence does neither.
Why It Matters
- Clarity: one row holds the complete story of a requirement, from need to requirement to specification to evidence.
- Alignment: every Product Requirement maps back to a User Requirement, and every Risk Control maps to a Design Input.
- Documentation: the matrix is the Design History File (DHF) trace artifact a reviewer expects to see.
- Regulatory: 21 CFR 820.10(c) (QMSR) and ISO 13485:2016 Section 7.3.3 require complete, traceable design input documentation. The matrix demonstrates it directly.
The 5-Part Series
- Part 1: Design Inputs
- Part 2: Design Outputs
- Part 3: Design Verification and Design Validation
- Part 4: Risk Management in Design Control
- Part 5: Design Input and Design Output Matrix (this article)
References
Quality Management System Regulation (QMSR), 21 CFR Part 820. 89 FR 7523, Feb. 2, 2026.
ISO 13485:2016. Medical Devices, Quality Management Systems, Requirements for Regulatory Purposes. ISO, 2016.
ISO 14971:2019. Medical Devices, Application of Risk Management to Medical Devices. ISO, 2019.
Design Control Guidance for Medical Device Manufacturers. FDA, 1997.
ISO 25539-2:2020. Cardiovascular Implants, Endovascular Devices, Part 2: Vascular Stents. ISO, 2020.
Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on Medical Devices. Official Journal of the European Union, 2017.
Questions or feedback: mike@rmforge.io
Try the platform: rmforge.io