Let’s be real: writing user needs for a medical device sounds straightforward. You just list what the user needs, right? But anyone who’s been in the thick of product development knows this step can be deceptively tricky. It’s one of those foundational activities that can quietly make or break your entire design process.
So how do you write user needs that are clear, actionable, and testable without getting bogged down in vague generalities or rigid tech specs? Let’s walk through it.
What Are User Needs, Really?
Think of user needs as your product’s compass. They’re not about how your device works; they’re about what your user needs it to do to be successful, safe, and effective. These aren’t requirements or engineering specs. They’re rooted in real-world use.
Let’s break that down:
- “The device must be easy to operate with one hand.”
- “The user must receive feedback when the device is successfully activated.”
- “The device must be comfortable to use for extended periods.”
These statements might sound simple, but they anchor your entire design process. If you get them wrong, or skip them altogether, you risk developing a product that works on paper but frustrates users in practice.
ISO 13485 also states that design inputs should be based on user needs, so getting this part right isn’t just helpful, it’s expected. The FDA reinforces this in 21 CFR 820.30, which outlines design control requirements for medical devices marketed in the U.S.
That’s because regulatory bodies want to see that your design is grounded in real-world use, not just technical feasibility. It’s not about ticking a box. It’s about building devices that are safe, effective, and truly usable.
The Big Mistake: Confusing Needs with Features
This one trips up even experienced teams. You’re trying to be helpful, so you start describing how the problem will be solved instead of what the user needs.
Here’s a common mistake:
❌ “The device shall have a 4.5” LCD touchscreen with five menu options.” That’s a design input. You’ve already decided on a solution.
Instead, you want to focus on what the user is trying to accomplish:
✅ “The user must be able to easily access and navigate available functions.”
This approach keeps your team’s options open. It gives engineers and designers room to innovate, while still keeping the user experience front and center.
Pro Tip: If your user need contains a solution (like a specific size, material, or interface), it’s probably not a user need. Take a step back and ask, “What is the user really trying to achieve here?”
Where Do User Needs Come From? (And What To Do with Them)
Let’s talk sourcing. You’re not just making these up in a vacuum; they need to be grounded in the actual experience of your target users. Here’s where to look and how to use the insights:
1. Interviews and Stakeholder Conversations
Talk to clinicians, nurses, patients—whoever your end users are. Ask open-ended questions:
- What’s the most frustrating part of using [similar product] today?
- What do you wish this device could do differently?
- Walk me through a typical use; what gets in your way?
Then, listen carefully. Don’t just jot down answers, translate pain points into experience-driven needs. If someone says, “I always forget to reset the device after each use,” a need might be: “The user must receive a prompt to reset the device between uses.”
2. Contextual Inquiry (a.k.a. Shadowing)
Watching a user in their actual work environment reveals what interviews alone often miss. Observe what they struggle with, where they hesitate, what shortcuts they take. Note down interactions that cause delays, confusion, or unnecessary steps. Each friction point is a potential user need.
It’s important that you don’t rely solely on what people say, since they often adapt to inefficient systems without realizing it. You’re looking for gaps between what they say they need and what they actually do.
3. Usability Studies (Past and Present)
Whether it’s an early prototype or a competitor’s device, usability feedback is gold. Analyze where users fail, where they make mistakes, and where things aren’t intuitive. Use those insights to refine or write new user needs.
4. Complaints, Field Reports, and Post-Market Surveillance
Every complaint is a lesson waiting to be learned. If users consistently report pain points, confusion, or injuries, look for the unmet need behind the event. Regulatory bodies love to see a product development process that actively responds to post-market data.
In fact, FDA regulations for post-market surveillance outline specific requirements for certain Class II and III devices to monitor long-term safety and performance in the field.
5. Literature, Standards, and Industry Guidance
Make It Testable (Without Turning It Into a Requirement)
Here’s where user needs often fall apart…they’re so vague, no one knows how to validate them.
Your job isn’t to write the test case yet, but your need should be specific enough that a validation method could be created.
Let’s look at an example:
❌ “The device must be easy to use.” (Nice idea. But…what does “easy” mean?)
✅ “The user must be able to complete setup within 3 minutes without assistance.”
That’s clear. It’s measurable. And it can guide everything from interface design to packaging instructions.
Pro Tip: If you’re stuck, ask: “How would we prove this in validation?” If it’s not obvious, your user need may need tightening.
How Many Users Do You Need?
There’s no magic number, but here’s a good gut-check:
If your user needs don’t touch every major interaction your user will have with the product—before, during, and after use—you’re probably missing something.
Think holistically about the full user journey—before, during, and after use:
- Unboxing and setup
- Use during normal conditions
- Use during stress or emergency
- Cleaning and maintenance
- Disposal or reuse
Your goal is to map the full user journey. And if that journey includes emotion—fear, confusion, urgency—your user needs should reflect that, too.
User Needs Should Be Your North Star
You know what? It’s easy to treat user needs like a formality. Something you write down early, link in a traceability matrix, and then forget about.
But the best teams keep them front and center throughout development. They revisit and refine them as they learn more, often during formal design reviews. These aren’t just regulatory checkpoints; they’re opportunities to make sure your user needs still reflect what you’re learning through testing, feedback, and development.
Because here’s the thing: your user needs aren’t just the starting line, they’re your north star. And in a field where human lives are at stake, that compass better be pointing true.
So slow down. Ask good questions. Stay curious. And always, always write with the end user in mind.
Keep Your User Needs Connected, From Start to Submission
Even when you get your user needs right, the next challenge is keeping them connected to your design inputs, verification protocols, and risk documentation.
A traceability matrix gives you a simple way to map those connections and spot any gaps before they become problems. And traceability isn’t just a regulatory expectation; it’s your blueprint for building safer, more effective devices.
That’s where QuickVault by Veeva comes in. Our all-in-one MedTech platform gives your team a single, centralized space to capture user needs, link them to downstream requirements, and ensure traceability is maintained through every phase of development. No spreadsheets, no silos—just a streamlined path from customer voice to validation.
Whether you’re just starting your user needs or managing updates during design iterations, QuickVault helps ensure your processes stay compliant, collaborative, and built for scale.
Want to see QuickVault in action? Book your personalized demo now →
