How to create innovative products using Design Controls

In the movie Wolf of Wall Street Leonardo DeCaprio challenged his team to “sell me this pen,” implying that a good salesperson could sell anything.

This article helps teams “design a pen” using methods that benefit almost any project and includes tips for encouraging creativity and innovation. I wrote it for the biotech or medical device industries but the concepts apply to any company that must share work among a team.

I wrote a Pen Design Plan to demonstrate the concepts I’m about to describe; you may benefit from having it open at the same time.

Background

Governments require that companies selling medical devices adhere to design control regulations. The most common references are the FDA 21 CFR 820.30 and ISO 13485. You can learn more in my article on Design Control regulations.

What you’re reading now will jump into the design process using terms from the FDA

Step 1: Phrase Your Goal Wisely

Your ability to innovate happens when you’re stating your intentions or testing a new market, before design controls are required. Consider the differences in these goals:

Make this penDesign a penSolve the customer’s needsRevolutionize the pen market

There’s no right or wrong, just be aware that your choice will impact your team’s work. “Make this pen” could result in a high-quality writing instrument but won’t lead to innovation. “Revolutionize the pen market” is difficult for most companies and works best for entrepreneurs or researchers. The middle way between these extremes may be “design a pen,” which is a close to “solve customer needs” but with enough constraints to be a wise business decision.

Beware of advice on how to be creative; nothing is more effective than learning-by-doing and being the user of your own inventions. Practice phrasing how you’d solve a problem around your home, for work, or with your kids. Over time you’ll become wise at phrasing the first question so that other people have just enough information to begin but with enough ambiguity to bring out creativity.

Step #2: Understand User Needs

Understanding user needs is more than just listening to your customers, it’s also trying to understand their situation and acknowledging that they are conditioned by previous experiences. With practice, you learn the middle-way between making what they ask for and innovating something they appreciate.

A way to innovate medical devices is to immerse with healthcare providers, looking at their situations with a fresh perspective, identifying the underlying user needs. This is the method behind the Standford University BioDesign program, a year-long process where participants spend three months in operating rooms before brainstorming new product ideas.

Intended Use:

For our pen, let’s say that we immersed with surgeons and learned that they’d benefit from a pen that can mark on a patient’s body during surgery, allowing a team to visualize and agree upon incisions path for procedure modifications during a surgery.

User needs:

#UN1 visible on a range of patients’ skin colors#UN2 sterile pen#UN3 sterile and non-toxic ink#UN4 easy to hold and use

Describe your typical user and include it in your user needs documents to help team members understand their work or develop tests that simulate use. We’ll define our typical user as a surgeon, experienced with operating-room procedures but busy with many other things during surgery and unlikely to focus on a complex design. Also, consider who would be impacted other than your user; medical devices are unique in product development because our final user, the patient, is often not our customer and is rarely asked their opinion.

Step #3) Inputs

Design controls are not required for early-stage brainstorming but are required after you commit to designing a product [21 CFR 820.30(a)]. Three of the first things required are the Project Plan, Design Input, and a Design Review.

A plan is a detailed method for designing your product, including design input, or what the product must accomplish, who’s responsible for each aspect, how you’ll measure success, etc. The plan and inputs are agreed upon in a design review, conducted by a diverse team of people who will later have another review ensure that your product meets all inputs and was designed according to the plan.

You’ll have many different reviews, some for high-level, such as the development planning and design inputs, and some for detailed work such as mechanical design teams, packaging design teams, etc. The FDA requires that each review has at least one person uninvolved with that responsibility; this is to maintain diversity in thinking and minimize conflicts of interest.

Most companies have separate documents or at least separate sections of all things that contribute to design input, the most common being:

User needsBusiness or marketing needsRegulatory needsRisk Management

Note: Risk management is a relatively new, high-level document required by modern quality control policies. To learn more, see my article where I re-analyze the 1986 Space Shuttle Challenger explosion using modern Risk Management methods.

Design inputs need to be solved, but how you solve them is where innovation occurs.

There’s no clear definition between where needs or inputs end and design features begins; the balance between these two comes from experience of balancing structured design with innovative freedom, practical boundaries with freedom to explore new ideas, and clear direction with open-ended problems.

For this article, let’s assume a few “needs” documents, which may also be called “requirements.” Don’t get stuck on words, many other documents are often referred to as “requirements.”

Regulatory needs:

#RN1 Must use ink or marking material that’s approved by regulatory agencies in the United States and European Union

Business needs:

#BN1 Must be color-coded to match corporate brand: “blanched almond,” hex code “ffebcd.”

You could use your input document to outsource research and development. I’ve worked with innovative companies sent our input document to contract design companies to get diverse solutions to the same problem; our contract ensured we would own any patents.

