68. There Is no such thing as human error

---

WHAT EXISTS IS A PROCESS that failed to anticipate where a person could do something incorrectly and to prevent it.

Thinking that mistakes can be human implies that the solution would be to replace the human. Until we meet another human who fails, and then another, and then another. All at the same point.

If one person made a mistake, another could make a mistake as well.

Correcting the process where people fail is the only way to scale.

Assuming that “human errors” exist leads to processes and tools becoming less and less resilient, requiring greater capacity from users and, consequently, restricting their framework for action.

You may be thinking, “I know people who make a difference. I know people who have extraordinary results in the same process where other people have mediocre results.” That’s true. However, it does not escape the rule that we propose at this point.

People can improve the process and can get above-average results, but we need to make sure that the tools and processes ensure a modicum of safety and results regardless of who operates it.

There are two concepts that I would like to introduce in order to further develop this idea.

Poka-yoke: Foolproof

Poka-yoke is a method introduced by the Toyota Production System (TPS) that aims to reduce inefficiencies and unintentional errors in processes.

This method aims to reduce the number of decisions a person must make to achieve satisfactory results in their task.

Put another way: “Poka-yoke allows us to build ‘foolproof’ interactions.”

Some examples:

• The outlet has only one way to be plugged in.
• The USB-C type connector, which can be connected either way and both are correct.
• The hole that some sinks have that prevent it from overflowing.
• Metal molders that require the operator to press two buttons simultaneously to ensure that the hands are not exposed to the press.
• The user interfaces of digital products that implement Inductive User Interfaces (IUI ), also known as Wizards or Wizards. Where the user is guided by a process where they make limited decisions and with a framework of contextual information to support the decision.
• The washing machine doesn’t work if the door hasn’t been locked.
• Pens with retractable tips, where it is impossible to lose the cap (because there is no cap).
• Elevator doors, which detect resistance and reopen to avoid injuring users.

In short, there is a method that allows us to reduce the number of user decisions, consequently reduce the potential to make mistakes and, in this way, not resign ourselves to thinking that the error can be human.

Tesler’s Law of Conservation of Complexity

Larry Tesler was a pioneer in the area of Human-Computer Interaction (HCI). He worked in the golden years of Xerox Parc and Apple. He is considered one of the founding fathers of formal User Experience (UX) Design.

Larry Tesler’s Law of Conservation of Complexity states:

It is not possible to reduce the complexity of a task beyond a certain point.

Once that point is reached, it is only possible to shift complexity from one place to another.

The only question is who will have to deal with this complexity.

Conclusions for software products:

The complexity that is not solved by the programmer will be absorbed by the user (as many users as the product has).

If the user cannot absorb it, it will fall back on a User Manual, Help Document or User Service Center (Technical Support, Call Center, etc.)

Last-mile decisions, of a programmer versus their piece of source code, determine the experience of many more users.

A programmer who is unaware of the impact of their decisions on the experience of these users exposes them to unnecessary complexity.

Answers to the following questions contribute to the success or failure of a product:

· How many users will be impacted by a given decision?

· Is the time of programmers to solve something more relevant or the time of all users dealing with that unsolved problem?

· What can be done to make the software able to absorb more complexity (User Interface, algorithm, server, infrastructure, etc.)?

It’s not always necessary to reduce the complexity absorbed by a piece of software to its bare minimum. However, it is mandatory to analyze the impact before reaching such a conclusion.

Every team member, especially management, should discuss the following equation before concluding that a feature has reached its full maturity. The components of this are:

• Total Cost of Operation of Functionality (CTf):
• Cost of Operation (Co): This is the intrinsic cost of operating the product. It is suggested to quantify in monetary cost.
• Number of users (Qu): This is the number of users exposed to that complexity.
• Frequency of use of the feature in question (Fu): The number of times per unit of time that the user is exposed to the feature.
• Probability of Error (Pe): This is the probability that the user will make the error.
• Cost of Errors (CE): This is the cost of recovering from the error. It could be the cost of issuing an invoice with errors and correcting it, of operating a metal press exposing the operator, or of the user not noticing that the email was not sent. It is suggested to quantify in monetary cost.

CTf = (Co * Qu * Fu) + (Qu * Fu * Pe * Ce)

The COST of the operation, and the probability of error can be approximated through Usability Testing or through obtaining empirical information about the use of the software (analytics, time trackers, etc.).

Let’s take an example:

• Operation:
  - Issue invoice.
• Error analyzed:
  - The user issues the invoice for the wrong reason.
• Cost of Operation (Co):
  - 3 minutes per invoice = US$ 6.- per invoice
• Number of users (Qu):
  - 100
• Frequency of use (Fu):
  - 20 times per day
• Probability of Error (Pe):
  - 0,05
• Cost of Error (CE):
  - US$ 6.- for each invoice + cost of noticing the error later in the process (we will estimate this second term at US$ 0.- so as not to add more complexity to the example. However, it can result in a high cost, depending on the point at which the error is noticed.)

CTf = (Co * Qu * Fu) + (Qu * Fu * Pe * Ce)

CTf = (US$6 * 100 * 20) + (100 * 20 * 0.05 * US$6)

CTf = (US$12,000) + (US$600)

CTf = (US$12,600/day)

These results allow us to draw several conclusions:

1. The daily cost of issuing invoices in this scenario is US$ 12,600 per day.

2. The cost of making mistakes in this scenario is US$ 600 per day (at a minimum, since we have not included in the analysis the cost of transferring the error to other parts of the process).

If the software is in operation, say, 5 years, exposing users to the same error, that’s a hidden cost of more than $700,000 over the life cycle of the software.

This same calculation can be used to estimate the ROI of a project that aims to eliminate error.

We can be extremely methodical and frequently update the results for the most frequent errors, although we can also estimate a value in our heads by investigating the variables described.

We have two options then:

a. Considering that users are stupid and that’s why they make mistakes and there isn’t much to do. We can change the user and solve the problem.

b. Consider that we must reduce complexity and expose users to fewer errors in order to achieve better results.

What do you choose?

The important thing to understand is that behind every mistake there is a hidden cost, and the possibility of eliminating it is usually in our hands.

It is vitally important to incorporate this way of looking at “human errors” into the culture. To find the frontier of our products and discover new perspectives on how we can expand them.