Ask Aza: Mistake Proofing
Question
A simple and effective concept from Toyota is Poka-yoke, or mistake-proofing. Products and Interfaces are context-sensitive — that is, products and interface features have a particular purpose , but I’m curious if you can share any generic context-agnostic approaches to mistake-proofing, or Poka-Yoke? Principles of Poka-yoke you can apply to anything; to any product or interface?
Answer
An interface is humane if it is responsive to human needs and considerate of human frailties. We make mistakes. No matter how hard we try to concentrate and prevent errors, errors will happen when our concentration wanes or when we are forced to do something that is beyond our cognitive abilities like multi-tasking: the act of consciously thinking about two things at once — and, with the use of Queueing Theory & Little’s Law, we learn that multi-tasking leads to lower productivity.
Poka-Yoke is an excellent method of making a process more efficient and humane by being considerate of human frailties: we won’t always be thinking about which way a part fits in, so design the part in a antisymmetric way so that it can only be installed correctly.
Shigeo Shingo, the originator of poke-yoke, wrote “Defects arise because errors are made; the two have a cause-and-effect relationship…yet errors will not turn into defects if feedback and action take place at the error stage”. In other words, users make mistakes, but those mistakes are detrimental only if they aren’t corrected immediately. One context-agnostic principle of humane interface design is summed up in the mantra “Never Use a Warning When You Mean Undo“. If you make a mistake, no big deal. Just undo it.
For example, a common Poka-Yoke style method is to cover an important switch so that it cannot be bumped accidentally. But, what happens if you use that switch all the time? You’ll either leave the cover open or flick-the-cover-open-and-flip-the-switch as a single gesture. In the computer world, we often have the advantage over the real-world in being able to undo. So that even though you just ran the smash-the-car-into-the-wall safety test while the technician was inside, you can just go back to the way it was before.
If Poka-Yoke was practiced more in interface design our lives on the computer would be a lot less stressful.
RT @azaaza Ask Aza: Mistake Proofing | Follow @azaaza on Twitter | All blog posts
David Humphrey
I can’t find the exact study now, but this is pretty close:
http://www.npr.org/templates/story/story.php?storyId=91945517
The idea was to look at how applying aviation’s use of checklists, and call-response from pilot to co-pilot, could be used to deal with human error. The particular study I’m thinking of related to a hospital trying it and reducing patient sickness due to error with a particular procedure to 0%. It was a shocking and amazing outcome.
Reading your post brought this back to mind. I wonder if the call-response model has any place in our apps? We don’t want to have all our actions mirrored back to us; but at the same time, when we make (what could be) a mistake, knowing that the undo is available would be good. I’m not sure the practical ramifications of mapping this onto software, but it’s interesting.
dave
I wonder what you’re opinion is on how this is reflected in the KDE vs Gnome wars. The KDE side are trying to empower a commited and vigilant prosumer who is fully engaged with their task while Gnome is trying guide users towards the best path without overwhelming them with choice and helping them avoid shooting themselves in the foot.
Or less charitably, the KDE interface looks like the car that Homer Simpson designed with every single gadget and option crammed in willy-nilly, ready to explode at the press of the wrong button. And Gnome is a bunch of fascists who have nothing but contempt for their imbicile users and will slowly remove every single feature until there is nothing left for them to get wrong.
Is there an objectively measurable third-way?
Kevin Warden
Although I like, and agree with your point, there has to be some sort of bypass to allow for someone to purposely use something incorrectly. Closed source software forces you to use things for the developer’s intended purpose. Think Internet Explorer. Now think Firefox. If I want to use a browser for something other than the developer’s intended purpose of web-browsing (testing a site, improving a built-in feature, etc.), then I have to use Firefox as IE won’t let me purposely break something.
Jason Yip
6 levels of mistake proofing:
1. Eliminate the step
2. Replace with something more reliable
3. Prevent by design
4. Facilitate to make steps easier
5. Detect errors quickly
6. Mitigate to minimise effects