How to Do User Needs Research for a Medical Device

The five-step process: interview the people who will actually touch the device, observe them working in the real environment, turn what you heard and saw into discrete needs statements, prioritize those statements against risk and feasibility, and document a traceable line from each need through to a verification test. Run all five before you lock a design and you get a product informed by reality and a defensible design controls record.

Quick Answer: Interview the intended users → observe their real workflow → write discrete needs statements → prioritize by risk and feasibility → trace each need to a verification method. Skip the interviews and you build the wrong device. Skip the traceability and even the right device becomes hard to defend to a reviewer or an auditor later.

Prerequisites: What to Nail Down Before You Start

You need three things settled before the first interview, or the research you collect won't hold up: who the intended users actually are, where the device will actually be used, and how this work feeds your design controls process.

Intended users is not one bucket. A device that looks like it has a single "user" usually has three or four: the clinician who operates it, the patient who wears or receives it, the technician who cleans and maintains it, and sometimes a caregiver who manages it at home. Each group has different goals and different failure modes if the device gets it wrong. Write down every distinct population before you schedule a single conversation — you cannot fix a missing one after the interview round is done.

Use environments shape the device as much as the users do. An infusion pump used in a well-lit ICU with a trained nurse nearby is a different design problem than the same pump used by a patient at home, half-awake, with no biomedical engineer on call. List every environment where the device will realistically be used, including the ones that feel like edge cases — those are frequently where the real risk lives.

Design controls context is what separates medical device user needs research from ordinary product discovery. In a regulated development process, user needs sit at the top of a chain that runs from need to design input, to design output, to verification, to validation. Notes that can't be traced forward through that chain get redone later, usually right before a submission deadline. If you haven't run structured discovery conversations before, The Complete Guide to Customer Research for Pre-Product Founders covers the interviewing discipline underneath this work — medtech just adds a paper trail on top of it. And if you're still working out where this fits inside the larger validation sequence for a device concept, How to Validate a Medical Device Startup Idea lays out how it sits alongside regulatory strategy and reimbursement questions.

Step 1: Interview the People Who Will Actually Use the Device

Talk to every user population you identified in the prerequisites step, separately, before you show anyone a concept or prototype. The goal is to understand their current workflow and frustrations in their own words — not to validate an idea you already have.

Structure each interview around what people actually do, not what they say they'd want. Ask about the last time they performed the task your device will touch: what happened, what went wrong, what workaround they used. Concrete, past-tense questions produce far more usable data than hypothetical ones. This is the central lesson of Rob Fitzpatrick's The Mom Test: people are polite, and they will tell you your idea sounds great if you ask them to react to it. They are far more honest when you ask them to describe what already happened to them.

A few habits pay off repeatedly. Record every interview with permission — you will misremember specifics under deadline pressure later. Capture verbatim quotes, not paraphrases; a needs statement built on your summary is weaker evidence than one built on what someone actually said. Interview across the full range of intended users, including the ones hardest to schedule — a home caregiver's constraints often differ the most from a clinician's, and that population is also the one most founders skip because it's inconvenient to reach.

Step 2: Observe the Workflow Where It Actually Happens

Interviews tell you what people believe about their own behavior. Observation tells you what they actually do, and the gap between the two is frequently where the real design opportunity sits. People routinely describe a clean, linear version of a task that, in practice, involves an improvised workaround or a skipped step.

Watch the task happen in its real setting whenever you can get access — a clinic, an OR, a patient's home, a nursing station at 2 a.m. if that's when the task actually happens. Note the interruptions, the reach distances, the lighting, and every workaround you see. Each one is a candidate needs statement. For a full field method — how to get access, what to document, and how to turn a shift of observation into usable notes — see How to Shadow a Clinical Workflow as a Founder.

Pair every observation with a short follow-up question, in the moment or immediately after: "I noticed you did X instead of Y — walk me through why." That single question frequently surfaces the real constraint behind a workaround, which is usually more valuable than the workaround itself.

Step 3: Turn Raw Notes Into Discrete Needs Statements

Interview transcripts and observation notes are not needs statements yet — they're raw material. A needs statement is a single, specific sentence describing what the user requires, written in terms of the user's outcome rather than a particular design solution.

The discipline is separating what the user needs from how you might solve it. "The device should have a bigger screen" is a solution smuggled into a needs statement. "The user shall be able to read the primary display value from a normal working distance under the lighting conditions where the device is used" is a need — it leaves room for a bigger screen, better contrast, or an audible readout, and lets your design team choose the solution later with full information.

Write one needs statement per distinct requirement. Resist bundling several observations into one compound sentence — a compound needs statement is nearly impossible to trace cleanly to a single design input later. Marty Cagan's Inspired makes a related point about discovery work generally: it's only useful once it's broken down into concrete, testable pieces small enough for a team to act on, not left as a pile of impressions.

