It can be difficult to predict what paths a user might take while navigating your website. This often leads to frustration in trying to fix a bug that's a result of an unexpected user action. A way to prevent these frustrations is to create your software in such a way that that prevents the user from making errors, a concept known as "poka-yoke."

Poka-Yoke – Mistake Proofing

Poka-yoke (pronounced POH-kah YOH-kay) is a Japanese manufacturing concept invented by engineer Shigeo Shingo in the 1960's, which literally means "mistake proofing." Shingo originally went with a phrase that meant "idiot proofing," but scrapped this for the gentler version used today [1].

At Shingo's factory, a product required two springs, and occasionally workers would forget to include the springs. Shingo designed a poka-yoke device that required the factory workers to place the springs in a small bowl before doing anything else. Then, if the springs were still in the dish at the end of the process, it was known that the springs had been forgotten [2].

There are two major distinctions between poka-yoke devices: prevention and detection. The stronger form of a poka-yoke actually prevents the user from making the mistake. An example in software development would be a form that prevents submission if it's missing required fields. A weaker form of a poka-yoke is a system that detects that an error has occurred, and alerts the user that a mistake has been made, but does not actually prevent the user from making the mistake. An example of a detection poka-yoke might be a spellchecker – the spellchecker alerts the user that it believes a spelling mistake has occurred, but it does not prevent the user from submitting the misspelled word (maybe the blogger is actually writing about "poka-yoke," even though it's not an English word).

Poka-yoke is generally used in manufacturing processes [3], but the process is an excellent idea to incorporate in software development. Because the cost of fixing bugs in the operations phase can be up to 100 times more costly than fixing them in the development phase [4], it's crucial to try to incorporate poka-yoke designs in the development phase.

Poka-Yoke – Why Isn't It as Simple as the Hokey Pokey?

This all sounds great in theory, but before you get your dancing shoes on, remember that there are a number of real-world constraints that make this difficult to implement in reality.

Developers and testers can often make a crucial mistake that prevents the opportunity for poka-yoke devices – they make assumptions about how the users will behave. Specifically, developers and testers overestimate the likelihood that the user will follow the same thought process as them when using the software.

It can be difficult to estimate how users will actually try to use the system. I have seen bugs occur that could have been prevented by a poka-yoke, but the bugs were the result of actions that no one thought was even a possibility. For example, an outlier user entered 700 rows of data into a form that generally took no more than 20 rows. It was not a malicious attempt to overflow the system; it was just a use of the system that no one expected. Another example is a user that used quotes in the first name field (William "Bill" Lastname), which revealed a bug within Microsoft's Json serializer.

To combat this fallacy that the user will follow the same thought process as you, I recommend that you be careful about the assumptions you make about how the user will behave. If you find yourself thinking either "The user will be able to figure it out" or "The user would never do that", you should take a second thought before immediately discounting that scenario. If time and budget allow, performing Usability Testing with screen captures of how users are actually using the system can provide invaluable insights.

So while a poka-yoke may not be as simple as the hokey pokey, there's no need for it to be a full-on waltz, either. Take a second to try to think outside of your normal thought patterns, and try to imagine how someone who isn't you would use the system. After all, if you can easily create a poka-yoke device that prevents or deters users from making mistakes, your clients and users will be significantly happier with your product. And isn't that what IT consulting's all about?

Sources:

[1] http://blogs.hbr.org/2010/02/my-favorite-anecdote-about-des/

[2] http://faculty.washington.edu/apurva/502/Readings/Lean/pokasoft.pdf

[3] http://www.qmt.co.uk/training/quality/poka-yoke

[4] http://www.cs.umd.edu/projects/SoftEng/ESEG/papers/82.78.pdf