Use design controls for innovation
This article helps teams “design a pen” using design controls in a way that sparks 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. We go from defining user needs to transferring design into manufacturing.
Design controls for innovation
- Design & Development Planning 21CFR 820.30 (b)
- Design Input 21CFR 820.30 (c)
- Design Output 21CFR 820.30 (d
- Design Review 21CFR 820.30 (e)
- Design Verification 21CFR 820.30 (f)
- Design Validation 21CFR 820.30 (g)
- Design Transfer 21CFR 820.30 (h)
- Design Changes 21CFR 820.30 (i)
- Design History File 21CFR 820.30 (j)
Create a plan
Phrase Goals Wisely
The apocryphal story of Russians using a pencil in space serves as a lesson in understanding user needs: they didn’t need a pen, they needed to write in space.
Your ability to innovate begins when you’re defining your goals and brainstorming solutions, before design controls begin.
Phrasing matters. Consider the differences in these goals:
- Make this pen
- Design a pen
- Solve the customer’s needs
- Revolutionize the pen market
There’s no right or wrong, just be aware that your choice will impact your team’s work. 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 enough information to begin but enough ambiguity to allow creativity.
Understand user needs
Innovative products can’t be requested because most people start with what they already know. With practice, you learn to balance making what they ask for and innovating something they’ll appreciate.
For our pen, assume the following 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
Step #4, Input document
- #RN1 Must use ink or marking material that’s approved by regulatory agencies in the United States and European Union
- #BN1 Must be color-coded to match corporate brand: “blanched almond,” hex code “ffebcd.”
- #BN2 Must fit into existing packaging of other products (maximum of 6.0 inches long, 0.5″X0.5″ wide and deep
- #BN3 Must cost less than $1 for final products made in orders of >1,000 per month
- ou 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.
- #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**
- #MR1 must not slip out of hands in a typical hospital surgery room environment*
- #MR2 greater than 4.0 inches and less than 6.0 inches long
- #MR3 Must be less than 0.5″ wide or deep, and greater than 0.25″ wide or deep
- #MR4 weigh between 2 and 4 ounces**
- #MR5 the color of the outside must be “blanched almond,” hex color code “ffebcd”
- #IR1color = black, hex code “000000”*
An underlying problem with medical devices our users are patients, not the physicians that drive much of our work. We forget to include unspoken patient needs. This isn’t intentional, it’s the result of a society where most executives, managers, and even engineers are white males and may not empathize with diverse users. Consider this simple example from an automatic soap dispenser that used infrared lasers to turn on water but only for white hands:
- #IR1 color = silver, hex code “??????”
- #IR2 color able to be seen on typical patients’ skin, including diverse races, in typical operating room lighting
Design outputs are how you solve the inputs. Outputs include drawings, software, test methods, etc.
In other words, you’re given inputs and you create outputs.
Verification & Validation
- 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
- 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.)
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.
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)
A trace matrix quickly becomes long and complex, so I recommend starting a spreadsheet-style matrix as soon as possible and iterating it throughout development. And, like my advice to make the plan be the final report, I suggest making a trace matrix part of the plan, starting with most spaces blank so that they are simply checked off as development proceeds.
- Start with the intention to be innovative
- Understand your user’s needs
- Budget time for iterative design
- Create final testing first
- Ensure that you test designs throughout development, continuously improving both the designs and the tests
- Document all work