Optional step: requirements

Many companies create requirements that clarify user needs, removing ambiguity so that design engineers can meet objective criteria. Too much clarity can reduce innovation, so there’s a balance between clarity and ambiguity that combines efficiency with innovation. The balance between “design input” and “design requirements and features” is open to interpretation that comes from awareness and practice.

Examples of design requirements for our pen could include:

System-level requirements:

#SR1 ink must not leak when pen shaken by a typical user*#SR2 ink and pen able to be sterilized using gamma radiation#SR3 able to be used 10 times without failing**

Mechanical requirements:

#MR1 must not slip out of hands in a typical hospital surgery room environment*

Ink requirements:

#IR1color = black, hex code “000000”*

Similarly, you could have packaging requirements, labeling requirements, etc.

Keep the end in mind…

Design inputs are what a product must accomplish. Design outputs are how the product accomplishes them. Start with the end in mind, recognizing that design inputs must be defined well enough to envision how tests would look to verify them, but ambiguous enough to allow innovation. Your requirements are this middle ground. Ultimately, anything you choose must be validated against user needs.

Think about this…

Defining requirements is an art, not a science, and requires diverse people contributing throughout product development.I recommend testing your product throughout the design process with diverse users, always keeping an open mind to user needs that may have been missed in input documents, especially new risks introduced by design features.

In my workshops I emphasize this situation because an underlying problem with medical devices where we often forget that our users include patients, and their voice is often overlooked. This isn’t intentional, it’s the result of a society where most executives, managers, and even engineers are white males.

Consider this simple example from an automatic soap dispenser that used infrared lasers to turn on water but only for white hands:

Last year the person filming a soap dispenser that only worked on white hands Tweeted:

“If you have ever had a problem grasping the importance of diversity in tech and its impact on society, watch this video”

Not considering diverse users for a soap dispenser is inconvenient; not considering diverse users for medical device design can be life-threatening.

Let’s assume we went back and changed the requirements document, which would be controlled by our company documents system so that old versions are archived and the latest version is used by designers.

Ink requirements, version 2:

#IR1 color = silver, hex code “??????”#IR2 color able to be seen on typical patients’ skin, including diverse races, in typical operating room lighting

Your requirements may continue to evolve as you learn more, including learning that what you originally stated is ambiguous for other team members. For example, phrases like the pen should be “able to be used 10 times without failing” is ambiguous; under which conditions?

Words are ambiguous to everyone except the person saying them, so I advise companies to have test protocols defined during early-stage input meetings. This can be as simple as “able to be used 10 times in a worse-case scenario of being dropped from 5 feet and stepped on,” which clarifies the design intent to a diverse team.

Summary:

Step 4) Verification & Validation

Design validation ensures you met user needs. For example, a user need of “easy to hold” can’t be tested in a laboratory and must be validated by user testing in simulated situations. As an example, our pen may work well in a laboratory but could be dropped by a surgeon wearing gloves made slippery by body fluids.

Requirements like “greater than 4 inches and less than 6 inches long” can be verified in a laboratory without user testing. The requirements unambiguous; for example, 4.0 inches tells us that the accuracy must be to +/1 0.01 inches, and a color’s hex code of “ffebcd” is unambiguous and can be measured rather than interpreted.

Some requirements must be tested to worse-case extremes, such as “able to be used 10 times without failing.” You could simulate a worse-case scenario in a laboratory by removing the cap, dropping it, and stepping on it 10 times before writing with it. This is a form of validation usually combined with manufacturing requirements; when you can’t 100% of your products you must test a small percentage of them and validate that the results are statistically relevant for all products manufactured. As an example, we wouldn’t test each pen to failure, but we could test 10 out of every 1,000 manufactured to ensure quality-control between each batch made.

My advice is for your project plan to include a brief statement of how you would test each user need. For example, an input “easy to use” would include a brief description of the test, such as “ten new users must be able to open the packaging and use the pen within five seconds.” Those initial descriptions would also guide teams in designing thorough test protocols. For example:

Verification tests:

Ver#1 Scales used to weigh shall be accurate to at least +/- 0.01 ouncesVer#2 Colors shall be verified using color-codes, either hex or RGB

Validation tests:

Val#1 The design must work after having 10 tests of being dropped from 5 feet and simulated being stepped on by a 200 lb person wearing tennis shoesVal#2 All design features that can not be simulated or tested, such as “ease of use” shall undergo a validation test with real-world users representing the typical user defined in our input document (education level, experience level, cultural background, etc.)

