Hacker News Reader

Comment by rm445 | Hacker News Reader

Poka-yoke is a massively useful concept in the design of physical objects, and it should apply to design of software interfaces as well.

A key principle is making different things look different. In a mechanical assembly, often you see very different pins and fasteners doing similar jobs - but what may seem an oddity on the part of the designer is a godsend when assembling. I'm sure we've all puzzled over putting together household objects where you have several slightly-different lengths of the same screw. In software, consistency is incredibly important, so that users can expect behaviours and discover features, but there's still a case for making different things visibly different.

View on HN

Poka-yoke plays a big role in making my life easier. I implemented a bunch of them around the house, and in the garage. They're an excellent coping mechanism for people with ADHD, because they make it hard to do the wrong thing.

- I leave my backpack against the door to make sure I don't leave the house without it.

- I put coloured tape around the 10 mm spanner, and the 10 mm socket. The 12 mm socket is 2 sockets to the right.

- Every tool has a place. If a slot is empty, a tool is missing.

- When I disassemble something, I place all the screws down in order. When I put everything back together, I should always need the rightmost screw.

- I always do mise en place before cooking. If an ingredient is missing, I'll know before I start cooking.

I also try to implement them in the workplace. Errors can happen, but they shouldn't happen twice.

Even some code writing practices exist with the goal of "making the mistake impossible to be made". E.g. in C or C++ introducing the practice of writing the constant first in the conditionals:

    if ( 0 == x )

makes the mistake of accidentally writing assignment there impossible (0 = x would generate an error). However, my belief is that we should both demand and expect from the tools to have the "reasonable defaults" i.e. even if the

    if ( x = 0 )

is a valid code, the "reasonable default" of the compiler has to be at least a warning. But who says that the environment where the compiler is used has "reasonable defaults" itself? I've worked in some environment where it was really expected from every participant to "ignore the warnings" produced during the build process. Which just shows how hard it is in some environment to even start a culture of "making the errors less possible": "don't waste the time, we have other methods to detect the problems, just do how it is done here" etc.

Viewed from the higher level, it is always about human weaknesses, still, it's always harder to address such weaknesses present on the higher levels.

One of the human factors that makes makes touch screens in cars so dangerous.

Reply on news.ycombinator.com