6 Strategies to Getting Genuine User Feedback in Medtech

Bringing a novel technology to the market in the form of a new medical product introduces several challenges:  Will the technology work the way that it is intended?  Will it meet clinical objectives?  Will it achieve FDA’s safety and efficacy requirements?  While these challenges are important, there is another challenge that few companies sufficiently address during novel products’ development phases: Will people use it?

Startups often are advised to get feedback from their customers, and attempts to gain feedback typically take the form of a survey. The survey generally consists of several background information questions and some binary, “yes/no” questions to suggest whether customers would be receptive to a new solution. Surveys can be very effective when customer needs are explicit and users are considering alternatives, or incremental improvements, to products they may already be using.  But, when no existing product addresses a problem customers may have, adoption — and, presumably, regular use — of a new product requires behavior change, and attempting to address behavior change through a survey leads to highly unreliable data.

Behavior Changes And Switching Costs

Convincing humans to modify their existing behaviors, or to add new behaviors into their daily routines, is one of the most challenging parts of bringing a novel device to the market. In the deceptively simple words of one surgeon, “My job in the operating room is about minimizing stress, and I’ll change when the stress of staying the same outweighs the stress of changing.” What the surgeon really means is that the true upside of any new solution equals its advantages minus any “switching costs.” Beyond monetary costs, these can include any pain points associated with adoption, such as training, learning curve, new risks, etc. If the benefits are too small, they could be cancelled out by switching costs. The surgeon’s statement also reveals a critically important truth: most users are reluctant to change until presented with an extremely compelling reason to do so.

Case Study: Changing Behavior Of Elderly Adults

Philadelphia-based startup ActiveProtective aims to protect elderly adults against fall-related hip injury through a wearable airbag system. In collaboration with Smithwise, Key Safety Systems, and Inertial Labs, ActiveProtective has developed a system that can accurately detect the incidence of a serious hip-impacting fall, deploy airbags over the hip regions within 40 milliseconds, and send out an alert to caregivers.

Since the company’s inception, one of ActiveProtective’s critical questions has been, “will users wear it?”  Rather than immediately jumping into product architecture, ActiveProtective dove deep into understanding the psychology of various user groups, analyzing user painpoints, motivations, habits, and perceptions to the company’s product concept.  These are some of the key insights from that process:

1. Separate the needs from the product — All too often, developers make the mistake of framing their interviews around design improvements being contemplated for their new solution. In other words, interviews place a prototype on the table and “lead the witness” to the answers developers want to hear.  Before jumping into product mode, ActiveProtective visited target users in their environments to understand the challenges they faced on a daily basis. This process illuminated critical needs, some of which were apparent to users, and others that were more latent.

One critical need quickly revealed during this discovery process was mitigation of “fear.” Many of the elderly individuals interviewed were keenly aware of their risk of hip fracture, as well as the associated decrease in mobility and quality of life that occurs after such an event. This fear was explicit, captured by many vivid and emotional stories told about friends or loved ones who had experienced hip fractures and subsequently suffered often devastating consequences.

Other latent needs not directly articulated by users, but observed by the design team, included the challenge faced by many elderly people in putting on particular types of clothes. For instance, the research team observed many seniors struggling to insert a second arm into a jacket sleeve, due to lack of flexibility, or struggling to depress small buttons, due to arthritic hands and lost tactile sensation.

 

These insights were captured by separating the needs of the target user group from the ideas behind the product.  Going into discovery mode with a “solution-neutral” mindset can help a product team remain objective before becoming attached to particular design directions.

2. Create user segments — Among the qualitative data gleaned from ActiveProtective’s discovery research, a number of distinct user personalities emerged, differentiated by their specific painpoints, motivations, and habits. To put these various personalities into context, the development team created detailed “personas” for each user group. These personas described living situations, degrees of social engagement, levels of mobility, and the painpoints / motivators unique to each group.

These user personas provided the team with a specific vocabulary to reference regarding each segment. More importantly, these personas enabled the team to identify the segments considered to be primary targets for the product. As the saying goes in product development, “designing for everyone means designing for no one,” and the team was determined to focus on the user groups in which both need and likelihood of adoption were maximized.

