User Needs to Drive Product Requirements
An ‘Insights’ interview with Carolyn Rose, director of research and strategy
The importance of understanding user needs has been widely acknowledged by OEMs, consultants, and regulators alike to be an extremely critical input to the development process. But sometimes it’s not all that easy to identify and prioritize user needs and ensure that they drive relevant decisions throughout medical device design or combination product development.
We are here with Insight Product Development’s Director of Research and Strategy Carolyn Rose to try and understand some of the nuances that help ensure success when considering the impact of user needs on product design.
Carolyn, let’s assume you just completed some ethnographic based design research and you have just unearthed some pretty important needs…
Can you share how to prioritize user needs? Once you’ve done that, how do you organize user needs?
“Ok, sure. It starts with a qualitative assessment of importance based on what you hear in the field. This type of assessment is very different than quantifying something. In order to understand what the biggest goals and pain points are from the user perspective, it’s generally an assessment of two things: frequency and volume.
I think frequency is kind of obvious. For example, if my sample is with 15 people, was it something that 12 of the 15 are citing unprompted? Or is this more of an anomaly, where I’m only hearing it from one person?
In thinking about volume, is somebody getting really excited? Is there a lot of passion and energy behind whatever it is they’re expressing? Or is it something that feels relatively minor based on the way it’s being expressed?
So we have one sense of prioritized needs from what we learn in the field and from engaging with potential or current end-users. We also have another—the design perspective—which pulls each of these needs through a filter that asks: what’s the potential impact or implication? We’re thinking through, okay, ‘Is that need core to function?’ As in, is it going to actually impact the intended use? Is it related to the efficacy? If we don’t deliver against this need, are we going to compromise the extent to which it’s going to be effective?
Safety is another big one, so we usually pull it through those first: what’s effective versus what is safe. These two are key issues that we address with core Human Factors activities.
Beyond efficacy and safety, there are other things that come into play that aren’t as easy to categorize. For example, the frequency of the interaction, considering any unique capabilities or limitations of the user group, the range of users and the environment of use.
It’s important to note that prioritization acts as a development compass, providing a base reference and a direction on where to focus your efforts. However, all user needs must be addressed. For this reason, we’re not individually ranking each need (that level of detail would be fairly arbitrary and is unnecessary). We typically create 3-4 buckets or tiers that act as an early framework for comparison.”
Is it possible to have conflicting user needs?
“It can sometimes happen that user needs, typically derived from different user groups (like a nurse versus a patient) may seem conflicting. However, an understanding of the ‘whys’ behind desires and preferences can often unveil the ‘common ground’ or user need and the ‘context’, which often becomes the design challenge (or opportunity!).
Let’s use diabetes management as an example, specifically end of dose feedback when administering insulin. Both the nurse and the self-administering patient want confidence that the full dose has been administered.
From a nurse’s perspective, they’re articulating a desire to have a loud, clear sign that it’s been done right. Because they’re in a clinical space with lots of activity, there’s no reason to be discreet.
However, the patient might be on a train or having dinner with a friend. They might not necessarily want to call attention to the fact that they’re administering their dose but they still want confirmation that it was administered. Perhaps this person could receive confirmation via mobile app.
The point here is that user needs, in the way we frame them, are never conflicting. All must be met. But desired ways to address them may conflict, often based on contexts of use. A successful design solution will strike an effective balance across varying contexts of use and/or provide solutions specific to a unique context.”
How can you ensure that the design continues to satisfy these important user needs downstream in the development process?
“First, the user need must be properly framed. We’re probably all familiar with user needs that are not properly framed. Some can be super-vague—like “easy to use” or have lots of detail—”have a dial torque between four and eight inch-ounce.” We’ve spent a good amount of time thinking through what makes an effective user need. First, we defined what a user need is.
A user need is a capability and/or affordance that must be provided within the context of the intended use of a product. It seeks to answer the following questions from a drug delivery or medical device perspective:
What does this device need to do to achieve the desired end result? In thinking through the use case and context, what’s the who, what, when, where, why and the role that these play on the device capabilities?
Then we came up with four user need mandates. These are intended to help us as we’re writing user needs because they act as a gut check to determine if it meets the intent of our definition. It seems silly, but sometimes you write something and you wonder, ‘Is this truly a user need?’ Referencing these mandates is a good way to ensure consistency.
These user needs are the first design input that ultimately lead to product requirements and should be continually referenced throughout development. Properly framed user needs are the first step in ensuring this type of traceability.
As you can imagine, it becomes harder and harder as development progresses to try to relate a requirement back to something like “easy to use.” If it’s properly framed, I think it’s fairly easy to be able to connect the dots from that user need to what you’re exploring. From that exploration, which concepts/approaches are best enabling those user needs? And then ultimately, how or in what way? Essentially, these answers are the foundation for our product requirements.”
Take a deeper dive into Identifying User Needs to Drive Effective Medical Device Development by checking out our user needs process map!