Lucy Baldwin, head of research and strategy, and Oliver North, head of engineering at Ensera Design, reflect on the key design considerations in medical device development.
Medical device development is becoming increasingly interconnected. A physical product may now form just one part of a wider ecosystem encompassing software, connectivity, cybersecurity, and more. As these ecosystems expand, development teams must also manage the growing interdependencies between user needs, human factors, clinical workflows, manufacturability, and regulatory requirements.
Go deeper with GlobalData
Access deeper industry intelligence
Experience unmatched clarity with a single platform that combines unique data, AI, and human expertise.
As the number of disciplines involved grows, so do the dependencies between them. A decision by one team can have significant consequences elsewhere in the programme, especially when specialist functions or external organisations work on different elements of the same ecosystem.
Against this backdrop, there can be a natural tendency to equate progress with moving quickly toward a solution. However, one of the most valuable things a development team can do at the outset is resist that instinct.
Before asking what a product should look like or how it should be engineered, teams need clarity about the problem they are trying to solve, who experiences it, the context in which it occurs and what a successful outcome would actually mean. Establishing that clarity is integral to medical device development.
Are you solving the right problem?
One challenge in medical device development is that a project can begin with a proposed solution rather than a clearly articulated problem. A brief might ask for an existing device to be made smaller, for connectivity to be added or for a particular technology to be incorporated. These can all be legitimate objectives, but they can also embed assumptions about what users need and where value will come from.
Technology trends can reinforce this tendency. Several years ago, organisations might have started with the ambition to make a device Bluetooth-enabled. Today, similar conversations can begin with a desire to incorporate artificial intelligence (AI). In either case, the technology needs to be considered in the context of a clearly defined user need, intended application and problem it is expected to solve.
Engineering teams can be particularly susceptible to moving quickly into solution mode. Presented with a technical challenge, the instinct may be to change a mechanism, geometry or material. However, solving the immediate engineering problem without understanding its wider context can introduce problems elsewhere or unnecessarily commit a program to a costly development direction.
The first task should be to interrogate the brief and understand what is driving the request, which users and stakeholders are affected, what assumptions have already been made, and which constraints genuinely need to shape the solution. Sometimes that process confirms that the original direction is appropriate. Other times, it reveals that the real challenge differs from what was initially presented.
Building an evidence-based picture of the challenge
Developing clarity requires teams to understand the environment surrounding the product rather than considering the device in isolation. This means gathering evidence from multiple perspectives before narrowing the range of potential solutions. Depending on the product and development stage, this can involve:
Observing users in context
Research into clinical workflows or user experiences can reveal how products are used and where unmet needs or practical challenges arise.
Looking beyond clinicians and users
Sales teams can provide insight into recurring customer concerns, while manufacturing, validation and other downstream specialists can identify constraints that may not be apparent to the core development team.
Making ideas tangible early
Simple stimulus models, space models or physical mock-ups allow teams to test assumptions and gather evidence before committing significant resources to a development direction.
Sharing insights across disciplines
Involving designers and engineers in research, or communicating findings through visual materials and collaborative workshops, helps ensure that user insights directly inform technical decisions.
The objective is to build a shared, evidence-based understanding of the challenge so that assumptions can be tested before substantial resources are committed to solving it.
Creating alignment without creating paralysis
Greater understanding does not automatically produce agreement, and different stakeholders will inevitably view the product through different lenses and define success accordingly.
Users may prioritise comfort, discretion and ease of use, while clinicians may focus on integration into established workflows.
Meanwhile, manufacturing teams need consistency, scalability and reliable production, engineers must consider technical feasibility and performance, and
commercial teams need to account for market requirements and the business case.
Early alignment makes these competing priorities visible while there is still flexibility to respond. Clear, preferably measurable success criteria provide a common reference point and allow teams to address trade-offs before incompatible requirements become embedded in the programme.
Multidisciplinary development should not, however, become committee-style decision-making. Projects require a defined core team that can synthesise different perspectives, establish direction and make necessary compromises. Clarity depends on both broad consultation and clear decision ownership.
Reframing requirements can change the development pathway
The value of questioning the initial brief becomes particularly apparent when a seemingly straightforward technical requirement is examined in context.
Consider a development programme focused on miniaturising an electromechanical device. The initial assumption might be that making the product progressively smaller will improve wearability and encourage adoption. However, further miniaturisation can demand considerable engineering time and resources.
Through iterative prototyping and user research, a team may discover that size is only a barrier up to a certain point. Once the device is sufficiently compact, how easily it fits into the user’s workflow can matter more than further size reductions.
The development challenge can shift from making the product as small as possible to making it work effectively within the intended workflow. That creates a clearer basis for balancing dimensions, usability, technical complexity and development effort.
This distinction is important for organizations with finite R&D budgets. Reframing the requirement can prevent resources from being spent optimising an attribute beyond the point at which it delivers meaningful user value and instead direct investment toward the characteristics most likely to determine success in practice.
Clarity early can reduce complexity later
The benefits of a well-defined problem extend throughout development. Medical devices need to demonstrate that defined requirements have been met. If those requirements are ambiguous, poorly constructed or based on unchallenged assumptions, verification can become significantly more difficult. Testing may require dedicated test rigs, multiple prototypes, inspections or structured experiments. Across hundreds of requirements, small ambiguities can create substantial downstream work.
The impact grows as development progresses. A commonly used principle in product development is the “10x rule”: the cost of correcting a design flaw can increase by an order of magnitude at each successive stage. An issue that can be addressed relatively quickly and inexpensively during concept development may require substantially more time and investment once a design reaches verification and validation. If the same problem is identified after manufacturing infrastructure and processes are established, the consequences can be even greater.
Clear user needs and requirements therefore provide a framework for navigating development. Teams can evaluate concepts against agreed objectives, make deliberate trade-offs and determine what evidence is needed to show the device performs as intended. Early user research serves a similar risk-reduction function by identifying potential mismatches between a proposed solution and real-world needs while changes are still comparatively easy to make.
Medical device development will always involve uncertainty. Establishing clarity early does not eliminate it, but it helps teams identify consequential assumptions while they still have the time and flexibility to act on what they learn.
Maintaining the “red thread”
Establishing clarity at the beginning is only valuable if it survives throughout development. The term “red thread” refers to a clear, continuous line of logic that can be easily traced through a complex process, from the original user needs and problem definition through requirements, design decisions, engineering and validation.
There can be a temptation to treat research, design, engineering, human factors and manufacturing as sequential activities, with requirements and solutions handed from one function to the next. Complex medical device development rarely works effectively through one-way handoffs. Instead, a continuous “red thread” should connect early user and stakeholder insights with later decisions. Engineers and designers should contribute while the problem is being framed, and emerging technical solutions should be repeatedly checked against the user needs and contextual requirements that informed the brief.
Prototyping supports this iterative process by creating opportunities to test assumptions throughout development. Human factors specialists can assess whether emerging solutions deliver the intended interactions. Manufacturing expertise can identify designs that may create avoidable production difficulties. Research can revisit assumptions when evidence suggests that the team’s original understanding needs refinement.
The result is not necessarily linear. Iteration is inevitable. The difference is that iteration becomes purposeful: teams learn against a clear definition of what the product needs to achieve, rather than repeatedly changing direction because they didn’t fully understand the original problem.
Clarity creates the conditions for progress
Speed remains important in medical device manufacturing, but beginning engineering sooner does not necessarily mean reaching a successful outcome sooner. When teams move toward solutions before agreeing on the problem, they risk optimising the wrong attributes, overlooking important stakeholders and embedding assumptions that become more expensive to correct.
Creating clarity at the outset means establishing whose problem is being solved, understanding the context in which the solution must work, identifying genuine technical and manufacturing constraints, aligning stakeholders around meaningful success criteria and making conscious trade-off decisions. That foundation gives multidisciplinary teams a common purpose to test subsequent decisions against.
At any stage of medical device development, bringing together user and technical perspectives can help organisations reassess the challenge, focus effort where it will create the greatest value and identify a clearer path forward.
Taking the time to define the right problem may sometimes feel slower than immediately pursuing a solution. In practice, it can give a programme the clarity and momentum to move forward with confidence.
