The "Paretism", illustrated There are people who knows a little about many things. Different things. There are other people that focuses on something and just knowing a lot of that something. We're great lovers of the percentages, and if someone asked us what is the distribution of these two groups of people, we wouldn't hesitate a second to say 80% - 20%.

There are people who knows a little about many things. Different things. There are other  people that focuses on something and just knowing a lot of that something. We're great lovers of the percentages, and if someone asked us what is the distribution of these two groups of people, we wouldn't hesitate a second to say 80% - 20%.

The guilty for this quick answer is none other than Wilfredo Pareto. His longtime principle and the very broad range of cases that fall under its umbrella, have become this distribution one of the most widely used to represent different sets. From politic aspects to macroeconomic representations, through models of logistics, quality control or software engineering, will always be a "Pareto" distribution that models their behavior (in most cases, when the study applies seeking to obtain representations of high level).

Within the technology sector, there are many situations in which to apply this chameleonic law. Probably in software development is where most occasions has he resorted to it, applying it as "80% of the development effort (time and resources) produces 20% of the code, while the remaining 80% is produced as only 20% of effort", or in the area of ​​testing as "80% of the faults of software is generated by 20% of the code of the software, while the other 80% generates only 20% of failures".

 

The "admin / user" paradigm

However, the reading we wanted to do on this occasion has a different goal: the perception of the usefulness and usability that a customer has with respect to technology, be it a web, CRM software or hardware product type. There is a huge battle between advocates of efficiency (which I will call "admins") and effectiveness (which I will call "users"). Of course, ideally, any technology was 100% effective and 100% efficient, and we have no doubt there are cases that there is, but as they say, "the perfect is the enemy of the good." Or what is the same thing, "efficient is the enemy of effective". Do not ever lose sight that any product or service, in the end, is developed for someone to use it. Someone or something. A person, usually. And, just as when we make a recipe with no idea, what we seek is that the book or application shows the possible (effective) more clearly, when a user will make use of a technology in any of its expressions, you want it to be displayed in the "user" mode. Needless to say, in certain cases, it is imperative to implement solutions of "admin" type, but the proportion that should appear in one and the other responds, how could it be otherwise, relating to a 80% - 20%.

Develop efficiently is a commendable work, which not everyone can aspire, because solid skills and knowledge are necessary. Develop effectively is a task that requires "feeling", common sense and empathy. Of "feeling" understood as intuition from a series of usability guidelines that must be present at all times. Common sense for making usability as universal as possible and reach as many users ("user" and "admin" alike). And empathy to be able to develop a product or service that we should not just mere customers and developers worried because the number of calls to the database is optimal, in exchange for a registration process it is incomprehensible to the average user.

We believe that discussions about the "admin / user" paradigm will not end here. Long is the way and mixed the positions on this issue. We'll be back...