The Invisible Work Behind UX in Clinical Setting

This article reflects my personal experience working on a MD digital health solution in the context of a clinical study. All examples are generalized to protect confidentiality.

Introduction

When people think of UX design, they imagine wireframes, interviews, journey maps - maybe even some sleek prototypes. But when you’re a UX designer working in digital health, especially in a clinical study context, the work goes far beyond what’s visible on the screen.

There’s an entire layer of invisible, often exhausting work that has nothing to do with design tools - and everything to do with systems: regulatory processes, clinic politics, approvals, documentation, and recruitment.

Here’s what that looks like in reality.

1. Recruiting Is Not Just for Researchers (usability studies)

In clinical UX work, recruiting users isn’t a quick email blast or a well-targeted ad. It’s a cascade of dependencies:

• You need permissions from hospitals and clinics.

• In some cases you need ethics approval.

• You need clinic staff to help identify eligible patients (who often have limited availability and high vulnerability).

• You might need your materials translated, reviewed, and re-reviewed.

Even when recruitment is not "your job" on paper, it directly affects your design timeline - because if no patients are enrolled, no usability testing happens.

2. Design Iteration Stops at the Gate (clinical studies)

In a typical UX process, iteration is constant - you test, learn, and tweak. But in a clinical study involving a regulated Software as a Medical Device (SaMD), that model breaks.

Once your SaMD is submitted for the clinical trial - and accepted as part of the ethics and regulatory package - it becomes locked in.

That version is your “intervention.” You can’t change it mid-study, except for minor cosmetic tweaks that don’t affect functionality or study outcomes. Anything more? You risk invalidating your study, delaying approvals, or triggering expensive re-submissions to ethics boards and regulatory bodies like Swissmedic.

This puts you in a strange UX position:

• The version you're testing must be polished and stable - not a prototype.

• But development and design still need to continue - so you often work on a separate commercial branch, while the clinical version sits untouched for months.

This is one of the biggest design paradoxes in medtech: you’re asked to design something solid enough to test in the real world, while still needing to evolve the product to prepare for market - all without confusing teams, users, or regulators.

It’s not fast. It’s not iterative. But it’s necessary if you want your work to be part of evidence-based care.

3. Documentation Depends on Your QMS - But It Still Takes Work

One of the most misunderstood parts of UX in medtech is the assumption that everything must follow strict, external formatting rules. In reality, how you document your UX work is defined by your company’s QMS (Quality Management System) - not by Swissmedic or the ethics committee directly.

For our team, this meant we optimized where we could:

• We created clear specifications that aligned with our regulatory needs

• We ensured naming conventions were consistent enough to avoid confusion in long-term audits

• But we didn’t over-engineer our component or flow documentation just for the sake of it

IEC 62366 (the usability engineering standard for medical devices) doesn’t prescribe a specific format - it outlines principles. How deeply you integrate those into your process depends on your company’s maturity, regulatory strategy, and clinical plans.

What is true across the board is that you need a solid maintenance QMS to even start a clinical study with a SaMD. And if Swissmedic shows up for an audit, you must be able to prove traceability between your usability work and the product on trial.

So while naming every button or screen isn’t mandatory, you do need a system. A system that works for your product, your study, and your stage of growth - and that stands up to inspection when it counts.

4. Clinic Integration Isn’t Standardized - And It’s Largely Out of Your Control

One of the hardest realities in implementing a digital health solution facing patient (but recommended by physician) is that even when the product is well-designed, its adoption depends on internal clinical processes you don’t control.

Across clinics, we encountered a wide range of implementation setups:

• Some had a dedicated nurse handling patient onboarding

• Others relied on broader care teams, such as physiotherapists or rehab coordinators

• Cardiologists, while important stakeholders, typically had the least time or involvement in the day-to-day rollout

We created printed QR codes for each site to support patient onboarding - a consistent tactic. But the way patients were actually introduced to the study varied from clinic to clinic, driven by internal policies, staff engagement, and workflow structures. And we had limited influence over that reality.

Usually, a site initiation visit would be our one structured chance to train staff and communicate the value of the study and product. But after that, it required ongoing, proactive support from our side to keep teams engaged - answering questions, troubleshooting misunderstandings, reinforcing protocols.

We did everything we could to support and motivate care teams, and we learned a lot from them in return. But despite those efforts, the fragmented nature of clinical environments - paired with limited startup resources - made sustainable scaling unfeasible in this phase.

In the end, we had to make the hard but necessary decision to scale back to focus solely on completing the clinical study. Because strong evidence is our best path to funding, adoption, and longer-term impact. At least that was a conclusion in this case.

Final Thoughts

Clinical UX isn’t just design - it’s logistics, regulation, negotiation, and deep patience.

If you’re entering this space, prepare to:

• Advocate for research timelines no one else understands

• Design processes, not just screens

• Embrace paperwork as part of your workflow

• Learn that some of your best design decisions will never be seen by users - but will be felt in how the system works

It’s not the glamorous side of UX. But it’s the side that makes innovation in health actually happen.