Janko is UI designer, software engineer, blogger, speaker and artist. Janko has posted 20 posts at DZone. You can read more from them at their website. View Full User Profile

Poka-Yoke in UI design

05.11.2010
| 11790 views |
  • submit to reddit
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.

References
Published at DZone with permission of its author, Janko Jovanovic. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Robert Greathouse replied on Tue, 2010/05/11 - 8:20am

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?

Richard Kennard replied on Wed, 2010/05/12 - 12:37am

I strongly agree. Unfortunately I believe we have some way to go before achieving this, as I have written about here.

Davy Meers replied on Fri, 2010/05/14 - 6:06pm in response to: Robert Greathouse

It isn't a "one knife fits all", but by notifying the user immediately when he did some action that disables the submit button, and by giving a sum-up of the reasons why the submit button is disabeld nearby the button, you can eliminate that frustration.

Michael Eric replied on Wed, 2012/09/26 - 3:53pm

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.

redhat 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.