Product development is a complex process that involves making a multitude of decisions and choices, with all the potential for error that that entails. Given that, it’s not surprising that organizations like the FDA or the ISO 13485 standard require medical product designers to build design reviews into their development process. After all, it’s still the best way to ensure that your products are safe, reliable, and effective (and also stay on time and on budget)!
But first, what is a design review?
How often should I do a design review? And when?
Arguably, the right answer is “whenever you need to”. That’s not a very helpful response, but the truth is that there is no ideal frequency for conducting design reviews. It depends on the project and how complex it is.
For a very simple project, a single design review may be sufficient. For more complex projects, design reviews could be slated for the end of each milestone, to validate the basics of the design before moving on to the next steps.
Allows the team to verify any part of the development process in any phase.
Allows the team to verify that all design reviews and deliverables have been completed in the current phase and that we can proceed to the next phase of our IDEAL process.
IDEAL Methodology + Design Reviews
Who should be involved?
But remember when we told you in our co-creation article about how important it is to have an outside perspective when developing your product? Well, the same goes for design reviews. At least one external person should participate, which is also one of the FDA and ISO 13485 requirements for design reviews.
NOVO further exceeds the regulatory requirements by also bringing a member of its Quality Assurance team on as a reviewer. That way, we can be confident that we have people on board with a higher-level and outside perspective, while still ensuring that the design reviews are conducted properly and rigorously. Besides, it’s always good for the QA team to have an in-depth knowledge of the product development progress.
What does a design review look like in practice?
Team meetings to present and review the design
Independent review of the materials by each reviewer
How reviews are documented
NOVO doesn’t just document each design review. Our Quality Assurance team also keeps track of all the documents related to the product design, as well as their location in the Design History File (DHF) Index, which acts as a sort of table of contents for the project.
Doing so allows us to assemble everything in one place and quickly locate development-related documents, which is very useful when putting together the product design folder for the FDA.
How design reviews can make a real difference: the case of BJ Nimo DragonVision
At NOVO, we sometimes make mistakes. We’re human, after all. But we pride ourselves on having a process that leaves ample space for design reviews, allowing us to catch those mistakes before they can have nasty consequences like delays or cost overruns.
On the BJ Nimo DragonVision project, we saw firsthand how important it is to have a rigorous design review process that truly works!
Ongoing design reviews
BJ Nimo sought out NOVO’s expertise to develop an ophthalmic diagnostic tool. Since the product included a circuit board with around 20 complex functionalities, NOVO quickly realized that design reviews would need to be conducted throughout the development process. In fact, they would have to be almost constant, since the product required approval from the NMPA.
A small mistake that could have thrown a wrench in the schedule
Assessment of design reviews on the project
Proof that design reviews have a role to play
A hundred anomalies could give the impression that something was wrong with the product development process that NOVO put in place. It’s just the opposite!
Above all, it shows that it gives our designers the peace of mind to push boundaries and take risks, while still being agile enough to do so without jeopardizing the final product, budget, or schedule.
As proof, despite the BJ Nimo DragonVision project’s complexity and tight schedule, the first version of the prototype was fully functional — thanks in large part to the design reviews.