There are Design Controls, and then there are Human-Centered Design Controls. Both fulfill the baseline regulatory and risk management requirements necessary to prove a device is safe and effective. The difference? A human-centred approach elevates standard ‘user needs’ beyond basic compliance, ensuring the final product truly resonates with and optimizes the experience for the people who use and buy it. This directly supports market success. And it’s the only approach we take at Cortex.

Here, we demonstrate how human-centered design controls work in practice. We will explore the critical roles of early stakeholder discovery, robust user requirements, and iterative design through a real-world case study: Cohesys, the company behind the innovative BoneTape product. Cortex partnered with the Cohesys team to design the accompanying welding tool ( the Medical Ultrasonic Welder) using this human-centered approach. This work contributed to Cohesys’ industry recognition and supported it in reaching its next major milestones.

First: understanding design controls

Design controls are the systematic processes used to verify and validate that a medical device meets its technical requirements and user needs. This framework results in the Design History File (DHF), which proves how the device was developed, and leads to the Device Master Record (DMR), which dictates how it will be manufactured. The evidence generated during this process forms the backbone of your market submissions to regulatory bodies like the FDA and Health Canada.

These regulators have one main focus: ensuring the safety, effectiveness, and quality of your device throughout their entire lifecycle. Their goal is to protect public health by minimizing risk, preventing harm, and confirming that the device performs exactly as intended for its clinical purpose.

They do not evaluate whether the product will succeed in the marketplace.

Safe and effective ≠ commercial success

Human-centered design controls follow a human-centered design process

Being certified under ISO 13485 means that we must meet quality and design requirements when developing medical devices. But it doesn’t dictate how we execute those requirements. We still have flexibility in our process, as long as we meet the standard.

At Cortex, we don’t just design and engineer devices to generate a compliant Design History File (DHF) and Device Master Record (DMR). We use a human-centered design approach to ensure our ultimate goal goes beyond regulatory clearance: we want the product to succeed in the marketplace.

To do this, we have specific design phases we move through chronologically, with compliance integrated into every step.

User discovery

Design controls start with understanding the intended use; the purpose of the device, including its indications for use (such as the disease or condition it is intended to address and the patient population), as well as how it will be operated by its intended users.  In parallel, user discovery involves identifying specific user profiles and broader stakeholders who will interact with the product.

User discovery is best done in the field. Ideally, this involves ethnographic research, observing your stakeholders and gathering context in their actual environment, like an operating room. It is the process of building empathy by understanding the high-pressure, real-world context where your device will actually be used.

But that’s not always possible. For example, an industrial designer cannot take the place of a surgeon and perform their procedures. They can, however, immerse themselves in that environment and engage directly with stakeholders to understand their requirements, their unmet needs, and their frustrations.

The stakeholders

There are primary and secondary stakeholders. Primary stakeholders are the users who interact directly with the device. Secondary stakeholders encompass the rest of the product’s ecosystem, from the technicians who maintain the device to the hospital administrators and buyers whose opinions dictate whether the device is ultimately adopted.

As primary and secondary stakeholders interact with the device, their opinions and feedback are collected procedurally to capture requirements and generate insights. We map out the entire user journey to understand exactly how the device is handled in the real world. We look at every phase, from unboxing and preparation to the clinical procedure, all the way through to reprocessing, sterilization, and storage. By identifying exactly who is involved at each of those specific steps, we uncover the hidden stakeholders whose needs are critical to the device’s safety and success.

For example:

• Device setup: A nurse sets up the equipment and prepares it for the surgeon.
• Device use: In the operating room, there are sterile and non-sterile zones. The generator remains in the non-sterile zone, while the handset is used in the sterile zone, and they are connected by a cable. The design of the system has to accommodate that environment.
• Device reprocessing and storage: The device is sterilized (autoclaved) after the procedure, then stored and later brought back into the operating room for use, creating specific workflow and adoption requirements.

Concept discovery

From user needs to requirements

The practice of industrial design is often confused with aesthetics (colour, material, and form). At Cortex, design goes far beyond that. It is the process of capturing a real human need and translating it into a scalable solution, a philosophy that drives each phase of our development lifecycle.

Because of that, user needs must be clearly documented. Within a QMS, this documentation defines what the user needs are and establishes the traceability needed to demonstrate they have been met. 

Our process translates User Needs into specific technical requirements (Design Inputs). These inputs directly drive our engineering decisions and resulting Design Outputs. Each stage of this process is documented to ensure that each design feature can be traced back to a specific requirement and user need.

The mind does a great job of filling in the blanks if only your body can catch up. Physically mocking up a design and playing the journey out from start to finish makes what the body needs so vivid that you feel it, and that’s critical for early success.

Selena Chau, Cortex Industrial Designer

Prototyping & user testing

Prototyping is not just about the physical form. It’s also about the performance of the software and firmware, and how they make the device more intuitive to use. 

Formative prototyping

We use prototyping to physically mock up a design and mimic the full user journey from start to finish. At this stage, the mockups are intentionally low resolution. While guided by best practices, we use formative usability studies to validate our assumptions before finalizing design decisions. The purpose at this point is to uncover key insights that guide more refined prototypes.

Formative prototyping exists to support formative usability studies—the studies through which the design is informed.

Formative usability study 

In formative usability studies, we simulate the intended use environment with a level of fidelity that matches the current design phase. The objective is to gather early, actionable feedback on user interactions, allowing us to identify and mitigate risks without the constraints of a final validation study.

In this particular case, the embedded team’s requirements were to ensure a low cognitive load for both setup and use by surgeons and nurses.

Here are some of the constraints:

• The device must automatically adjust to changes in pressure. The surgeon should not need to adjust power settings manually.
• The device must withstand repeated autoclaving.
• The generator must require minimal interaction from the user. It should display only information relevant to the user and must track the number of handpiece cycles, indicating when the device is near or at end-of-life.

Human-centered design controls takeaways

Engage early with your stakeholders 

• Identify who those stakeholders are. Your stakeholders go beyond the end user. 
• Those involved in the discovery, purchase, and maintenance have their own needs.
• Even if some of those secondary stakeholder needs don’t directly impact safe and effective use, a QMS should capture these business requirements alongside the user needs, ensuring the product is adoptable.

Prototype early to check assumptions

• Prototype early to challenge and correct assumptions quickly.
• Design requires a series of choices to reach an objective. These decisions should remain flexible until validated by the appropriate stakeholders.
• Prototype, test, and modify iteratively before your summative study.
• Ensure Instructions for Use (IFU), Quick Start Guide (QSG), and training material are appropriate for all users.

Operate your design controls to increase adoption

• A great quality management system (QMS) serves the company, not the other way around.
• Structure your QMS so it supports your business goals and product adoption, not just regulatory approval.