There are three types of models: the implementation model, the user mental model and the representation model.

User mental model (users)

The mental model reflects the person's vision or perception when interacting with the product. In reality, it is a cognitive behavior developed to explain interactions so that it can understand (justify) the mechanics of the process. It is the way a person uses to understand a complex system without knowing in detail how that system is developed.

Implementation model (developers / engineers)

The implementation model is what reflects the development. In this model, it is necessary to understand the complexity of the features and it is developed with the same mechanics in mind. It is the model that engineers use, as it all involves a process of steps and tasks for the realization of the product (technical part).

The distinction between these two models is based on perception. While whoever develops a product has a perception of implementation, whoever uses it doesn't. It only has a perception of the actions it will take, regardless of its development being simple or complex.

Representation model (designers)

The representation model is the model that the product represents based on the designers' work. The closer this representational model is to the mental model, the easier the person will understand the product. Therefore, one of the most important tasks of the designer is to bring the representation model closer to the mental model.

Human beings tend to form mental models that are simpler than reality itself.

It is easier to see that an action will generate a certain reaction, than to understand in detail how this action was generated and the entire process that it involves.

The computer is a good example of this, as people interact through its interface, they're not aware of it really works, but in reality its entire process and mechanics can be explained in detail in physical terms, however, no user when using it regularly needs to know the amount of bits which are being processed at that time and how they are processed electronically.

What often happens is that the mathematical thinking used for development, in this specific case of programs (software), involves concepts such as Boolean logic that are later reflected in the interfaces, but the people who use it are mostly unaware of its meaning. This can create a cognitive dissonance that will translate into an inconsistency, because when the person uses the program, their mental model expects something different than what the program will execute.

User interfaces should be based on the mental model and not on the implementation model, thus eliminating complex interface tasks that allow a clearer cognitive perception of goals and how to achieve them.

“…user interfaces that are consistent with user’s mental models are vastly superior to those that are merely reflections of the implementation model. It is much easier to design software that reflects implementation model. From the developer’s perspective, it’s perfectly logical to provide a button for every function, a field for every data input, a page for every transaction step, and a dialog for every code module. But while this adequately reflects the infrastructure of engineering efforts, it does little to provide coherent mechanisms for a user to achieve his goals. In the end, what is produced alienates and confuses the user.”
Cooper & Reimann & Cronin

Tesler's Law

Larry Tesler developed a theory in which he argues that the complexity of a interaction/process system depends on who develops or uses it. Designers/engineers can only simplify up to a certain point. From that point onwards, complexity is on the user's side.
If the system needs to be more simplified then it implies that this complexity will be on the side of the designers/engineers again.

In other words, the more work designers/engineers do to solve complexity, less complex is the system when a person uses it.