Human Factors & Use Error

Not every reported "device malfunction" is actually a device fault - a real, non-trivial fraction of service calls trace back to use error, often because the device's interface made the error easy to make. Human factors engineering exists as its own discipline specifically because interface design measurably changes how often operators make a given mistake, independent of training quality.

Investigating a reported fault

• Reproduce the reported steps exactly before concluding the device is at fault - the sequence of button presses matters, and a slightly different sequence than what the operator actually did will often produce a different, misleading result.
• If the same "fault" is reported repeatedly by different users on a correctly-functioning device, that's a usability/training signal, not a hardware one - route it to clinical education, not just a repeat repair ticket that will keep closing as "no fault found" without addressing why the reports keep coming.

True use error vs. use-error-prone design

Distinguish a true use error (device worked exactly as designed, the operator made a genuine mistake unrelated to the interface) from a use-error-prone design (device worked as designed, but the design itself invites the mistake - two visually-similar buttons with very different functions placed adjacent to each other, for example). The first is a training issue; the second is worth escalating to the manufacturer as a real design concern, because training alone won't reliably prevent a mistake the interface itself keeps inviting.

Why this distinction matters for the record

How a service event gets logged - "use error" vs. "device fault" vs. "design concern escalated to manufacturer" - feeds directly into the trending data described in Chapters 09 and 17. Mislabeling a design-driven pattern as a series of unrelated individual use errors hides the real signal that would otherwise justify escalation.