by Chris Myhill
Director of Experience
There are lots of funny sounding concepts that get thrown around in our industry.
For those just starting out in the world of tech, this secret language can be pretty confusing. For this reason we try to avoid talking about contemporary design principles where possible. In fact, avoiding jargon is one of our core values at Pixel Fridge.
Just this once though, we’re going to take a bit a mild exception… Because this one is interesting. We’re talking about ‘Poka-Yoke’. It’s the Japanese term for ‘error-proofing’, coined by Toyota engineer Shigeo Shingo.
This one gets a pass because it’s such an important ideal for good UX design… Also, it’s just so damn delightful to say.
When designing websites & apps, we can spend a lot of time planning for errors.
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 sure that error-causing actions are literally impossible.
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 Poka-Yoke in everyday products include :
A Poka-Yoke design is one that prevents errors from occurring in the first place.
When designing digital products, 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.
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 initial 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.
Instead of thinking about errors, can we design in a way to stop that error from happening in the first place?
Lots of websites and apps have account functionality. Many sites cause issues by separating the ‘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 are registered in the first place. Needless to say, all of these scenarios could result in some frustrating errors.
Instead, we could try providing a single field that asks the user to enter their email address.
After the email address has been entered, we 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!
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 :
…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.
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 product creators should be aware of.
13th September 2022
By using real content in the early stages of design, we can ensure the right messages are delivered at the right times.
21st June 2022
What does it mean to design for everyone?
7th June 2022
The internet is entering a new era for privacy and authentication. But what could this mean for the applications we create?