Medical Device Design Between Clinical Needs, Usability and Engineering

What actually makes a medical device design decision defensible when regulators, clinicians, and engineers each expect something different from the same interface? A defensible decision is one you can trace — from an observed clinical task, through a measurable design input, to usability evidence and verification data. This traceable chain is what this article calls an evidence loop: the path from a user need to a design input, a design output, and the verification or usability evidence that confirms it, repeated at increasing fidelity as the design matures. That chain is what separates a design rationale from a guess that happened to work.

The idea is not arbitrary. IEC 62366-1:2015 specifies a process for a manufacturer to analyze, specify, develop, and evaluate the usability of a medical device as it relates to safety, and the standard’s own abstract describes stronger ties to ISO 14971 and related risk-management methods for the safety-critical parts of a user interface. Usability engineering and risk management are meant to run together, not as two checklists signed off in separate meetings weeks apart. Industrial design and engineering studios that work across regulated and consumer sectors alike tend to build their process around exactly this kind of iteration — among them PQ DESIGN, a multidisciplinary studio whose method sits close to what this piece describes: translating a clinical observation into a design input, then into tested evidence, without losing the connection between the two.

Why a clinical need is not a requirement yet

Take a routine example: a nurse setting up an infusion pump at the start of a shift says the pump should be easier to set up. That is a real signal, but it is not yet a design input. An unmet clinical need describes a problem — who experiences it, in which setting, under which constraints — while a requirement describes a measurable attribute the device must satisfy: the number of steps to confirm a flow rate, say, or the force needed to lock a line in place.

Confusing the two is a failure mode worth naming because it recurs across very different device types: a device can improve a clinical metric on paper and still struggle in practice because it adds two minutes to a nursing shift, forces retraining every time staff rotate, or introduces a new contamination risk at the point of use. Capturing workflow reality usually takes more than asking a physician what they want. Direct observation, stakeholder mapping across the full care team, and task decomposition tend to surface frictions that no single stakeholder would mention alone — the nurse setting up the pump is rarely the same person who responds to its alarm two hours later.

From workflow to design inputs: turning care pathways into engineering constraints

Once the workflow is mapped, the next step is defining users, environments, and use scenarios with enough precision to guide engineering decisions. A home-use scenario, an ICU, an ambulance, and a lab bench each impose different priorities: lighting, available surface space, ambient noise, time pressure, and whether the operator is wearing gloves or protective equipment can all change what counts as usable in that setting. The same pump that is intuitive on a bright hospital ward can become unreadable in a dim ambulance bay.

Translating tasks into measurable design inputs is where industrial design and engineering start working from the same brief. Depending on the device and its intended environment, that often means parameters such as actuation force, reach envelope, text and icon readability at a given distance, alarm audibility against ambient noise, cleaning-cycle tolerance, and the number of steps required to complete a critical task under stress. A pump’s alarm, for instance, may need to stay distinguishable from three other devices beeping in the same room — a requirement that only becomes obvious once someone decomposes the task instead of describing it in general terms. Traceability becomes a practical design tool at this stage, not an administrative burden: linking each user need to a design output and a corresponding test is what lets a team explain, later, why a specific button size or a specific material was chosen, and what would change if it were not.

Usability is patient safety, not a layer applied later

Use errors — and uses that fall outside a device’s intended conditions — tend to originate in the interface and the physical form of the device, which is why they need to be anticipated early rather than discovered during a late-stage audit. Back to the pump: if acknowledging an alarm requires the same gesture as silencing it permanently, that ambiguity is a design problem, not a training gap to patch with a laminated card taped to the wall.

Formative usability work, run early and often with low-fidelity prototypes, is where a team learns what confuses people before the design is frozen. Summative usability testing, run later under more controlled conditions, is where a team demonstrates that the final interface performs safely for its intended users. Skipping or compressing the formative stage does not guarantee a problem downstream, but it removes the main opportunity to catch comprehension issues while they are still cheap to fix — and issues caught during summative testing, or after launch, rarely are. Labeling, feedback, affordances, and a clear path to error recovery deserve the same rigor under high-stress, time-pressured conditions as under calm ones, arguably more, since that is when the device actually gets used. Hand strength variability, vision limitations, and the cognitive load of fatigue or emergency situations can function as risk-reduction inputs from the start, rather than accommodations added if time allows.

It helps to be precise about what each standard actually asks for. IEC 62366-1 specifies the process itself — the steps a manufacturer follows to analyze, specify, develop, and evaluate usability as it relates to safety. IEC 62366-2 is a technical report: it offers background and implementation guidance but does not itself specify requirements. The most recent versions — IEC 62366-1:2015 with its 2020 amendment, and IEC 62366-2:2016 — are recognized consensus standards for FDA submissions, and the base standard carries its own recognition number in FDA’s database. One caveat worth flagging for teams selling into the EU: a harmonised-standards summary list generated in January 2026 did not include IEC 62366-1 among the standards harmonised under the EU MDR. That does not remove the obligation to apply usability engineering — it is simply a detail worth checking directly against current official sources before assuming an automatic presumption of conformity.

Engineering reality check: feasibility, reliability, manufacturability

