In the health tech domain, the space between “we did research” and “we understood the users” is where products die so often. I have seen so many health tech products and solutions built for existing problems till now.
And yet, a significant number of them shared the same quiet failure: they had done user research, did all the hard work, and still proceeded to build the wrong thing.
Not because they didn’t care or they skipped the interviews. But because their research had no structure holding it together.
And this is certainly not just true when you are creating something new. It is equally true when you are trying to understand an existing problem sufficiently well to solve it, as the same assumptions will kill solutions as surely as solutions that never make it past a whiteboard.
Why User Research Is Non-Negotiable in Health Tech Right Now
Healthcare has always been a really complex domain. But the last few years have added a specific kind of pressure: digital transformation timelines, post-pandemic workflow overhauls, new care delivery models, and a workforce that is stretched, burned out, and deeply skeptical of tools that promise to help but create more work.
In that competitive environment, assumptions are liabilities.
If you are building a clinical decision support tool and you assume that physicians are your primary users, you might miss that it is the hospitalist on a 12-hour shift making real-time decisions who will either trust your tool or ignore it within the first week.
The only way to replace those assumptions with actual signals is through user research.
If done correctly, user research saves you from building something wrong and wasting 18 months before it fails in a pilot. If done wrong, or without structure, it gives you the illusion of understanding without the substance.
You Cannot Just “Jump Into” User Research
In this kind of scenario, the problem is never the research. It is the lack of framework before the research even began. You cannot approach a user interview without knowing who you’re talking to and why you’re asking the questions you’re asking.
Define Who Your Users Actually Are
In health tech, users are almost never a singular entity.
A care coordination tool might be used by nurses, case managers, social workers, and administrators, all within the same health system, all with very different workflows, incentives, and pain points.
A patient tool might be used by patients, caregivers, and family members acting as health proxies.
Before you talk to a single user, you have to think about who all the relevant users are, what they have to do with the problem you are trying to solve, and which ones you most need to understand right now. Not all users are relevant for all research questions. In fact, attempting to research all of them at once produces noise, not insight.
This is the decision that drives everything else.
Frame Your Questions With Intent
Once you know who you are researching, you then need to know what you want to learn about this person and how to ask for it in such a way that the truth actually comes out.
Question framing is the stage where most health tech teams lose the research even before the interview begins.
The most common mistake is to ask users what they want. “What features would you find helpful?” or “What would make your workflow easier?” are questions that are good intentions but completely useless.
Users will tell you what they can imagine, and users can only imagine variations on what they already know. And you will end up getting requests for features that feel safe and familiar, but you won’t get requests for what you really need to know.
Better questions ask for behaviors, not wishful thinking. “Walk me through what you did the last time you tried to A.” “What did you do when you didn’t get from the system what you needed?” “What part of your day do you dread the most, and why?” These are the questions that ask for actual behaviors, not for wishes.
You must ask questions about the context, not just the tasks. Ask about the environment, interruptions, handoffs, and work-arounds. Some of the richest research data comes from observing people in spite of the system, not because of it.
The Synthesis Framework
This is the part where most teams skip or rush through. They do their interviews, have a Notion doc with all their notes and a folder with all their recordings, and then skip to building because the research part felt productive and they’re eager to create something. This is where the actual failure occurs.
Raw data from user research is not insight. It is potential insight. The synthesis process is what turns the data into insight, removing the noise from the signal. And without a framework for synthesis, you will subconsciously handpick the data that supports your assumptions and ignore the data that contradicts them.
And this applies equally whether you are building a product from scratch or working to find a structured solution to an existing clinical or operational problem.
The framework one should follow:
Raw Data → Organize and Prepare
First, start by gathering everything together. That means transcripts, notes, recordings, or any other artifacts users may have provided. Get everything together in one place. Organize those notes so they are readable if you weren’t there.
If you have recordings of your interviews, pull out quotes. The goal here is to have a complete and honest record of everything said and everything observed.
Label Every Data Point
Review your consolidated notes and mark every important observation with a descriptor, a behavior label, an emotion label, a task label, a friction label, or a workaround label. This is where you are forced to really engage with all your data instead of just scanning for high points.
In health tech, you may find some labels recur quickly: time pressure, alert fatigue, documentation burden, trust gap, and workaround. And you need to pay attention to those labels that appear frequently across participants.
Group by Similarity
Now, review your consolidated notes and mark every significant one. Bring your marked data points together by theme.
What observations talk about the same thing? What labels group naturally? This is where affinity mapping enters the scene, both in physical form with sticky notes on the wall and in digital tools like Figjam or Miro.
The groupings should arise naturally from the data; they should never be forced onto it.
Generate Insights
A group is not an insight.
An insight is how you interpret or make sense of what the group means; e.g., “Nurses are frustrated with documentation” is an observation. “Nurses are duplicating documentation across three systems because none of these systems communicate, so any tool that doesn’t integrate will be seen as a fourth burden, not a solution” is an insight.
Insights give you the answer to the question, “so what?”
They link the user behavior to design implications.
POV Statements and Insight Statements
This is the step where the research is turned into a design brief.
A POV statement (point of view statement) links your idea to a particular user and their need.
Think of it this way: [the need] because [insight]. e.g., “A hospitalist with 35 patients needs documentation to happen in the flow of care, not after the fact, because errors are introduced and retention suffers during post-shift documentation.” This statement can inform design decisions for months.
An insight statement is bigger in scope; it is a systemic truth about the problem space, something bigger than the individual user.
Create two to three of each. Share them with your whole team, engineers, clinical advisors, and leaders. These statements are the foundation upon which everyone is building toward a common understanding.
Communicate
Research in a folder doesn’t change anything. The last step in synthesis is communication, which is deliberate and designed with the audience in mind.
Make the communication relevant. Start with the insight statements. Use direct quotes from the users to make the findings come alive. Show the patterns, not just the individual stories.
In Health Tech, Wrong Decisions Costs More Than a Sprint
The organizations that succeed at this, that understand their users before they go out and research them, that craft their questions with real curiosity, and that understand synthesis as hard work, are the organizations that produce products that actually get used.
Not because they’re smarter. But because they stayed in touch with reality longer before committing to a course of action.
So if you’re just about to embark on a research sprint, take a moment before you schedule your first interview and ask yourself whether you know who you’re interviewing or what you’re trying to find out.
If you don’t know either of those things, you probably want to go back and fix them first.
I really would love to know how your teams approach all these challenges. What does your synthesis look like? What’s broken?
