Poke-yoke

When you’re not wrong, you’re all right.

A poke-yoke is any mechanism in a process that helps an equipment operator avoid (/yokeru/) mistakes (/poka/) and defects by preventing, correcting, or drawing attention to human errors as they occur.

Shingeo Shingo introduced the poke-yoke technique in the 1960’s to help modernize Toyota’s manufacturing processes. He saw that by avoiding pitfalls the chances of failure while completing tasks could be significantly lessened or removed. The first step is requires us to step outside of our comfort zone:

A relentless barrage of ‘why’s’ is the best way to prepare your mind to pierce the clouded veil of thinking caused by the status quo. Use it often.

As a designer and strategist, a lot of my job is asking why.

Using a poke-yoke lens helps uncover new ways to help people. Task completion gets simpler, and there is less friction in reaching in reaching goals.

Recently, I was working with my team to update a form. We were moving to a new design system and had to the chance review the form’s error states. Great, but what if we could reduce the chances of people making errors in the first place? Could a different approach create an environment where mistakes couldn’t happen?

We learned people were confused by some elements being disabled and unelectable. Because of this, they weren’t sure how to complete the form and continue with their task. We looked the usual options, adding help text, info link with tool tips, etc.

Then we stopped and asked why.

Why are there unselectable options in the form? We discovered those options need other criteria from outside our form. We made a bet. (How might we change this environment so that mistake can’t happen.) We moved them from the form, and instead provided links to complete the steps that would enable the option.

We benefitted in a few ways from this change:

  1. Users were able to understand what they could do
  2. Users were able to make the necessary changes to enable other options
  3. Our form was more accessible by removing disabled states
  4. Code complexity was reduced by reducing possible errors

The process of pausing and reframing is a step I’m implementing with my team. I’m excited to see how this method will help us reduce friction for our users and help them get things done.