is it a yes, or is it a no?
Guess what I did at work today? I lubed up Foley catheters with baby oil and inserted them into an acrylic model of the prostatic curve.
Over, and over, and over.
I’ve gone through the design input process for half a dozen disparate medical devices - everything from vascular stabilization, to imaging, to interventional cardiology. Each device has addressed a very different unmet clinical need; each device, not surprisingly, has had a very different set of design inputs associated with it.
Except one (one input to rule them all, I guess). Every time I sit down in a design inputs meeting, without fail, someone says, “It’s got to be easy to use.”
This sentence is what keeps me up at night. At the end of the day, technology is easy to quantify. Science is easy to quantify. When a device I developed makes it to a patient, I know that the science behind it is sound, and the testing is robust.
We try our hardest to quantify procedure time, insertion force, stiction - but ease of use is not a particularly good engineering input. The only way to know if your device is easy to use is to use it. A lot. With a lot of different people. It means building it twenty times before you ever draw the final plans. It means testing, and it means failing your design objectives a hundred times before you figure out how to get it right.
And once you’ve done that, it means taking a leap of faith to decide that yes, this product is easy to use.
When you’re analyzing a situation, you eventually get to a point at which you ask yourself, ‘Is it a yes, or is it a no?’ And you just know the answer.
Ease of use is one of those things that one day, just clicks. So here’s how to get to that point (without losing as much sleep as I do, maybe):
1. Do your homework. Know what your design objectives are. Know who’s going to be using this. Know what they find easy.
2. Build. And build. And build some more. Your first prototypes will suck. The first device I ever designed was a cardiac ablation mesh that could map electric potentials across the pericardium, and then reverse the energy to ablate those areas we mapped as fibrillation points. We spent two months building ONE high-fidelity prototype. In retrospect, we could have doubled our understanding by building two prototypes that weren’t as intricate.
Somewhere, I have photos of the CardioMap build. But I prefer this picture of eating pig hearts after we used them for testing. Eat your heart out… ?
3. Fail. A lot. You don’t know what’s easy to use until you also know what’s not easy to use. So build things that aren’t easy to use and use them as comparison points.
My goal in my new job is to fail, quickly, cheaply, a lot, so that when we get out of Concept Phase and we hand our projects off to the commercialization team, we’ve gotten the product failures out of the way. So I get the pleasure of spending my Friday simulating insertion of a urinary catheter through torturous male anatomy (for you gentlemen who don’t have a background in healthcare, don’t Google this).
4. Make a decision, and move on. Once you’ve done your homework, and you’ve tried your ideas, you’ll know. Ease of use is one of those things that you “know it when you see it.” So stop overanalyzing. Do your homework, and then trust your gut. And get some sleep.