Practical Poka-Yoke

[Note: I’ve been away from the blog for several months now in the middle of very significant changes in my life. That’s about to change! In the next post, I’ll tell you about what happened and what my plans are for the future. In the meantime, I wanted to share something that happened to me today.]

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, I was really surprised by how long it was taking for my money to pop out.

Maybe there’s a problem with the connectivity? 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… so much so, that I was able to use an ATM machine entirely in the Icelandic language once.)

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 the money (I mean, that’s the specific thing I came to the ATM to get) so of course I’m going to do whatever is required to accomplish my goal. The machine was forcing me to take my card — preventing the mistake of me accidentally leaving my card in the machine — which could be problematic for both me and the bank.

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) described it like this:

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 cash was dispensed 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 is a long lag time between recording genius ideas and making them broadly available to help 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 got some findings that you think would benefit the entire quality community (or quality management systems or software), 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

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s