Integrating HFE from Day One of development may seem counter-intuitive. The iterative testing process HFE calls for can be frustratingly non-linear, and may appear expensive. But the alternative – taking a product all the way to pre-market testing before identifying potential user error – is much riskier. At that point, when testing reveals use-based safety concerns, you'll be forced to choose between a costly redesign or a hasty, less-than-effective retrofit. The further along in development your product goes before HFE integration, the riskier and more expensive neglecting it becomes.
Broadly speaking, HFE aims at reducing hazard risks arising from user error during normal use of your product. Successful HFE integration forces your whole development team to stay focused on users, use environments, and user interfaces throughout product lifecycle. HFE recognizes that a well-designed user interface (UI) not only encourages correct use of your product, but also discourages incorrect (and potentially hazardous) use errors.
 |
| Image Credit: FDA |
(The FDA defines UI for medical devices as all elements of the device that a user interacts with – sees, hears, or touches).
It should come as no surprise that modifying product design is more effective at combating user-error hazards than training or labeling. Training is subject to “knowledge decay” – we forget training with time – and we don't necessarily have or take the time to locate and read instructions, especially in urgent medical situations. Users interact with devices primarily on intuition and expectation, biases and instincts which are reactions to product design and influenced by previous interactions with similar products. We've got to anticipate these and keep them constantly in mind in order to “design out” user error.
In general, the FDA believes that user-based medical device safety should be prioritized like this:
- Safety Through Design
- Protective and Preventative Measures
- Safety Information and Training
One of the biggest challenges we face in design is the expectation of simple interfacing. I once heard a microwave repairman claim that they should put only "+30 second" buttons on microwaves instead of all the other numbers because that's the one that malfunctions from overuse.
Increasingly, medical devices are being controlled through smartphone apps, which puts pressure on UI designs to imitate their mass-market counterparts. Users are now driven by a wide range of high-quality experiences and demand increasingly intuitive interfaces. For example, I know a woman who is afraid to use her neural stimulator – even though it was, in theory, designed with users like her in mind – because she doesn’t feel that she can accurately predict the results of manipulating the controls herself.
UI simplicity also introduces new challenges. My 10-year- old son can download and operate nearly any smartphone app, but I don’t want to risk him manipulating medical device apps when he borrows my phone. On the other end of the spectrum are medical devices which must perform tasks at an irreducible level of complexity. In some cases, their controls must be equally complex: simple interfacing may not be achievable in every instance. User permission levels can help us navigate these challenges, and should be integrated into the HFE design process from the beginning as well.
Predicting how users will interact with a new device isn't easy, but there are a number of methods and best-practices available for HFE integration at various early stages of development that can save time, costs, and headaches later.
In our next post, we'll look at each of those safety priorities - Safety Through Design, Protective & Preventative Measures, and Safety Information & Training - in more detail.
Then, we'll jump ahead to preview the end of the process: proving the high quality of your HFE to the FDA through Human Factors Validation Testing.