What Comes First: Design Input Requirements or Prototype?

Okay, this is kind of a trick question. Actually, what should come first the the unmet clinical need. But once you’ve identified the unmet clinical need, what do you do next? Do you define the product’s design inputs? Or do you proceed to building some type of prototype?

I’ve taken both approaches. And I’ve often wondered which is best–which is correct.

I think I now know which approach makes the most sense. Build the prototype first.

Why? A prototype is so much better at communicating than words can ever be. Put a prototype in the hands of end-users, and they can tell you everything that is right about it. More importantly, they can tell you everything that is wrong too.

Capturing and documenting design input requirements becomes so much easier when end-users are able to conceptualize the product, especially if they can hold and manipulate it in their hands.

So go build the prototype. It doesn’t have to be perfect. It doesn’t have to be made using production materials or processes. It has to be good enough to communicate a solution to others.

Then take the information you learn with this prototype and document the design input requirements. And refine the prototype to learn more and more until you have the product design right.

It’s important, though, to not get too stuck in this cycle. It’s easy to do, especially for engineering types. Don’t try to make the perfect product with all the bells and whistles. Know when the product is good enough to address the unmet clinical needs and get it to the market as quickly as possible. Be sure you’ve proven its safety and efficacy, and of course be sure to document all of this along the way.

Speak Your Mind