IDEAL Biomedical | Entrepreneurship

Enabling Evolutionary Design

A tweak to the Waterfall Method that unlocks creativity

Watching the flowers evolve from my front porch — Where I’m sitting while writing this article

If you know what design controls are, you know the Waterfall Model. When we interpret that infamous figure as a stage-gate process, it is a self-imposed constraint. We missed the fine print where the FDA called out the iterative nature of design.

Rather than follow the FDA example to the T as iterative, I propose an option to describe it in your design control standards as evolutionary.

The figures below illustrate the Waterfall Method interpreted as a stage-gate compared to how the method looks if executed as an iterative process and, better yet, as an evolutionary process.

Before describing each in detail, here is a brief list of the terms used throughout the figure:

• User Needs: The solution-free WHYs for what we are making
• Design Inputs: All the possible WAYs to realize it
• Design Process: The WORK to translate WAYs to HOWs
• Design Outputs: Detailed HOWs (aka requirements/blueprints)
• Medical Device: The complete thing
• Verification: Did we build it right?
• Validation: Did we build the right thing?
• Review: A check-in to document current status

Here is an oversimplified example illustrating these same terms with the design of a toothbrush:

• User Needs: Remove plaque and prevent gingivitis (these are two examples of many needs)
• Design Inputs: Toothbrush with rotating bristles, Toothbrush with vibrating bristles (these are two IDEAS since this is design, we can have many possible WAYS)
• Design Process: All the hard WORK to figure out how to make prototypes of toothbrushes, one with rotating bristles, and another with vibrating bristles
• Design Outputs: Detailed requirements such as CAD files, material specifications, and components
• Medical Device (Prototypes): The complete works-like prototypes for functional testing and looks-like prototypes for usability testing
• Verification: Does the rotating head rotate as specified? Does the vibrating head vibrate as specified? Do the measured dimensions of the real things meet the specifications called out in the CAD drawings?
• Validation: Does it remove plaque and prevent gingivitis? Note that for prototypes, we may simulate plaque removal using a model before moving on to animal testing with more mature prototypes, and eventually human testing with the final product. We may realize along the way that preventing gingivitis is too large of a claim to make, and remove it from our list of needs.
• Review: We made a prototype of a rotating brush and a vibrating brush. After functional and usability testing, we decided to go with the vibrating version and will continue our design from what we learned.

The above example intentionally included multiple options, used the definitions from the guidance for making prototypes, and included an evolution of design. These terms are not typically interpreted this way. The implementation of the Waterfall Method has been incorrectly (in my opinion) interpreted as a stage-gate method. Thus the final step of the waterfall would only be one final device, which (again, in my opinion) is not a good method for design.

Figure 1: The Waterfall Method executed as a stage-gate process

When executed as a stage-gate, the method would require all the user needs to be finalized before beginning design input activities. This is not practical. I’ve never met anyone that has attempted this in practice. Consequently, I observe a decision to have a Phase 0, pre-design control phase, or other such mechanism called out where no formal methods are required. Only after the design is mature are design controls formally implemented. As a result, all of the work done at the fuzzy front end of design is loosely recorded, if recorded at all. As a result, formal documentation of user needs, design inputs, and design outputs becomes a downstream retrospective administrative burden. What’s worse is it eliminates the benefits of having design controls in the first place. Recall that the idea is to implement a repeatable process to increase success and improve health outcomes.

Figure 2: The Waterfall Method executed as an iterative process

Figure 2 illustrates the Waterfall Method when implemented as an iterative process. It is a better interpretation. However, I argue it is still far from reality. An iterative approach is not creative enough to convince a product development team to implement a formal design method early in the process. It is also, in my opinion, slower, as we will likely pursue one iteration at a time, rather than design alternative approaches simultaneously. When an innovator shows me a prototype of their device, it is nearly always ONE prototype, rather than multiple options.

Figure 3: The Waterfall Method executed as an evolutionary process

Figure 3 illustrates the Waterfall Method when implemented as an evolutionary process. This example, in my opinion, represents the reality of how product development teams work. We might have an idea for a medical device as the first light bulb. We may then try to make a prototype and have outputs defined before we have formalized any needs or inputs. It’s OK. We are learning. In this way, the Waterfall Method blossoms like a flower.

In practice, the Waterfall Method figures as shown above are documented in the form of a table.

Figure 4: Sticky notes moving through the Waterfall Method are shown in a table

These tables are kept in software solutions and spreadsheets. They don’t look like what I’m showing in Figure 4 above. Several rows detail all the needs, inputs, outputs, verification tests, and validation studies. Each column has a one-to-many and many-to-one set of relationships. There will be many inputs to describe an individual need and vice versa.

Realized as an evolutionary process, this table will grow like a flower through a creative and defined method of innovation.

This article does not constitute a formal and complete review of design controls. For the experienced medical device and diagnostics professional, I hope this inspires you to implement an evolutionary process into your standard operating procedures. Most importantly, I hope it inspires you to be both creative and methodical at the same time.

For those who are new to medical innovation, while not comprehensive, following this process will build a solid foundation when seeking to transfer your research endeavors into a commercial venture.

For everyone, when you document your creative process, the result will avoid downstream delays and headaches associated with the administrative burden of reverse engineering your design history. More importantly, you will experience the intended benefits of design controls, namely increased success and improved health outcomes.

Thank you for reading.

health. happiness. kindness. respect. to every-being and all-things
- ajds