Jun 21 2014
Poka-Yoke in User Interface Design | Six Revisions
“Poka-yoke is a Japanese term that means “mistake-proofing”. It surfaced in the 1960s, and was first applied in the car manufacturing industry. Poka-yoke is credited to industrial engineer Shigeo Shingo.”
Source: sixrevisions.com
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.
I surrendered, and confessed that I didn’t have a clue what he was talking about with clouds, crocodiles, pots of gold, UDEs, DEs, and Ds, and asked for help. The first response I received was from Henry Fitzhugh Camp:
It didn’t help much, but then, fortunately, he added:
He included a link to a video about Goldratt’s change matrix. Others also directed me to webinars, and debated whether there was rich knowledge embedded in the jargon, which prompted me to respond that yes, sometimes, technical terms do embed rich knowledge, for example in math or biochemistry. Often, however, the primary purpose of jargon is to exclude the uninitiated.
Some like to learn from webinars and videos. I don’t mind them for cooking recipes, but I find them an excruciatingly slow way to learn vocabulary. Clouds, crocodiles, pots of gold, UDEs, DEs, crutches and mermaids should be explained each in 25 words or less.
Lisa Scheinkopf then came to my rescue with explanations for at least some of these terms, which I summarized as follows:
As metaphors, Pot 0f Gold and Alligators are OK, but Crutches and Mermaids make no sense. A crutch is a device that helps you, not a risk. And I can’t see what mermaids have to do with the benefits of the status quo. In many cultures, mermaids, or sirens, lure sailors to their deaths. That is not much of a benefit. In others, they fall in love with human males, which makes you wonder what kind of “mermaids” a woman employee would have.
These terms are all about what you have to do to convince members of an organization to embrace a change you are recommending or have been tasked with implementing. In my experience, words are ineffective. To drive change, I have usually focused on finding protagonists rather than persuading antagonists.
Among the first-line managers in a manufacturing plant, for example, you usually encounter about 30% of antagonists who, for whatever reasons, oppose what you are recommending, about 50% of fence-sitters who are waiting to see which way the wind blows, and 20% of protagonists, who see an opportunity and want to take it. You work with the protagonists to get pilot projects done.
Their success then wins over the fence sitters and, together, the original protagonists and the converted fence sitters overcome the objections of the antagonists. Of course, this approach requires you to take human issues into consideration when selecting projects. You may select a smaller pot of gold because the manager in charge is ready to go for it.
And I still don’t know what Kelvyn meant with his “clouds.”