For initial design planning it’s fine to have generalized test descriptions, but all tests should be refined throughout the development process, becoming complete and unambiguous so that anyone would have all information necessary to repeat the tests, including which equipment to use and the level of accuracy required. Consider this: if a future team had to modify your product they would need to repeat the tests you used; and if problems were discovered during real-world use they would need to improve test protocols to better represent the real-world. So, for the patient’s benefit, and for complying with Design Controls, please continuously improve your verification and validation protocols to be thorough and unambiguous.

Summary:

Step 5) Outputs

Each team uses the input document or their requirements document to design solutions, often starting with simple drawings or prototypes that can include software codes, electrical components, mechanical features, regulatory labels, packaging, final-product inspection criteria, etc, all of which are considered design outputs.

In other words, you’re given inputs and you create outputs.

Caution: Many companies have a product and then create their design controls by making their inputs match what they’ve already created as output. This limits innovation and creates unnecessary bureaucracy.

For our pen example, consider the requirement for ink to be visible on diverse patient’s skin colors. One solution could be a silver-colored ink, which I believe should be considered an output; this allows room to learn and improve the color of ink and to change the output documents without needing to also change input documents. If the input requirement were “silver” then teams would stop looking for more effective colors that still meet input requirements.

Overlapping input and outputs is often done when regulations are treated as an afterthought, something done to “check the box” of having inputs after a product has been designed. Though not illegal, it’s ineffective, discouraged, can lead to patient harm, and almost invariably adds bureaucracy because all small changes to outputs would also require updating input documents and having high-level design reviews. I advise keeping input documents high-level to allow teams to focus on continuously improvement by iterating outputs. High-level inputs allow a team to “design a pen” rather than “make this pen.”

Summary:

Iterate

Make sure you plan time to iterate; many companies become overburdened manufacturing flawed products. More time sharpening an axe during design means less time chopping wood during manufacturing.

A way to ensure iteration throughout the design process is to continuously test prototypes using your verification and validation tests, document changes to both the design and the tests, and, if necessary, iterate your inputs or requirements, especially when you learn things not addressed in your initial Risk Management.

An effective company will also have a closed-loop quality control system, continuously improving designs based on real-world feedback. To learn more about closed-loop quality systems, see my articles on the process-approach to medical devices and the European Medical Device Regulations.

Design Changes & Design History File

A reason Design History Files are required by law is that medical devices were failing in people after innovative companies were acquired by larger companies that re-introduced bad designs into the products.

I recommend making the Design History File and the plan the same document, just as I recommend making the plan and the final report the same document. You’d start with a plan, documenting all changes.

Summary:

Design Transfer

Design transfer is nothing more than ensuring you recorded all design features and it’s ready to be manufactured; it’s “make this pen” and be ready to make thousands of them.

Design transfer requires a design review to ensure that all inputs were satisfied by verification and validation testing of production-equivalent designs. This step is often part of validating your manufacturing process, and from this point design and manufacturing processes are linked: usually you can’t change one without re-validating the other.

A best-practice is to create a “trace matrix” that shows hall all inputs were satisfied by outputs by verification and validation, and agreed upon by a design review. In other words, make it easy for someone outside of your company to see that you met all needs through design features; this is especially important for risk management solutions.

User need #UN1 (or UN2, or UN3, etc)Described in “our input document.doc”Described in requirements #MR1 (or MR2, MR3, etc) and #IR3 (or 4 or 5, etc)Addressed in design features (outputs) “_____” and “_____”Verified by tests #Ver8 (or 2 or 3, etc)Validated by tests #Val4 (or 9 or 10, etc)

Many companies create a trace matrix and discover that they either missed an input or that some design features (outputs) do not come from a need, a phenomenon known as “project creep” that can add cost and complexity to designs without providing benefits. A trace matrix used throughout your design process can minimize creep and help team members prioritize their work.

Summary:

Summary

These steps are required:

When you commit to developing a product, follow design controls. Start with a plan, list all inputs, and have a design review. Create outputs. Use verification and validation tests to ensure that your outputs meet all input requirements. Document all changes in your Design History File. Have a final design review to transfer your design to manufacturing.

This is my advice for using the requirements for innovation and efficiency:

Start with the intention to be innovative: phrase your questions wisely and seek to understand your user’s needs. Ensure that you test designs throughout development so that people keep focused on what the user needs. Document all work.

Next step

Read about Manufacturing Process Controls in my article, “Make this pen.”

Keep in touch

My goal is to educate others so they’re able to do more things that benefit themselves and society. I consult corporations on international regulation requirements, teamwork, and innovation; and public schools on incorporating engineering and entrepreneurship into curriculum requirements.Connect on Linkedin, where I infrequently post articles. Subscribe for yearly updates, or browse this blog for articles.