What could possibly go wrong? Placing two springs in a dish prior to assembly not only adds a handling step, but it neither physically prevents a mistake, nor immediately detects it once made. A new operator, or one who fills in for another who has the flu, is likely to skip this step, particularly if necessary to sustain the pace.

This example not like any Poka-Yoke I am used to, like the slots in my printer that are shaped so that an ink cartridge of the wrong color won’t go in, or the food processor that is started by pressing on the lid. These devices actually make mistakes impossible without adding any work, so that there is no incentive to bypass them.

And it’s not difficult to imagine methods that might have worked with the switches. For example, the springs, presumably prop the buttons up, and a whisker hanging over the assembly line might be triggered only if the switch is tall enough…

This article made me wonder whether Shingo, the inventor of the Poka-Yoke concept, had actually come up with this dish idea. It is indeed on p. 44 of his book, “Zero Quality Control: Source Inspection and the Poka-Yoke System,” and he does call it a Poka-Yoke, even though he didn’t coin the term until two years later.

It is the only example I remember seeing in the Poka-Yoke literature that does not meet the requirements of being 100% effective and not adding labor.

Devices and methods that make errors less likely are useful too, but not mistake-proof. It is usability enginering. If you make operations easy to understand with intuitive, self-explanatory user interfaces, mistakes may be so rare that you don’t need mistake-proofing. It’s fine, but it’s not mistake-proofing.