Med Device Rosetta Stone: Translating User Needs Into Design Inputs

By Craig Scherer, Senior Partner & Co-Founder, Insight Product Development 

Design innovation consultants are asked to help clients understand users holistically: Who they are, how they differ from each other, how they are influenced by their environments, and how they might change over time.

We must look to our core development process to focus around the user and all critical stakeholders. Designing optimal solutions means taking into consideration all of the influencers on the user, which might include technology strategies, market trends and opportunities, or outside influences, like regulatory and reimbursement systems.

Across medical device press, conferences, and other public forums one constantly hears organizations ask the question, “So…I have all of these user needs defined – what the heck do I do with them now?” What they really are asking is, “how do I translate user needs into specific and actionable design inputs?”

Understanding Users

To answer that question, we need to understand our users on many fronts, ensuring that we have identified their relevant and critical needs. When we drill down into the user-centered design drivers, human factors engineering (HFE) always seems to be at the center of the discussion. The FDA does a nice job of characterizing various user attributes that need to be addressed throughout development. These include physical capabilities like strength, reach, and readability, as well as cognitive abilities, like understanding and learning. Also, what is the user’s state of mind emotionally — are they stressed or anxious? And finally, how do their experiences help them, and how were they trained?

These all are great user attributes that must be characterized when capturing user needs, but we also need to contextualize users and their products to understand environmental influences, as well as users’ expectations around workflows and goals. This is achieved through utilization of ethnographic research methods, also known as contextual inquiry. It also is important to consider that humans are dynamic: Their needs, wants, and desires change as they become experienced using a device, or as their disease states change.

However, research methods and processes have evolved to be much more holistic. In performing core human factors evaluations, we can go beyond being simply safe and effective, drawing upon users’ core needs, wants, and desires to make user experiences much more meaningful and rewarding.

Still, now that we have collected all this great data and documented our target users’ needs, how do we ensure that we can translate them correctly into product attributes?

Characterizing Needs

This is where the fun begins. A three-step process can ensure that we have documented and evaluated user needs correctly. We must first prioritize the user needs based on the critical-to-function tasks — those at the top of the list are the must-haves. Each subsequently listed user need is less critical, with the bottom section consisting of “nice-to-haves,” all things being equal.

Having been informed by research, the development team works to document variables such as intended use of device, its frequency of use, and its important safety issues. It also is vital to understand and document the limitations of a particular user group, and to consider that the device may be utilized by a diverse set of users or environments.

Next, identify opportunities for the new design. These might include improvements to current solutions for next-gen devices or, in the case of new-to-the-world solutions, they may be evaluated against ideal states. Try to envision how each particular physical characteristic of a design might best solve each of the prioritized user needs.

Finally, take the highest priority needs, with the strongest solution opportunities, and evaluate the development challenges to the overall program. Understanding risks that might be introduced into the program is another great way to down-select to a realistic solution set.

Ultimately, this resulting matrix is designed to represent the target features, functionality, and guidelines for developing early concepts.

Balancing User Capabilities With Device Complexity

The process of proving out prototype work flows and interactions is iterative and interactive. It is critical to understand project risks by evaluating the measures taken to capitalize on an opportunity. Likewise, a balance must be struck between the “total” solution — solving every user needs to the fullest — and the need to minimize project and product risks. Achieving the correct balance means understanding the potential outcomes caused by overburdening the user with complexity of interaction, and balancing that understanding with issues that may be caused by creating an overly complex device.

The consequences of failing to achieve that balance can stop a project in its tracks. Overburdening users might lead to a treatment is not delivered successfully, or a procedure that is slow and inefficient. The worst outcome might be that safety or clinical efficacy is compromised. Additionally, a too-complex device might mean a solution that is too costly to manufacture, has reliability issues in the field, or has R&D lead times so long they fail to capitalize on market opportunity.

A great example of this phenomenon is the common syringe vs. the highly automated auto-injector. A typical syringe is frequently used by a trained RN, so it can be a both manual and inexpensive, whereas the much more costly and complex auto-injector often is used by an untrained user in a very stressful situation.

Thus, we should follow a process:

1. Identify and document user needs — Through a combination of embedded knowledge and various research inputs, assess how current needs are being addressed. Are they unmet? Poorly met?
2. Prioritize user needs, understand opportunities, and vet risk — The opportunity to satisfy a particular set of needs has to be weighed against the significance and relative importance of each of those needs, as well as the development challenges associated with satisfying them.
3. Propose physical solutions to meet user needs, creating functional specifications — As various configurational embodiments are developed, they are embodied as early prototypes. These prototypes are built from early specs, designed to solve for the prioritized user needs.
4. Confirm appropriateness through usability testing and functional testing — User research confirms the best approach to meeting prioritized user needs, while at the same time confirming the ability of a physical developmental model that meets those needs, tested for appropriate functionality.
5. Analyze and respond to project risks relative to technology selection — Support a technology strategy that has been proven effective long-term and can provide commercial scalability; continuously vet new technology for its ability to meet user needs, as well.
6. Document design inputs for detail design under design control — These inputs will be used to develop an integrated design, which ensures the system concept will successfully deliver on user needs relative to the chosen technology platform

Following these methods will help create solutions that consider external influences, like market trends and regulatory requirements, in ways that help you differentiate your offerings, achieve great adoption, and ultimately provide better outcomes to improve lives.

About The Author

Craig Scherer is senior partner and co-founder of Insight Product Development. Craig plays an active role in key account management, working with companies ranging from early stage tech organizations to the largest healthcare OEMs. He is also a director of Insight Accelerator Labs, Insight's in-house med device accelerator, helping medtech start-ups deliver transformative technologies to healthcare. Craig holds a BFA in industrial design from the University of Illinois at Urbana-Champaign and an MBA from the University of Illinois at Chicago.