User-Centered MedTech Software: Building Around Real Workflows

How work is described and how it actually happens are rarely the same.

Processes are mapped. Systems are defined. Workflows are explained in a way that makes everything look structured, consistent, and easy to follow.

But once you observe the work in reality, things tend to look very different.

The more useful place to start is usually less glamorous:

How does the work actually happen?

That question sits at the core of how we build at Flinn.

As we argued in our article Built With Intention, good MedTech software doesn’t begin with technology for its own sake, but with the problem. One of the clearest consequences of that mindset is this:

We meet users where they are.

Sometimes that leads to building into tools people already use, like Microsoft Word.
But that decision doesn’t come first. It is the result of something deeper: understanding real workflows, systems, environments, and constraints before deciding what the right solution should even be.

Because we don’t start with technology.
We start with understanding how people actually work, and then build the most fitting solution around that.

Why user-centered MedTech software is harder to build than it sounds

That idea sounds obvious. Well, in practice, it really isn’t.

Especially in MedTech, workflows are rarely neat. In areas like complaint management, things stop looking tidy the moment you look a little closer. What you find instead is a much broader and more layered environment:

• multiple departments

• many SOPs and internal procedures

• different systems that need to interact

• highly specific ways of handling information

• organizational habits that vary from company to company

Which is where it gets interesting: every organization does it differently.

The real challenge starts with understanding the environment well enough to know what actually needs solving. Get that wrong, and you may not just build the wrong feature, you may be solving the wrong problem.

Reality check: real workflows are always messier than the slide deck

From a distance, workflows often sound far cleaner than they really are:
Managers explain the process, documentation maps the steps, stakeholders walk you through channels and information flows and on paper, it can all look almost suspiciously coherent.

And then you watch the work happen.

Real work is full of interruptions, detours, informal logic, workarounds, and constraints that somehow never make the polished version. Interviews and assumptions are a start, but sooner or later, you have to see how the job actually gets done.

Example 1: Shadowing a service technician

One of the most direct ways we approached this was through full immersion.

“Shadowing” sounds faintly like secret-agent work. In practice, it was much less spy-movie and much more useful: Felix, our Design Lead, spent around one and a half days shadowing a service technician at one of our enterprise MedTech customers, through the actual rhythm of the job.

He saw the work as it unfolded in real time, including:

• going to the technician’s office in Tübingen

• driving with him between client visits

• joining him on-site at hospitals

• observing how devices were serviced and maintained

• sitting with him during the administrative work back at the office

In other words, he stepped into the user’s world instead of asking for the polished recap afterward.

That mattered because the role itself is highly dynamic: it combines field work, technical troubleshooting, and administrative tasks, all of which shape how complaints are reported and processed.

What changed afterward

Before the shadowing, much of the picture came from managers and more senior stakeholders.
Helpful as that was, the workflow looked rather different once it was seen in motion.

Seeing the work firsthand did what firsthand observation tends to do: it complicated the neat version. Some assumptions survived, but others didn’t make it particularly far.

That made the exercise valuable for three reasons:

• it exposed gaps between perceived and actual workflows

• it revealed practical constraints that had not been visible before

• it changed how we understood the problem itself

That’s the point: not just “nice user research,” but work that materially reshaped the solution space.

Example 2: A two-day deep dive into complaint management workflows

Immersion at the individual level is one path. Another is a structured deep dive across teams, systems, and procedures.

In one case, our team spent two days on-site with a large, globally operating MedTech organization in Switzerland to understand complaint management workflows in detail. Think less routine customer meeting, more deliberate effort to understand the environment well enough for actual product decisions to come out of it.

The team itself was intentionally cross-functional:

• product

• engineering

• sales engineering

• commercial

That mix was important.
Why? Because different disciplines notice different problems, ask different questions, and interpret the same environment differently. If the problem space is broad, the lens has to be broad too.

What happened during those two days

Across the visit, the team:

• ran workshops to understand the complaint space in detail

• explored procedures and internal workflows

• mapped systems and information architecture

• discussed integrations between tools

• spoke with people from different departments

• observed how returned devices were processed

Just as importantly, the sessions were not only about documenting the current state, but they also surfaced ideas about what future solutions could look like.