Material and process decisions in medical devices are rarely style choices. Sterilization method, biocompatibility, chemical resistance to disinfectants, and durability targets over the device’s service life narrow the field of viable materials well before anyone discusses a surface finish. Tolerance strategy, assembly sequencing, and serviceability affect usability as directly as they affect cost of quality: a pump housing that is hard to reassemble correctly in the field will, sooner or later, get reassembled incorrectly.

For connected or electronic devices, latency, power budget, and electromagnetic interference are the kind of constraints that can quietly shape what the interaction design is allowed to promise — a status light that updates half a second late reads very differently in a calm clinic than in an emergency bay. These are illustrative pressures, not universal rules; the specific constraints depend on the device, its electronics, and its intended environment, so they belong in the engineering requirements for that particular project rather than in a generic checklist.

A prototyping ladder helps teams validate the right thing at the right fidelity: looks-like models test form, ergonomics, and first impressions; works-like models test mechanisms, electronics, and performance under conditions approximating real use. Collapsing the two stages too early carries a specific risk: tooling and supplier decisions can get locked in before the mechanism or the electronics have actually been proven, and those decisions are far more expensive to reverse than a prototype is to rebuild.

Risk management as the bridge between clinical, usability, and engineering trade-offs

ISO 14971:2019 specifies terminology, principles, and a process for risk management of medical devices, including software as a medical device and in vitro diagnostics; the standard was last reviewed and confirmed current in 2025. Its core definition of risk — the combination of the probability of occurrence of harm and the severity of that harm — gives a team shared vocabulary for decisions that would otherwise default to whoever drafted the spec first. Regulatory guidance has also pointed out that there is no single statutory definition of risk outside frameworks like this one, which is exactly why a documented risk process carries more weight than intuition when a design choice gets questioned later.

Use-related risk analysis works by mapping critical tasks and foreseeable misuse back into design requirements: a hazard becomes a hazardous situation under specific use conditions, and a hazardous situation becomes harm only if nothing in the design, the labeling, or the training intervenes. The genuinely difficult trade-offs happen at this stage — a physical interlock is often more robust than a software prompt, because it cannot be dismissed under time pressure, but it adds mechanical complexity and cost. Deciding between simplifying a workflow and adding a safeguard rarely has an obvious answer, and the decision is defensible only if the reasoning behind it is written down rather than assumed to be self-evident.

Whatever the team composition, the reasoning behind each trade-off belongs in a record that can be pointed to later:

the use-related risk analysis linking tasks to hazards and mitigations
a requirements register distinguishing negotiable from non-negotiable constraints
formative usability findings and how each one was resolved
a decision log explaining why one mitigation was chosen over an alternative
verification evidence tying each design output back to its originating need

The evidence loops in practice: a repeatable sequence

None of the previous sections work as one-off exercises; they work as a loop that repeats with increasing fidelity as the design matures. A useful way to structure it:

Discover and define — map the clinical workflow, draft user needs, and raise early risk hypotheses before any concept exists.
Prototype and learn — run formative usability sessions alongside engineering feasibility checks, letting both inform design iterations together rather than sequentially.
Freeze and verify — lock the design intent, run design verification against the specified inputs, and confirm readiness for summative testing.
Validate in context — run summative usability and, where appropriate, clinical or operational validation under conditions that resemble actual use.

Teams run into trouble in fairly recognizable ways: testing too late, when changes are expensive; recruiting usability participants for convenience rather than representativeness; simulating environments cleaner and quieter than where the device will actually be used; and losing traceability between an early user need and the test that eventually confirmed, or failed to confirm, it. None of these are rare mistakes. Building the loop into the development plan from the start, rather than appending it as a compliance step at the end, is generally easier to defend later — both to an auditor and to the team that has to live with the design once it ships.

What a design partner’s method should include

Running these loops well means moving between clinical workflow mapping, industrial design, mechanical and electronic engineering, human factors input, rapid prototyping, and manufacturability analysis without losing the thread between them. Few teams, especially at an early stage, have every one of these capabilities in-house. That gap is one reason design and engineering partners get involved before the industrialization phase rather than after it — concept design and product design work, done well, already anticipate the manufacturing and usability questions that would otherwise surface during tooling.

In a published interview, the studio behind the link above is described as founded in 2009 by Piero Quintiliani, reporting — as of August 2025 — three offices in Milan, Pisa, and Shenzhen and more than 150 client engagements worldwide. It is portrayed as specializing in industrial design, combining engineering expertise with strategic vision across an integrated process running from concept design through industrialization, spanning product development, branding, and hardware and software design. Among the projects mentioned is Isola Oki, developed for LM Medical and presented as an example of moving clinical and engineering constraints into a device built for production rather than a concept render. These are figures and descriptions as reported in that interview, worth treating as a starting point for a conversation rather than as independently verified claims.

What matters more than headcount or client count, when evaluating any partner for this kind of work, is whether they can show how a requirement traveled from an observed clinical task to a tested design output — and what got documented along the way.

Turning the method into a decision at kickoff

Before a project starts, it is worth asking a prospective design or engineering partner to walk through one past loop end to end: which clinical observation generated a requirement, which prototype tested it, what the formative usability session revealed, and how the risk file changed as a result. A team that answers with specifics, rather than general claims about experience, is one that treats traceability as a working habit rather than paperwork added after the fact. That single conversation often reveals more about a partner’s fit than a client list or a sector logo, because it shows whether the loop between clinical reality, usability evidence, and engineering constraint is something the partner actually runs — or something they describe only once the design is already finished.