The foundation of any product development process is the design inputs or design requirements to build a product. This is especially true in the medical device industry. However, in order to get to the design inputs, it is necessary to have the user needs defined. The user needs arise out of the voice of the customer and represent the need of the user and the patient and the intended use of the device. The needs of the user are written in a manner that describes the problems that the customer or patient needs addressed rather than describe the product.
FDA 21CFR820.30 requires “a manufacturer to establish and maintain procedures to ensure that the design input requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient.” These requirements are written in a manner that describe the solution(s) to the problems or needs of the customer. Minimally, the design inputs describe the physical, functional, performance, interface, software, hardware, system, regulatory, and statutory requirements for the product. Furthermore, per design control procedures, manufacturers are required to verify that the design outputs meet the design inputs and validate that the product meets the user needs and the intended use.
It is critical that manufacturers clearly define what is a user need, what is a design input, and how the design inputs are traceable to the user needs. Yet, many product development teams are not always able to distinguish a user need from a design input. In fact, often one sees design outputs or specifications described and written into a user needs document. This creates a burden on the manufacturer to then demonstrate that they have not only verified the design inputs but also have their customers validate all the specifications written into user needs prior to regulatory approval. Having customers do unnecessary testing can be costly in terms of time and money to the manufacturer and the customer. One may also see design inputs written as user needs, which may result in building the wrong product and not realizing it till the validation stage, resulting in a significant and costly redesign.
So what is the product development team to do to make sure the user needs and design inputs are written appropriately. For user needs, the team should come up with a series of user stories based on the voice of the customer that describe who the user is, what the user wants to do, and why. The starting point of these stories should be the voice of the customer. Because there could be multiple problems that need to be addressed or multiple users the product touches, there may be a need for multiple user stories. The design inputs then describe the solutions in terms of product requirements that would address the problems the user is trying to solve in each of the user stories. The example below compares a user need versus a design input for an assay and hardware example:
Hardware Example for Instrument X
User Need: The customer (lab technician) wants to be able to operate the product on an average sized lab bench.
Design Input: Instrument X is less than 2 feet in length, 1 1/2 feet in width, and 1 feet high and weighs less than 40 pounds.
Assay Example for Analyte Y
User Need: The customer (test ordering clinician) wants the assay to produce precise and accurate results within the clinical measuring range.
Design Input: Assay Y shall have a maximum CV of 5% and be accurate within +/- 0.5 mg when the analyte concentration is between 5 and 100 mg.
Summing it up, it is important that product development teams develop a good understanding of the difference between user needs and design inputs. The team should keep in mind that the user needs are written in terms of a problem that the customer wants to solve and upon receiving the solution is able to validate that the right solution was built by the manufacturer. Whereas, the design inputs describe the solution or product that address the needs of the customer. The design inputs are written in a way the manufacturer can demonstrate that they are traceable to the user needs and that the final product specifications can be verified to meet these requirements. That is, the manufacturer built the product right.
Design Controls in a Waterfall Format