Good discovery is about mapping what already exists and about figuring out what could actually work (ideally before the whole thing slides into product fantasy or feature wish-list mode).

What came out of it

The point of those two days wasn’t simply to gather insights, but to turn them into decisions.

The team aligned on key hypotheses, identified potential solution directions, and selected initial concepts to pursue.

This is another important dimension of meeting users where they are: understanding systems, organizations, and interactions at scale, then bringing the right disciplines together to interpret what you are seeing properly.

Example 3: Building CER workflows with experts, then testing them with real users

A third version of this principle shows up in CER workflows.

Step one was to understand how the work is actually done.
Step two was the part product teams always enjoy a little too much: figuring out how it could be done better. To do that, we worked closely with people who write a high volume of Clinical Evaluation Reports, alongside actual end users.

Experts bring depth: they see structure quickly, understand the internal logic of strong CER work, and can help redesign a workflow without turning the whole exercise into creative writing for process nerds.

There is an important nuance, though: experts are essential, but they are not the whole user base.

They often have highly specialized workflows and very refined ways of working. That makes them invaluable for depth, but not automatically representative of everyone else.

So the process had to combine both kinds of input.

The path looked roughly like this

1. understand how experts currently work

2. analyze how they structure and write CERs

3. redesign the workflow or writing model

4. build an initial version of the solution

5. test it with experts

6. validate and iterate with actual users

The logic is simple: start with the work, shape a better model, then pressure-test it against reality.

What this enables

By combining expert insight with real-user feedback, you get a much fuller picture of:

• how the task is actually performed

• where friction and inefficiencies show up

• what is worth redesigning

• what a better workflow could look like in practice

That’s how you avoid one of the easiest product mistakes to make: confusing a clever concept with a usable one.

Meeting users where they are also shapes the form of the solution

The principle also influences the shape the product takes.

Sometimes the answer is a standalone system. Sometimes it is a full workflow environment. And sometimes the smartest move is simply to stop fighting reality and build into the place where users already spend their time.

That’s the practical side of meeting users where they are: understanding the environment and building in a way that works with it, rather than against it.

If Microsoft Word is where a large share of the work already happens, that should influence the product choice. You can try to lure users into a new environment because it looks cleaner on the roadmap. Or you can build around the place where the work is already getting done.

The second option isn’t always the flashiest. True! But it’s often the better product decision.

A concrete example of this is how we approached CER writing.

Instead of asking users to move into a new system, we built directly into Microsoft Word, the place where these documents are actually created and maintained.

This allows the system to work with the full context of the document, connect extracted data with existing content, and support writing exactly where the work already happens.

The same principle applies to complaint intake.

There is no single “correct” interface. Some users are on the phone, others live in email, others prefer structured input. Instead of forcing one workflow, we support multiple channels, meeting each user in their existing environment.

This is not about being “nice to users”

… but about building better MedTech software.
At the end of the day, that’s the real point, isn’t it?

“Meeting users where they are” can sound soft. In practice, it is demanding: it requires time, closeness, patience, and a willingness to notice when reality refuses to match the neat version of the workflow.

It means:

• getting close to the work itself

• understanding environments before proposing solutions

• noticing the gap between theory and reality

• interpreting what is learned across multiple disciplines

• validating beyond expert opinion alone

• designing around actual constraints, not imaginary ones

In short, it means earning the right to build.

Why building software around real workflows leads to better products

Because once you start from reality instead of assumptions, a lot changes.

You make fewer elegant-but-wrong decisions.
You choose formats more intelligently.
You spot friction earlier.
And you build solutions that fit the work more naturally.

That’s often the more meaningful kind of product quality in MedTech.

Not: Does this look clever in a demo?
But: Does this actually fit the environment people work in every day?

Final thought

The principle underneath all of this?
Understanding Workflows is the foundation building technology.

Because in MedTech, software doesn’t win by looking clever in a demo; it wins by fitting the work well enough to survive the complexity of real life.

And yes, that takes time! But in environments this nuanced, building from a distance is usually the more expensive shortcut.

If this is something your team is currently navigating, feel free to get in touch!