3. Start with a story (not a demo) — Before extending too far down the design path, it is critical to obtain product-specific feedback. This feedback may relate to the overall product concept, or to specific product embodiments and feature sets. Often, startups want to start these conversations with a demonstration, perhaps in the form of a video or a live product demo. Starting with this type of demonstration generally is not a good idea. The viewer of this demo may realize the amount of time and energy the product team has invested into the creation of the demo prototype, and they will refrain from providing candid feedback due to their association of you and “your baby.”

 

A better way to start these conversations is through a simple storyboard, which allows an interviewer to provide some context and describe the solution in a low-tech, easy-to-comprehend manner.  The storyboard typically should be presented in a way that objectively illustrates what the product is intended to do. Details surrounding the technology should be avoided, unless there are technology limitations or constraints that could benefit from specific feedback.

Most importantly, take care to avoid biasing the user by “spoon-feeding” the product’s purported benefits and value proposition.  A common mistake when describing a product via storyboard or general verbal description is transitioning into “sales mode.” Inventors may rattle off a long list of the new product’s benefits, which only furthers the association between inventor and product.  It usually is more valuable for interviewers to learn concerns and questions about a new product, rather than receive validation.  The concerns are almost always out there — it’s just a matter of conducting the interview in a way that elicits them.

4. Share multiple models (not just one) — With many new-to-the-world products, there are numerous options related to product architecture.  ActiveProtective ruminated, should the product be a belt? Should it be an undergarment? Maybe a long jacket? Additionally, there often are questions about specific features. How should the product be activated? Should it be colorful and stylish, or muted in aesthetic?

 

To address key product architectures and functionalities, the ActiveProtective team created a series of use-case mockups and revisited potential users to gather feedback and preferences. These mockups represented the different usability modes identified by the design team. Note that these use-case mockups were non-functional, intended only as “props” used to describe how the product might be used. These mockups were presented to the interviewees to capture feedback on specific concepts and also specific feature sets.

After these concepts were reviewed in their entirety, the users were asked to rank each, from favorite to least favorite. This ranking exercise shifted the conversation to “why” — why was “Concept H” your favorite, or “Concept L” your least favorite? Often, this ranking process yields the most tangible data that can be used for advancing a design.

The alternative approach taken by most startups is to present a single demonstration unit, typically more functional in nature.  This “show-and-tell” generally will provide binary feedback – “I like it” or “I don’t like it.” Since there are no comparisons to reference, it is difficult to identify the rationale behind likes and dislikes.

5. Understand short-term and long-term reactions — User feedback and reactions generated by an in-person interview generally are based on snap judgements. While these initial reactions are informative, they may differ from the long-term response and adherence to a new product. ActiveProtective recognized this potential disparity and designed an extended-use case study, leveraging a group of 30 users to evaluate the longer-term perspectives.

During the study, individuals were asked to wear a non-functional belt mockup for 28 days, while keeping a daily journal to capture how the belt fit (or didn’t fit) within their daily activities and routines, as well as to record any suggestions for design and usability improvements. User perceptions of the product were captured in Day 1 and Day 28 interviews to measure changes over time. A sensor contained within the belt tracked when the belt was being used. The users were informed that the belt was non-functional, so the benefits that they would gain from participation in the study were minimal. Despite this caveat, a broad base of users was willing to participate, and valuable insights were gained that never would have been revealed in scripted, face-to-face engagements between users and developers.

6. Pricing – don’t go there — It is tempting to broach the subject of pricing during user feedback sessions.  While understanding pricing is critical for business viability, asking users about pricing thresholds related to a new product will almost always yield unreliable data. It is not uncommon for users to suggest high pricing levels during an interview session, only to respond very differently when it is time to make a purchase.

A better method to gauge price elasticity is to observe other products in a user’s environment that provide similar value. In the ActiveProtective case, it was reasonable for the product team to understand whether target user groups were investing in patient remote monitoring systems (e.g., Life Alert). Using existing systems with comparable benefits as a baseline, and adjusting price levels to account for advantages or differences in functionality, can be a reliable approach to assessing price levels early in development.

Gaining Reliable User Feedback Is A Science

As the methodology above suggests, reliable user feedback is born of a strong process. This process should be treated no differently than any other science:  Protocols should be developed, interviews should be conducted consistently, data should be captured, and the results should be analyzed thoroughly before conclusions are drawn.  This will arm you with the confidence to answer that all important question: “Will people use it?”