From Practice to Theory to Practice: An evolution in the methods of defining user needs

March 9, 2020
//
Andrew DiMeo

My first introduction to defining user needs was in practice as a design engineer.  It was 2001 and I was a new hire at Alaris Medical Systems (formerly IMED / IVAC and currently CareFusion, a subsidiary of Becton Dickinson).  Defining user needs was part of design controls. And design controls were part of quality systems. This was all new to me.

Background in Quality

Many industries and organizations have quality systems in place.  In some sectors where safety is of public concern, such as medical devices, transportation, and energy; quality systems are a legal requirement.  In other cases, they may be self imposed to ensure customer satisfaction. Quality systems can specify the “control” of many things. A common control is Good Manufacturing Practices (GMP).  However, there are many business functions a quality system can control including purchasing controls, document controls, and controls for labeling and packaging.

But why control the process of design?

The emphasis on design controls in Medical Devices dates back to a 1990 report by the FDA, “Device Recalls: A Study of Quality Problems.”  The report evaluated device recalls between October 1983 and September 1989 and found that 44% of quality problems leading to voluntary recalls were attributed to poor design.  A conclusion was that these recalls could have been prevented by adequate design controls.

Whether enforced by a regulatory body, suggested by a standard, or based on evidence found in a study; my opinion was that design controls are good for business.  That is, good for business in theory.  Why in theory?  It’s hard to measure the implications of workplace satisfaction and/or impact on creativity by imposing design controls on new product development.  I also think the FDA could not have predicted today’s innovation environment when first writing design controls into the regulation. Today, a significant source of medical innovation comes from hospitals, academic programs, and other entrepreneurial environments where access to user needs are abundant, but knowledge and skills of design controls are largely absent.

The Reality of the Practice

The ambiguous definition of “user needs” made its debut 7 years after the Device Recalls report by the FDA when they published, “Design Control Guidance for Medical Device Manufacturers,” on March 11, 1997.  In fact, the guidance document never defined “user needs,” but rather showed them as the source of a very well defined term, “design input.”  And so it was in this context that I learned the art of defining user needs, mentored by peers, from a source document that was low on clarity but high on importance.

My understanding for user needs at the time was as follows:

In practice though, I felt like we did the opposite.  While marketing teams may have been starting with ample research to justify a commercial need, they were typically not involved in design controls.  From an engineering perspective, traceability was being built in reverse, well after locking in a final design. With a mature product requirements document in place, user needs were often defined from the design inputs and from the design outputs rather than from the research.

Practice to Theory to Practice Iterations

Years later I would spend over a decade teaching medical device product development as a Biomedical Engineering professor.  In that role, theory was derived from practice. As noted above, I did believe, in theory, that design controls were good for business.  During my academic tenure, this was the theory put into practice by the students: New product development teams, including engineers, are responsible for defining user needs based on research.  With a focus on clinical immersion, observation, and interviews; use iterative approaches to validate those needs holistically while considering multiple product concepts.

As it turned out, a seemingly small part of this bigger theory [defining a user need as a solution free statement] in and of itself was no small task and not at all straightforward.  Through significant education and inspiration from innovation and design thought leaders, I developed several new approaches to defining user needs.  Of particular note are Levels of Abstraction (LoA) and “Shaping Boxes” – both formalized into practice at Trig (and referenced in the associated links).

The theories for defining user needs developed between 2006 and 2018 while teaching BME set a foundation for bringing them back to the practice.  LoA was only part of the equation. The time consuming practice of consumer research, defining user needs, documenting them, and then establishing traceability in the true spirit of design controls still had major hurdles from a job satisfaction and innovation stifling perspective.  

Over those same years, the academic and hospital based innovation environment was emerging.  With it, a new and even greater pain point was also emerging. Reverse engineering traceability by professionals in medical device companies was one sort of pain.  Building a design history that was likely never documented in this new, innovative environment, was a different level of pain that often blindsided medical device startups.

This was the most significant pain point.  The delays associated with establishing design controls and building design history for startup companies could be two months or more.  Sometimes I saw these delays directly attributing to startup failures. Devices that could be used today, invented in hospitals and on ambulances, that could be improving and extending lives, were instead ending up on dusty shelves or inside failed startups.

Coming up with a solution to meet all of these challenges, including job satisfaction for the professionals and increasing innovation output from hospitals and colleges became a priority.  My solution: Trig’s DHF Ready Ideation.  It was designed to make design fun, maximize creativity, and maximize social and economic impact.  Rather than a 2-month process of rebuilding design history to meet a regulation, this solution makes the regulation meaningful while removing the pain points associated with the reality of practicing product development.

Today, DHF Ready Ideation is being practiced by professionals such as the Industrial Design team at Trig.  It’s also being taught in BME Classrooms around the country. In all cases where it’s being used, it has been humbling to see the theory put into practice.

At CanvasGT, we are taking this practice to new heights.  LoA and DHF Ready Ideation are thought processes and frameworks to transform quality design.  CanvasGT is the software solution that enables real-time multi-site collaboration of the practice.  It’s the platform where creative work is done and where pragmatic requirements are formalized.

With CanvasGT, design controls are no longer good for business in theory, they are good for business in practice.

Health & Happiness for All
Andrew

Like what you read?

Check out our software