Translating User Needs Into Actionable Design Inputs
Developing a medical device first requires defining precisely what that product is supposed to do. Discussion among stakeholders often elicits vastly divergent ideas. The challenge here is for everyone to get on the same page before any useful product development decisions can be made. You need to make sure you’re speaking the same language — as early as possible.
This is easier said than done. Other aspects of product development are much more cut and dry. Budgets and timelines are written in a near universal format, even though they can be conflicting at times. Market opportunities and business goals typically have defined metrics. Regulatory at least has a method and documentation for moving forward. When we get to users however, it can become difficult to identify and translate their needs into actionable items that can be verified and eventually validated.
Building and Utilizing Accurate User Needs
At MPE (Formerly Mindflow Design) , our first step in reaching consensus on product requirements is to conduct contextual user research. We run valuable sessions around multiple use cases and user types to reveal insightful context. These sessions allow us to accurately identify and carefully articulate user needs. Some needs are easily communicated by the user; others are hidden away in nuanced body language. (Imagine a weary grimace or the wide eyes of a satisfying interaction.) Identifying needs in context with tasks and use environments is the foundation of use-centered design.
Once the user’s needs have been fully captured, they must then be translated into a common language. “The Device Must be Portable” can be interpreted many ways, especially by large development teams with different perspectives.
In a recent meeting, we were assessing the vision that our client had for their medical product. The word “intuitive” came up frequently. The sentiment was fitting, but it also had the opportunity to be misinterpreted when it came time to create metrics for verification. For some, intuitive meant simple and quick to task completion. For others, it meant guided and stress-free. Clearly there was work to be done to unify our client’s vision and the users’ needs.
A lack of refined definition can lead to products that pass verification but inevitably fail validation or perform poorly in the field. Viewing the users’ needs in context and deriving design inputs to satisfy those needs ensures that there is no misalignment between verification and validation of the product.
We rely on our team of human factors researchers and development strategists to accurately translate user needs (qualitative) into design inputs (quantitative). This translation process not only creates clarity for the project stakeholders, but also provides a universal language. The strategy and development teams are able to use that language to proceed smoothly through the verification and validation process.
In the case of defining the intuitive product, we found in our contextual user research that the client was touching on a trend of users’ dissatisfaction with the complexity of a competitor’s product. In the end, we tailored quantitative definitions for the users’ needs. Fifteen second max ready time, three interactions to task completion, 90% of users can distinguish haptic feedback from device harmonics, etc.
Each life science and medical device project has a myriad of requirements from all corners of the business. This includes the design inputs derived from user needs and so much more. Forging all of those requirements into a product that delivers a satisfying user experience, one that demands the repeated and successful completion of a task, requires the ability to view the product development process as a whole.
A traceability matrix (ours here at MPE (Formerly Mindflow Design) is called a Product Requirements Matrix) tracks the development details of each requirement through verification and validation. This matrix’s value is twofold. It serves as both a high level progress overview and a detailed account of the development of each individual requirement.
With a tailored traceability matrix for our client above, we were able to closely track the development of the “intuitive” features from design input through design outputs, verification, and eventually validation testing. We were also able to simultaneously monitor the progress of many other requirements, like ingress protection, RF emissions, and chemical resistance.
The high-level takeaway here is that accurate translation of a user need into quantifiable terms will greatly reduce your risk of developing the wrong product. Utilizing a traceability matrix adds the structure needed to track the development of product requirements through to a validated product ready for market.