Mistake-Proofing

That IT specialists should be interested in the Poka-Yoke concept is natural. There are, however, consequential inaccuracies In the way it is described in many English-language sources, including Wikipedia.

The example given as the first Poka-Yoke is a redesign of a switch assembly process that involved presenting springs on a placeholders so that the operator would not forget to insert one.

Assuming this is a true example, it has two characteristics that make it different from the other examples given in Shingo’s book or in Productivity Press’s big red book of Poka-Yoke.

First, having a placeholder does not physically prevent the operator from making a mistake. A classical example of a system that does is one that puts a lid on every bin except the one the operator needs to pick from.

Second, this example adds labor to the operation, which means that the preparation step of placing the springs in the placeholder is likely to be by-passed under pressure. This is why it is a requirement for a Poka-Yoke not to add labor to the process.

For the same reasons, a multi-step deletion process in a software interface does not qualify as a Poka-Yoke. If you do multiple deletes, you end up pressing the buttons in rapid succession, occasionally deleting items you didn’t intend to, while cursing the inconvenience of these multiple steps.

Having different, incompatible plugs certainly made it impossible to plug the keyboard into a port for an external disk. USB, however, was an improvement over this, because, with it, the machine figures out the purpose of the connection. A connector that you can insert in any orientation is even better. It saves you time, and there is no wrong way to plug it in. This is a genuine Poka-Yoke.

There are other, useful approaches that make mistakes less likely without preventing them outright. Don Norman and Jacob Nielsen call them “usability engineering.” They should certainly be used in user interface design, but not confused with Poka-Yoke.

With its unsightly bumps and nooks, the “fancy cup” you show is not even pretty, which makes you wonder what the designer had in mind. The issues you bring up, however, are more about usability engineering in Don Norman’s sense, than Poka-Yoke.

A properly designed handle is self-explanatory in that any user who has never seen a cup will immediately understand what it is for. But it doesn’t make the cup mistake-proof: there is nothing physically preventing you from pouring coffee onto it while it is upside down.

Usability engineering is about controls that look and feel distinctive to the touch — as opposed to rows of identical buttons — that give you feedback when you have activated them, that have shapes that naturally lead you to use them properly, that respect cultural constraints in the meaning of shapes and colors, etc.

Applying these principles in designing human interfaces reduces training costs and the risk of errors. It is valuable, but it does not prevent errors.

Incidentally, why do so many cultures, including Japan and China, use cups with no handles? An alternative to handles to avoid burning your fingers is the double-walled cup, and I have seen some from China. Otherwise, I have resorted to the Arab way of holding a handleless tea cup: between my thumb on the bottom and my index finger on the rim.