Translating User Needs Into Actionable Design Inputs
Developing a medical product first requires defining precisely what that product is supposed to do. Commonly, discussion among stakeholders elicits vastly divergent ideas. The challenge here is for everyone to get on the same page, speaking the same language, before any useful product development decisions can be made.
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 if they can be contradictory 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.
Our first step in reaching consensus on product requirements is to conduct contextual user research. We run these valuable sessions around multiple use cases and user types to reveal insightful context, allowing 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 like a weary grimace or the wide eyes of a satisfying surprise. Identifying needs, and especially their context, 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 some 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 for the strategy and development teams to proceed 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; 15 second max ready time, 3 interactions to task completion, 90% of users can distinguish haptic feedback from device harmonics, etc…
Each project has a myriad of requirements from all corners of the business, including the design inputs derived from user needs. 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 is called a Product Requirements Matrix) tracks the development details of each requirement through verification and validation. This matrix’s value is two-fold, serving as a high level progress overview as well as a detailed account of the development of each individual requirement.
With a tailored Product Requirements 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 the risk of developing the wrong product. Utilizing a Product Requirements Matrix adds the structure needed to track the development of product requirements through to a validated product ready for market.