Poka-Yoke in UI design

May 10, 2010

As I mentioned before forgiveness is very important principle in UI design. But error prevention is even more important – whenever possible try to prevent an error instead of recovering from it. Preventing an error to happen is known as Poka-Yoke principle. The first time I heard of it was in the book Designing for Interaction by Dan Saffer, but it is just another term for “fail-safe”.

The purpose of Poka-Yoke is, according to Wikipedia “to eliminate product defects by preventing, correcting, or drawing attention to human errors as they occur. The concept was formalized, and the term adopted, by Shigeo Shingo as part of the Toyota Production System. It was originally described as baka-yoke, but as this means “fool-proofing” (or “idiot-proofing”) the name was changed to the milder poka-yoke.”

If you search for Poka-Yoke you will find some nice examples such as 3.5″ floppy disks, where the shape of disks prevents people from inserting them improperly. But Poka-Yoke can be used in user interface design as well. Applying it to UI design means to prevent an error using constraints and correction, and to warn/inform users about the reasons for prevention.

Prevent actions and disable elements

Naturally, forms are ideal for applying Poka-Yoke. Its most obvious usage is preventing an action to begin until all of the conditions necessary to perform that action are met. For instance, don’t allow form submission until all required fields are filled in. Disable submit button if input field is empty. Disable Delete all link if less than two items in the list are selected. Examples are numerous.

I’d recommend you to read (a bit old but good) discussion on ixda.org Hiding and Disabling Menu Items.

Restrict user’s input

You can restrict user’s input in many ways – allow only numeric characters, disallow special characters, limit user’s input to a specific range or limit the size of user’s input. This is usually done by rejecting user’s input if invalid characters are detected. You should always make clear to the user why rejection happened (e.g. “You can enter only numbers”). Plugins like alphanumeric can be a good choice here.

Mask user’s input

Similar to previous technique, masking forces users to enter information in a specific format. It is a good practice to reveal mask in input field upfront and make it clear to the user which format is allowed. The problem with masking is that help text is not always clear enough – would users know what “~9.99 ~9,999.99” means? In case when masking pattern is not easily understandable, it is better to show users an example of usage.

Correct user’s input

In some cases, the application will be able to correct the user’s input automatically without interrupting her/him. For instance, the application can automatically add “http://” to an URL if user omitted it. Another example is when user enters a value that is larger than maximum allowed. In this case the application can replace the user’s input with maximum allowed value while letting the user accept it or change to another value.

Other helpful techniques

Use defaults

In some cases defaults can help further in error prevention. If user wants to book a flight and have to choose a number of passengers, you can set 1 as default (instead of leaving this field empty which will trigger validation later). Another good example I can think of is my android-based mobile phone. Each time user starts a new SMS message, upper-case button is turned on. When user types the first letter it turns off.

Use appropriate controls

Another good way to provide fail safe is to use specialized controls. Instead of using input fields for dates, use date picker controls and disable associated input fields.

Conclusion

Those were just some of the examples of how to apply Poka-Yoke in user interface design. The important thing to remember is that whenever an error is detected, make sure you provide a clear explanation of why the process is stopped.

I discuss these topics on twitter too. In case you feel nostalgic, my RSS feed is still working.

7 Comments

  • cPT.cAPSLOCK (May 10, 2010)

    Another useful article, thanks :)

    While some of the things you mention in the article are self-explanatory (like [i]’preventing an action to begin until all of the conditions necessary to perform that action are met'[/i] ), they’re easily forgotten.
    Reading about them refreshes one’s mind, and makes him remember it next time (or for his current project).

    Altogether it surely was worth reading, keep them coming!

  • Janko (May 10, 2010)

    Thanks! Btw, I like your nickname :)

  • Jireck (May 11, 2010)

    Thanks for your article, I learn lot about design.
    I’m "[i]only[/i]" developper.

  • Robert Greathouse (May 11, 2010)

    It can be frustrating when a submit button is disabled. How is the user supposed to know what actions cause the submit button to become enabled?

    (from DZone: http://css.dzone.com/news/poka-yoke-ui-design)

  • Janko (May 11, 2010)

    That is a good question, Robert. UI has to be designed in such way that it is obvious what should be done – for instance to provide a help which says that all fields must be filled in in order to proceed. Or to provide a help tooltip that will pop up when user hovers disabled button (or other element).

    These are just some of the possible ways, but it depends on the specific cases, users, etc…

    You might find a discussion I provided at the beginning of the article useful http://www.ixda.org/node/17364

  • Kevin (May 12, 2010)

    The more defaults, the less chance for user errors I think. When you leave room for manipulation, you leave room for human error. Also disabling more elements probably speeds up production time as well. Kinda hitting two birds with one stone by preventing errors as well as streamlining things. No wonder this was come up with on an assembly line, pretty forward thinking.

  • abraxas (May 31, 2010)

    At first I thought this article would be about adding a Polka soundtrack to a website via midi. Thank goodness it wasn’t. I think, maybe, Toyota has forgotten about this principle.