Practical Poka-Yoke

My Story

A couple hours ago, I went to the ATM machine.

I don’t use cash often, so I haven’t been to an ATM machine in several months. Regardless, I’m fully accustomed to the pattern: put card in, enter secret code, tell the machine what I want, get my money, take my card.

This time, my money was taking a looonnnnnnnngggg time to pop out.

Maybe there’s a problem with the connection? Maybe I should check back later? I sat in my car thinking about what the best plan of action would be… and then I decided to read the screen. (Who needs to read the screen? We all know what’s supposed to happen… right? Once, I was even able to use an ATM machine entirely in the Icelandic language just because I knew the pattern.)

PLEASE TAKE YOUR CARD TO DISPENSE FUNDS, it said.

This is one of the simplest and greatest examples of poka-yoke (or “mistake-proofing”) I’ve ever seen. I had to take my card out and put it away before I could get my money! I was highly motivated to get my money (I mean, that’s the specific thing I came to the ATM to get). Of course I’m going to do what you want, ATM! The machine forced me to take my card — and prevented me from accidentally leaving my card in the machine. This could be problematic for both me and the bank.

The History

Why have I never seen this before? Why don’t other ATMs do this? I went on an intellectual fishing expedition and found out that no, the idea is not new… Lockton et al. (2010) said:

A major opportunity for error with historic ATMs came from a user leaving his or her ATM card in the machine’s slot after the procedure of dispensing cash or other account activity was complete (Rogers et al., 1996, Rogers and Fisk, 1997). This was primarily because the [ATM dispensed the cash] before the card was returned (i.e. a different sequence for Plan 3 in the HTA of Fig. 3), leading to a postcompletion error—“errors such as leaving the original document behind in a photocopier… [or] forgetting to replace the gas cap after filling the tank” (Byrne and Bovair, 1997). Postcompletion error is an error of omission (Matthews et al., 2000); the user’s main goal (Plan 0 in Fig. 3) of getting cash was completed so the further “hanging postcompletion action” (Chung and Byrne, 2008) of retrieving the card was easily forgotten.

The obvious design solution was, as Chung and Byrne (2008) put it, “to place the hanging postcompletion action ‘on the critical path’ to reduce or eliminate [its] omission” and this is what the majority of current ATMs feature (Freed and Remington, 2000): an interlock forcing function (Norman, 1988) or control poka-yoke (Shingo, 1986), requiring the user to remove the card before the cash is dispensed. Zimmerman and Bridger (2000) found that a ‘card-returned-then-cash-dispensed’ ATM dialogue design was at least 22% more efficient (in withdrawal time) and resulted in 100% fewer lost cards (i.e. none) compared with a ‘cash-dispensed-then-card-returned’ dialogue design.

I don’t think the most compelling message here has anything to do with design or ATMs, but with the value of hidden gems tucked into research papers.  There can be a long lag time between generating genius ideas and making them useful to real people.

One of my goals over the next few years is to help as many of these nuggets get into the mainstream as possible. If you’ve learned something from research that would benefit quality or business, get in touch. I want to hear from you!

Reference

Lockton, D., Harrison, D., & Stanton, N. A. (2010). The Design with Intent Method: A design tool for influencing user behaviour. Applied ergonomics41(3), 382-392.

2 comments

  • My local supermarket accepts Chip and PIN credit cards and used not to print my receipt until I took my card out of the payment device. Now it prints my receipt as soon as my PIN is accepted.

    Since the programmer made this change I’ve forgotten my card twice and I have had to remind the customer before me in as she loaded her shopping into her car.

    It seems that the programmer overwrote this simple mistake-proofing routine.

    • Nicole Radziwill

      This is a fantastic (and terribly unfortunate) example of how mistake-proofing should be done with the whole process in mind! Unfortunately in many orgs the software engineers are just required to add features or fix bugs, and their hands are tied in many cases… even if they see the big picture.

      I would definitely forget my card if this happened to me!

Leave a Reply