Step 4: Prioritize Needs Against Risk and Feasibility

You will end this process with more needs statements than you can address in a first design cycle. Two dimensions decide what gets built now versus later: how much risk to the user or patient the need addresses, and how feasible it is given your team's current technical and regulatory constraints.

A simple way to sort a long list without pretending to more precision than you have:

• High risk, high feasibility — build first; both necessary and achievable now.
• High risk, low feasibility — flag for early technical or regulatory investigation; don't let them quietly slip off the roadmap because they're hard.
• Low risk, high feasibility — nice-to-have polish; sequence after the risk-driven work.
• Low risk, low feasibility — document and park; revisit only if the constraint changes.

Involve clinical, engineering, and regulatory perspectives in this prioritization together, not sequentially. A need that looks purely clinical often has a feasibility constraint nobody flags until engineering sees it, and one that looks purely technical often has a risk implication nobody flags until someone with clinical judgment sees it.

Step 5: Document Traceability From Need to Verification

This is the step that distinguishes user needs research done for a regulated device from research done for a general consumer product, and it's the step teams most often shortchange because it produces no visible design progress on its own.

Every needs statement needs a unique identifier, a documented source (which interview, which observation session, which date), and a forward link to at least one design input it informs. As the design matures, that same chain extends forward again — design input to design output to a verification method that can produce a pass/fail result. If a needs statement can't eventually be traced to something testable, that's usually a sign it was written too vaguely in Step 3, and it's worth sharpening it rather than pushing it further down the chain as-is.

Keep this record live throughout development, not as a retroactive exercise before a submission. Reconstructing which interview produced which need, six months later, from memory and scattered notes, is slow, error-prone, and exactly the kind of gap a reviewer or an internal audit tends to find.

Discovery Notes vs. Design-Controls-Ready Needs Statements

The table below shows one observation at two stages of the process — a raw note right after an interview, and the design-controls-ready version of the same need after Steps 3 and 5 have been applied.

The takeaway: a discovery note is where the insight starts, not where it ends. Every note that matters needs the rewrite step before it can do any work in your design controls record — treating a notebook entry as if it's already a needs statement is where most traceability gaps originate.

Common Mistakes: Leading Questions and Untraceable Needs

Two mistakes account for most of the rework teams end up doing on user needs research, and both are avoidable with discipline you can build into the process from day one.

Leading questions contaminate the research at the source. Asking "wouldn't it be easier if the device did X?" invites agreement rather than honest reaction, and every answer collected that way is weaker evidence than it looks. The fix is the one The Mom Test argues for broadly: ask about specific past behavior instead of hypothetical reactions, and treat any answer to a question about your own idea with skepticism until it's backed by something the person actually did.

Untraceable needs are the second recurring failure, and they surface later — usually during design review or an audit, well after the interviews are finished. A needs statement with no linked source interview, no unique ID, and no forward link to a design input is functionally invisible to your design controls process even if it's sitting in a document somewhere. The habit that prevents this is small and mechanical: assign an ID and a source citation the same day you write the statement, not in a batch cleanup pass before a submission, where details get lost or quietly dropped.

Key Takeaways

• Interview every user population separately — clinician, patient, technician, and caregiver needs rarely overlap as much as they look like they should on paper.
• Observation catches what interviews miss — the gap between what people say and what they do is frequently where the real design opportunity lives.
• Write needs statements as outcomes, not solutions — specifying a design choice too early takes options away from your team.
• Prioritize by risk and feasibility together, with clinical, engineering, and regulatory perspectives in the same room, not in sequence.
• Assign traceability on day one, not as a cleanup pass before a submission — untraceable needs are the most common gap in a design controls file.
• A raw discovery note and a needs statement are not the same artifact — every note that matters needs a deliberate rewrite step first.

Frequently Asked Questions

What's the difference between a user need and a design input?

A user need describes a desired outcome from the user's perspective, without specifying a solution. A design input translates that need into an engineering-specific, verifiable requirement your team can build against. User needs come first and inform design inputs, not the reverse.

How many people do you need to interview for medical device user needs research?

There's no fixed number — it depends on how many distinct user populations and use environments you identified in the prerequisites step. A practical signal is diminishing returns: once several consecutive interviews within one population stop surfacing new needs, you've likely covered its core requirements.

Can you start user needs research before you have a working prototype?

Yes, and you generally should. This research is meant to inform the design, not confirm one you've already built. Interviewing and observing before a prototype exists keeps you focused on the user's actual workflow instead of narrowing the conversation to reactions on a design you're already attached to.

Who should own user needs research inside a founding team?

No single function should own it alone. Clinical or user-facing team members typically lead the interviews and observation, but engineering and regulatory perspectives need to be involved early enough to catch feasibility and traceability issues before they get expensive to fix — waiting for a design review defeats the purpose of running this research up front.