Medical device user needs are statements, in the users’ own terms, of what a device must do for the people who will use it, in the places they will use it. For a diabetes device, they describe what a person with diabetes, a caregiver, or a clinician needs from a sensor, pump, pen, or app. User needs are not design inputs, but they are the source of design inputs, and the finished device is validated against them.
Teams building diabetes devices and software often start with regulations, risk management, and quality planning, and leave user needs until later. That order costs time. This guide explains what user needs are, how they differ from design inputs, how intended use and indications for use fit in, and five questions to answer before you write your first requirement.
User needs vs design inputs
User needs and design inputs describe the same device at different levels. A user need says what the user must be able to do. A design input turns that into a measurable requirement the engineering team can design and test against.
FDA’s Design Control Guidance for Medical Device Manufacturers (March 1997), which FDA still lists as final, shows user needs as the starting point of the design process. They feed into design input, which leads to design output and the finished device. Verification checks that design outputs meet design inputs. Validation checks that the finished device meets user needs. In the guidance’s words, “Design validation shall ensure that devices conform to defined user needs and intended uses.”
Here is how one need flows through that chain for a CGM app:
Stage | Example | How it is checked |
|---|---|---|
User need | A person with diabetes needs to notice a low glucose alert while asleep | Design validation with representative users |
Design input | The app sounds an audible alert of a set volume within a set time of a low reading, even when the phone is on silent | Design verification against the specification |
Design output | Alert logic, sound files, and notification settings in the software | Design review |
Verification | Bench and software tests confirm volume, timing, and override behavior | Test reports |
Validation | Users in a simulated night-time setting wake to and act on the alert | Usability and validation study |
The user need does not mention decibels or notification permissions. That detail belongs in the design input. Keeping the two separate lets you change the design without losing sight of what the user actually needs.
Where user needs fit under the QMSR
FDA’s Quality Management System Regulation (QMSR) took effect on February 2, 2026. It replaced the old Quality System Regulation and now incorporates ISO 13485:2016 by reference (21 CFR 820.7). The former design controls section, 21 CFR 820.30, is now reserved. Design requirements come from ISO 13485 clause 7.3, which covers design and development planning, inputs, outputs, review, verification, validation, transfer, changes, and design files.
The underlying logic has not changed. Design inputs must still reflect the device’s intended use, and design validation must still show that the finished device meets them. Clear, documented user needs remain the most practical way to connect the two. For more on the regulation itself, see our guide to 21 CFR Part 820 and the QMSR.
Well-defined user needs also pay off well beyond compliance:
- Focus. The team builds what users need, not what is interesting to build.
- A shared vision. Engineering, clinical, regulatory, and commercial teams work from the same picture of the user.
- Less feature creep. Every proposed feature has to trace back to a need.
- Easier validation. Concrete needs give you concrete validation criteria.
- A clearer submission. A precise description of what the device does and for whom it is intended supports the regulatory review.
- Market fit. A clear picture of the user helps confirm there is real demand before you build.
Intended use vs indications for use
Two regulatory statements frame every user need: the device’s intended use and its indications for use. They are related but not the same.
FDA’s guidance The 510(k) Program: Evaluating Substantial Equivalence (July 2014) defines them this way:
- Intended use is “the general purpose of the device or its function,” and it “encompasses the indications for use.”
- Indications for use describe “the disease or condition the device will diagnose, treat, prevent, cure or mitigate,” including “a description of the patient population for which the device is intended.”
A 510(k) carries both. The 510(k) summary must include “a statement of the intended use of the device” (21 CFR 807.92(a)(5)), and FDA asks for a separate Indications for Use statement.
Insulet’s Omnipod 5 shows the difference. The Omnipod 5 ACE Pump “is intended for the subcutaneous delivery of insulin, at set and variable rates, for the management of diabetes mellitus in persons requiring insulin.” That is the intended use. The SmartAdjust technology that automates dosing is indicated for type 1 diabetes in people 2 years and older and type 2 diabetes in people 18 and older. Those are indications for use: specific conditions and populations.
Indications for use are deliberately broad. Your user needs should go further and describe the people you are actually designing for.
Five questions to define user needs for a diabetes device
These five questions turn intended use and indications into user needs your team can design against. IEC 62366-1, the usability engineering standard, refers to the combined answer as a use specification.
1. What will the device be used for?
Start with the intended use: what the device does and the decision or action it supports. A CGM may provide glucose readings that people use to make treatment decisions. An app may combine CGM, pump, and activity data to help users understand patterns.
Intended use tells you what the device is for, but not who uses it or what they need. It is the frame, not the picture. If your device includes software, decide early whether each function is a regulated device function. Our guide to FDA regulation of mobile medical apps explains where FDA draws the lines.
2. Who will use the device?
Indications for use name the patient population. User needs must describe every user, and a diabetes device usually has several:
- People with diabetes, from children to older adults, with type 1, type 2, or other forms of diabetes
- Caregivers, such as parents of young children or family members of older adults
- Clinicians, such as endocrinologists, diabetes educators, and nurses, who set up devices and review data
For each group, describe the characteristics that change how they interact with the device:
- Age range and life stage
- Vision, hearing, and dexterity, which diabetes complications such as retinopathy and neuropathy can affect
- Health literacy, numeracy, and experience with technology
- Language and cultural context
- Other health conditions and medications
- Insurance coverage and ability to pay, which shape what devices people can access
Then translate each characteristic into a need. “Users may have reduced fine motor control” becomes “Users need to change a sensor or pod with limited hand strength and precision.” This translation is the most important step in the whole process.
3. Where will the device be used?
A device used in a hospital has different needs than one worn every day at home, at school, at work, and at the gym. Ask:
- Will it be used at home, in a clinic, in a hospital, or all three?
- Will users wear it through sleep, showers, swimming, exercise, and travel?
- Is it disposable, reusable, or long-lasting?
- Will it be used in bright sunlight, in the dark, or in noisy places?
The answers drive requirements for durability, water resistance, size, discretion, alarm volume, and screen readability. For devices that span settings, see our guide to remote patient monitoring for diabetes.
4. How will users interact with it?
Decide how users will control the device and see its data: a smartphone app, a dedicated receiver, the device itself, or a combination. Consider connectivity, such as Bluetooth or Wi-Fi, and how much users can customize.
The interface deserves as much attention as the hardware. FDA’s human factors page puts it plainly: “The critical element in these interactions is the device user interface.” FDA updated its guidance, Applying Human Factors and Usability Engineering to Medical Devices, in August 2026. See our guide to IEC 62366 usability engineering for how to build this into development.
5. What does it need to connect to?
Diabetes devices rarely work alone. Pumps and CGMs now routinely communicate, apps pull in data from fitness trackers and other wearables, and clinicians expect data in their own systems. Users are more likely to choose a device that works with the devices and apps they already rely on.
List every connection users will expect, including ones that are not obvious at first. Then decide how you will build them, whether through software development kits, a modular component architecture, or both. Our guide to diabetes device interoperability covers the relevant standards and FDA requirements.
How to write user needs you can validate
A good user need is specific enough to validate but free of design decisions. Use these rules:
- Name the user. “A parent of a child with type 1 diabetes” beats “the user.”
- Describe the need, not the solution. Say what the user must achieve, not which button or screen achieves it.
- Include the context. Note when, where, and under what conditions the need applies.
- Make it testable in validation. You should be able to watch a representative user and tell whether the need was met.
- Trace it. Assign an ID to each need and link it to design inputs, risks, and validation activities.
Weak user need | Stronger user need |
|---|---|
The app should be easy to use | A person newly diagnosed with type 2 diabetes needs to see their current glucose level and trend within a few seconds of opening the app |
The pump needs a good alarm | A person with diabetes needs to notice an occlusion alarm while asleep, at work, or exercising |
Caregivers should get data | A parent needs to see their child’s glucose readings and alerts remotely while the child is at school |
The sensor should be durable | A person with diabetes needs the sensor to stay attached and working through daily showers, exercise, and sleep for its full wear period |
User needs also feed risk management. Each place where a user could misunderstand, miss, or misuse something is a potential hazard to be analyzed under ISO 14971.
What happens when real-world use is missed
Several recent Class I recalls, FDA’s most serious category, involved how diabetes devices behave in everyday use:
Device | Recall start | What went wrong |
|---|---|---|
May 2025 | Defective foam or an assembly error could stop the receiver speaker from working, so users could miss audible glucose alerts | |
March 2024 | An app crash caused excessive Bluetooth communication that drained the t:slim X2 pump battery; 224 injuries were reported as of April 15, 2024 | |
November 2019 | A loose reservoir that could no longer be locked into the pump could cause over- or under-delivery of insulin |
Recalls have many causes, and these were not necessarily failures of user needs analysis. But each one involves a situation users meet every day: sleeping through an alert, using a phone app alongside a pump, or handling a reservoir over months of wear. Those situations are exactly what a thorough user needs analysis brings to light early on, when designing for them costs the least.
Frequently asked questions
What are user needs for a medical device?
User needs are statements, in the users’ own terms, of what a device must do for the people who will use it, in their real environments. They come before design inputs and form the basis for design validation, which confirms the finished device meets them.
What is the difference between user needs and design inputs?
A user need describes what a user must be able to do, such as noticing a low-glucose alert while asleep. A design input turns that need into a measurable engineering requirement, such as alert volume and timing. Verification tests design inputs; validation tests user needs.
What is the difference between intended use and indications for use?
Intended use is the general purpose or function of the device. Indications for use describe the disease or condition the device addresses and the patient population it is for. The FDA treats “intended use” as the broader term that encompasses indications for use.
Does FDA require user needs?
Under the QMSR, effective February 2, 2026, the FDA requires that design and development follow ISO 13485 clause 7.3, including design inputs and design validation. FDA’s design control guidance identifies user needs as the starting point for the process, so documented user needs are the standard way to meet this requirement.
How do user needs relate to usability engineering?
Users need to describe who the users are, where they use the device, and what they must achieve. Usability engineering under IEC 62366-1 builds on that picture to design the user interface and test whether representative users can use the device safely.
Define user needs with Sequenex
Strong user needs make every later step easier, from requirements and risk analysis to validation and submission. They are worth getting right before the first line of code.
Sequenex has decades of experience in the diabetes and connected device industry and helps teams turn user research into traceable requirements for devices and software. See our biosensor and CGM software development services, or contact us to discuss your project.
