From user research to verifiable requirements: a lifecycle framework for medical-device teams

User research produces narrative artifacts. A journey map. An intended use statement. A list of pain points. An inventory of use environments. A workflow with annotated friction points.

Design controls under 21 CFR 820.30 require the opposite — discrete, measurable design inputs that pass the test in 820.30(c): appropriate to the device, addressing the needs of the user and patient, with a mechanism for resolving incomplete, ambiguous, or conflicting requirements.

Between the narrative artifacts of user research and the verifiable statements of design inputs, there is a translation step. This is a practitioner's framework for that translation step — what each stage looks like, what artifacts each stage produces, and what traceability each stage owes to the next.

The translation gap

A user need that says "the clinician should be able to set up the device quickly between cases without losing sterility" is not yet a design input. It is a narrative statement that compresses several decisions: what does "quickly" mean? What does "set up" include — packaging removal? device configuration? priming? user training? What does "losing sterility" mean — a sterility test failure, a sterile-barrier breach, a procedural violation?

Each of those questions has to be answered before the statement becomes verifiable. The translation step is where the answers are decided and recorded. Programs that skip this step write design inputs that look verifiable but are actually paraphrases of the narrative — at verification, they are tested against an engineering-team interpretation of the original need, and the audit trail breaks in the same place every time.

A five-stage framework

The framework that closes this gap has five stages, each producing a named artifact and each owing specific traceability to the next:

1. Stage 1 — Use specification. Per IEC 62366-1:2015 §5. The narrative anchor.
2. Stage 2 — User needs and use scenarios. Discrete user-need statements + a use-scenario inventory covering normal use, reasonably foreseeable misuse, and hazardous use scenarios.
3. Stage 3 — Design inputs with verification approach. The translation. Each design input is verifiable and pairs with a method and acceptance criterion at approval time.
4. Stage 4 — Design outputs and traceability. Drawings, specifications, software, processes — each tracing back to specific inputs.
5. Stage 5 — Verification and validation. Verification confirms outputs meet inputs (820.30(f)); validation confirms the device meets user needs in use (820.30(g)).

The remainder of this note is one section per stage.

Stage 1 — Use specification (IEC 62366-1:2015 §5)

IEC 62366-1:2015 §5 requires the manufacturer to prepare a use specification that documents:

• The intended medical indication;
• The intended patient population;
• The intended part of the body or type of tissue applied to or interacted with;
• The intended user profiles;
• The intended use environment(s);
• The operating principle.

The use specification is the upstream input to almost everything downstream — it anchors the user-interface specification (§6), the use-related risk analysis (§6.2), and the user-interface evaluation plan (§7). It is also the primary source for the "needs of the user and patient" that 21 CFR 820.30(c) requires design inputs to address.

Stage 2 — User needs and use scenarios

From the use specification, two derived artifacts emerge: a discretized list of user needs (each as a single statement, owned by a single user role, in narrative form) and a use-scenario inventory.

User needs — discretization

The use specification is necessarily holistic. The user-needs list breaks it into atomic statements that can each be evaluated for feasibility and translated into a design input. A useful test: each user need should describe a single observable outcome from the user's perspective. A statement that bundles two outcomes ("the device should set up quickly and operate quietly") becomes two user needs.

Use scenarios — coverage

The use-scenario inventory should cover three categories: normal use (the typical sequence of user actions), reasonably foreseeable misuse, and hazardous use scenarios. IEC 62366-1:2015 §6.2 calls out hazardous use scenarios specifically — sequences of user actions that could lead to harm. Each hazardous use scenario maps to one or more risk control measures per ISO 14971.

Stage 3 — Design inputs with verification approach

This is the translation step. Each user need produces one or more design inputs. Each design input is written to be verifiable and carries, at the time of approval, a verification approach and a target acceptance criterion.

Continuing the earlier example, the user need:

The clinician should be able to set up the device quickly between cases without losing sterility.

becomes one or more design inputs of the form:

DI-014: The device shall complete setup from packaging removal to ready-to-use state within 90 seconds when operated by a trained clinician per the labeled procedure. Verification approach: timed observational test, n=10 trained clinicians, target ≤90 seconds in 9/10 trials with 95% confidence (one-sided binomial).

DI-015: The sterile barrier shall remain intact through the labeled setup procedure when performed per the instructions for use. Verification approach: bubble-leak test per ASTM F2096 on n=30 units after simulated setup, AQL 0.65.

Note three properties of the translation:

• The narrative word "quickly" has been resolved to a measurable target. The decision (90 seconds) is recorded at the design-input level, with the rationale documented in the requirements record.
• The compound need ("quickly without losing sterility") has been split into two design inputs. Each is independently verifiable.
• The verification approach is named at design-input approval — not left for the verification team to decide later.

Stage 4 — Design outputs and traceability

Design outputs under 21 CFR 820.30(d) are the drawings, specifications, software builds, and process descriptions that implement the design inputs. The traceability requirement is bidirectional:

• Every design input has at least one design output that implements it (forward traceability).
• Every design output references the design input(s) it implements (backward traceability).

The simplest tooling is a traceability matrix that names each design input on one axis and each design output on the other, with cells marking implementation. The same matrix extends to the right with verification protocols (§820.30(f)) and validation evidence (§820.30(g)).

Stage 5 — Verification and validation

21 CFR 820.30(f) requires design verification to confirm that design outputs meet design inputs. Because the verification approach was decided at the time the input was approved (Stage 3), each verification protocol is a near-direct restatement of the approach-and-acceptance-criterion already in the input — with the details of test setup, sample preparation, and pass/fail conditions elaborated.

21 CFR 820.30(g) requires design validation to confirm that the device conforms to user needs and intended uses. Validation closes the loop back to the user-needs list and the use specification: each user need is validated, in actual or simulated use environments, by evidence that the device — operated through the intended use scenarios by the intended user profile — meets the original need as narrative-stated.

Where design verification is testing against design inputs, validation is testing against user needs. The translation step in Stage 3 is what makes both possible without contradiction.

Practitioner summary

The user-research-to-verifiable-requirements gap is one of the highest-leverage places to invest engineering rigor in a regulated-product program. Programs that build the translation step explicitly — as a named artifact, owned by a named role, reviewed and approved with the same rigor as the inputs themselves — produce design history files that audit cleanly and verification plans that do not surprise anyone.

Programs that don't pay the cost in retroactive curation: a traceability matrix assembled before submission, a verification protocol that conveniently aligns with the design output rather than the design input, and a validation report that compares the device to a paraphrase of the original need.

For where this fits in the broader lifecycle, see Why medical device development breaks down between user needs, engineering, and manufacturing. For the regulatory-and-design-controls service area, see Regulatory, Quality & Design Controls.