This amazing product design princible is something we should all aim for. Don’t respond to errors - prevent them!
There are are lots of funny sounding concepts that get thrown around in our industry.
For just starting in UX, this secret language can be pretty confusing. For this reason I try to avoid talking about contemporary design principles where possible.
There’s one that I take a bit of an exception to, though.
This one gets a pass because it’s such an important ideal for good UI design… and also because it’s just so damn delightful to say.
‘Poka-Yoke’ - The Japanese term for ‘error-proofing’, coined by Toyota engineer Shigeo Shingo.
What does it mean to be error-proof?
UX designers spend a lot of time planning for errors.
- We write error text for our forms.
- We style problem states, showing what happens when things break.
- We try to help users recover quickly when a process goes wrong.
This is all good practice, but it doesn’t prevent the initial frustration of the error itself.
A Poka-Yoke design is one that prevents the error occurring in the first place. It does this by making error-causing actions are literally impossible.
Poka-Yoke for product designers
Poka-Yoke originated on Toyota’s production lines, so naturally it’s a popular principle for product designers.
Every day people interact with Poka-Yoke designs, without thinking about it. And that’s the point. When a design is error-proof, no thought is required on the part of the user. There’s no possibility of them making a mistake — so they don’t need to think.
Examples of Poke-Yoke in everyday products include :
- A three-pronged plug. By avoiding symmetry, there’s only one way that that plug can go into the socket.
- A microwave that can only be switched on after the door has closed, and stops automatically when the door is opened.
- A bathtub with a sink plug at the near the top, so it can’t overflow.
Poka-Yoke for UX designers
As UX designers there’s so much we can learn from this way of thinking.
Deep-rooted computer science thinking has trained us to expect errors in digital products. Whilst computational errors are sometimes inevitable, they shouldn’t bleed into the user interface design.
Next time you’re designing an error state, think about how you could tweak the interaction to stop that error from happening in the first place.
Here are some examples of Poka-Yoke in UX design :
Selecting a product size before adding it to the basket
Think about an eCommerce site selling shoes. it’s necessary for the user to select their shoe size before adding it to the basket.
On many websites, the user might get an annoying error message if they hit the ‘add to basket’ button without first selecting a size.
Instead, we can error-proof this interaction by disabling the ‘add to basket’ button until after the size has been chosen.
To help draw the user’s attention to the size choice, the intital state of the ‘add to basket’ button could instead read ‘please select a size’. After selecting a size, the button then activates. We can use animation and styling to draw the user’s attention to the change.
Trying to create an account with an email that’s already registered
Lots of websites and apps have account functionality. Many sites cause issues by seperating their` ‘login’ and ‘register’ forms.
Users could accidentally find themselves trying to create an account when they meant to sign in, or visa versa. They could also forget whether they’re registered in the first place. Needless to say, all of these scenarios could result in some frustrating errors.
Instead, we could try providing single field that asks the user to enter their email address.
After the email address has been entered, we make a check our database to see if that email address has been registered. If it has, we show the login form. If it isn’t, we assume they’re a new user and allow them to register. Simple!
Catering for different input formats for a date field
Form usability can be a tricky beast. From a validation point of view, we need information to be entered into a database in a single, consistent format. The need for structured data has historically put an onus on the user to ‘get it right’.
For example, let’s say the user needs to enter their date of birth on a registration form. There are loads of possible formats that this could use to supply this.
Say my birthday was the 6th of August, 1989. This could be entered as :
- 06 August 1989
- 6th August 1989
…And so on.
A tooltip could suggest the required format, but it doesn’t stop them from getting it wrong. If the user tried to enter their birthday in a format we can’t use, we throw back an error. How rude!
Instead, we can put in a little extra effort to error-proof this interaction. Our ‘date of birth’ field could allow the user to enter it in any known format. By recognising different possible formats, we can then convert it behind the scenes into the format the database needs.
We can still provide a suggestion or example of a date format, but now it’s just to be helpful.
Stop preparing for errors. Start preventing them
Hopefully this has gotten you thinking more about error prevention, rather than just error recovery.
We still need to plan for edge cases, but errors are very often avoidable. Poka-Yoke is a fantastic attitude that all UX designers should be aware of.