MENU
Designing for complex medical technology
CLIENT
Nexstim
BRIEF
Medical technology presents a different kind of design challenge. The goal is not simply to make an interface easier or more pleasant to use. Design decisions need to support clinical workflows, reduce ambiguity, work within technical and regulatory constraints, and remain consistent across a complex system.
In my current role, I work on UX for navigated brain stimulation software used by trained clinical professionals. My work ranges from interaction design and prototyping to design systems, requirements, usability and collaboration with software, clinical and regulatory specialists.
Understanding complexity
Most of my daily work naturally focuses on the software interface. Visiting a clinic to observe treatments is a valuable reminder that the interface is only one part of the user experience.
In clinical use, the software, physical device, patient, clinician and treatment environment form a single system. Observing the device in its actual context helps bringing these relationships back into focus and reinforced the importance of seeing how design decisions work beyond the screen.
Understanding complexity means understanding the context around the interface, not just the interface itself.
Another part of understanding complexity is recognising the impact of change beyond the interface. In a regulated product, even a seemingly small UI change can create work across requirements, documentation and testing.
This does not mean avoiding change, but it does mean making it deliberately. Before changing an existing interaction, it is important to understand what problem the change solves and whether its value justifies the wider impact.
Designing for clarity and safety
In medical software, clarity is closely connected to safety. An interaction should communicate not only what the user can do, but also what is happening in the system and what the consequences of an action may be. This affects many seemingly small design decisions: how system states are communicated, when warnings are necessary, how errors are presented, and when an action should require deliberate confirmation.
One example involved an editable system-level setting. Although the interaction itself was simple, changing the value could affect other users and future use of the device. The design therefore needed to make the consequence visible at the right moment, while still allowing the user to cancel the action and return to the previous value.
Not all friction is bad friction.
In consumer products, reducing clicks and interruptions is often treated as an improvement. In safety-critical systems, an additional step can be valuable when it helps prevent an unintended action or gives the user an opportunity to reconsider its consequences.
Building consistency into the system
In a complex product, usability is not only shaped by individual screens. Users build expectations from patterns they encounter throughout the system. Similar elements should look, behave and communicate their state in consistent ways. This makes the interface more predictable and reduces the amount of information users need to relearn.
Part of my work has therefore focused on identifying recurring UI patterns and turning them into reusable, documented components. Over time, even simple elements can accumulate slightly different implementations. The challenge is to understand which differences are meaningful and which are simply historical variation.
A good example is the text field component. Several variations had developed for different contexts, even though much of their structure and behaviour was shared. I consolidated these into a common foundation with clearly defined states, behaviour and optional elements.
Instead of creating separate components for individual use cases, I separated reusable primitives from the patterns built with them. This makes the system easier to maintain while still allowing components to adapt to different workflows. It also forces the design to account for behaviour, not just appearance. For example, a field that may display an error needs to accommodate that state without unexpectedly changing the surrounding layout.
I am now applying the same approach to more complex components, such as tables, where content, column widths and configurations may vary considerably while many of the underlying interaction patterns remain the same.
Consistency is a tool, not the goal
Reusing existing components is valuable when the interaction and user need are genuinely the same. But consistency should not become a constraint that forces a new use case into an unsuitable pattern.
Before reusing a component, I consider what the user is actually trying to accomplish, what information they need and how the interaction should behave. Sometimes the right solution is to reuse an existing component. Sometimes it is to extend it, create a new pattern, or deliberately make something different.
A design system should support good design decisions, not replace them. Consistency reduces unnecessary cognitive load, but it should never override the user's task.
Working across disciplines
Designing medical technology is highly collaborative. A seemingly small interaction can involve clinical needs, software architecture, existing requirements, regulatory considerations and established behaviour elsewhere in the product.
My role is often to work between these perspectives: understanding what the user needs to accomplish, translating that into an interaction, and making sure the solution can work within the larger system.
Requirements are an important input to design, but they are not the design itself. Part of the work is understanding why a requirement exists, what problem it is intended to solve and whether the proposed behaviour actually supports the user.
This often means asking questions before designing solutions:
-
What is the user trying to accomplish?
-
What does the user need to know at this moment?
-
Why does the current system behave this way?
-
Is this behaviour required, or simply inherited?
-
What happens elsewhere in the workflow?
-
What are the consequences if the user misunderstands this?
Answering these questions requires close collaboration with software developers, clinical specialists, product management, requirements and regulatory experts, testers and other designers. Each sees a different part of the system.
The goal is not for UX to win an argument. It is to make the different constraints and perspectives visible enough that the team can make a better design decision. Prototypes are particularly valuable in this environment because they make abstract discussions concrete. Instead of discussing a requirement only in words, we can look at an interaction, walk through the workflow and identify assumptions or problems before implementation.
Complex products are rarely improved from a single point of view. My role is to make the user's perspective tangible while bringing different perspectives together around a solution that works within the system as a whole.
Designing beyond the interface
The impact of a design decision does not end at the interface. In a complex medical product, the same decision can affect implementation, testing, requirements and documentation.
This has made me increasingly conscious of designing not only for the person using the product, but also for the people who build, verify, document and maintain it.
Reusable components are one example. A well-designed component can reduce repetitive implementation work for developers, provide clearer expected behaviour for testing, and make UI documentation more systematic. When components, states and behaviours are defined consistently, they create a shared reference across disciplines.
This also works in the other direction. A seemingly small UI change can create significant work elsewhere in the development process. Understanding these dependencies helps me evaluate changes more deliberately: what problem are we solving, what does the change improve for the user, and what are its wider consequences?
The goal is not to minimise change or optimise each discipline separately. It is to design solutions that improve the product without creating unnecessary complexity around it.
I’m currently focused on my work in medical technology and the Design system work I’m doing there. I’m not actively looking for a new role, but I’m always interested in meeting people working on complex products, usability and design systems, and open to hearing about interesting learning opportunities for the future.