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 drug delivery device development.
We are here with Insight’s Director of Research and Strategy, Carolyn Rose, to try and understand some of the nuance that helps ensure success when considering user needs and their impact on design.
Carolyn, let’s assume you just completed some ethnographic based user-centered research, and you have just unearthed some pretty important needs…
How do you know which user needs are the most important and how do you organize them?
“Ok, sure. It starts with a qualitative assessment of importance based on what you hear in the field. and of course, a qualitative assessment is a very different than quantifying something. To understand from the user perspective what the biggest goals and pain points are, it’s generally an assessment of two things; frequency and volume.
Frequency, I think, 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 something that might be more of an anomaly where I hear it from only one person.
Versus volume – is somebody getting really excited and 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, and then we have another, the design perspective, which pulls each of these needs through a filter of what’s the potential impact or implication. We’re thinking through, okay is that need core to function, meaning it’s going to actually impact the intended use? Is it related to the efficacy in that if we don’t deliver against this need we’re going to compromise the extent to which it is 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 are not as easy to categorize, such as frequency of the interaction, considering unique capabilities or limitations of the user group, and the range of users and environment of use.
It’s important to note that prioritization acts as a development compass, providing a base reference and steering you in a direction to focus your efforts, but all user needs must be addressed. For this reason, we are 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.”
What happens when you have conflicting user needs, ones that at first brush may seem mutually exclusive?
“It can sometimes happen that user needs, typically derived from different user groups, for example, a nurse versus a patient, may seem conflicting. However, an understanding of the ‘whys’ behind desires and preferences can often unveil the ‘common ground’, which is the user need, and the ‘context’, which often becomes the design challenge (or opportunity!).
Let’s use diabetes 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. Bells ringing, lights glowing…
The patient, however, who might be on a train or having dinner with a friend, doesn’t necessarily want to call attention to the fact that they’re administering their dose, but they still want to know 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, 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 process?
“First, the user need must be properly framed. We’re probably all familiar with user needs that are not properly framed, ranging from the super-vague, like “easy to use” or the super-detailed like “have a dial torque between 4 and 8 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:
Thinking from a drug delivery or medical device perspective… What does this device need to do to achieve the desired end result? Thinking through the use case and context… 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 intended to help us as we’re writing user needs to 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’re kind of like… Is this truly a user need? Referencing these mandates is a good way to ensure consistency.
These user needs are the first 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? These answers are essentially 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!