Establece que para cualquier sistema existe una cierta cantidad de complejidad que no se puede reducir.

Larry Tesler, mientras trabajaba para Xerox PARC a mediados de la década de 1980, se dio cuenta de que la forma en que los usuarios interactúan con las aplicaciones era tan importante como la propia aplicación.

Según Tesler, en la mayoría de los casos, un ingeniero debería dedicar una semana adicional a reducir la complejidad de una aplicación en lugar de hacer que millones de usuarios dediquen un minuto adicional a usar el programa debido a la complejidad adicional.

Según la leu de conservación de la complejidad, todos los procesos tienen un núcleo de complejidad que no se puede eliminar por diseño y, por lo tanto, debe ser asumido por el sistema o el usuario, se debe asegurar de que la mayor parte de la carga se elimine de los usuarios al lidiar con la complejidad inherente durante el diseño y el desarrollo y debes tener cuidado de no simplificar las interfaces hasta el punto de la abstracción.

Pongamos un ejemplo para entender mejor la Ley Tesler. Las aerolíneas siempre tienen un pequeño formulario para iniciar el proceso de compra de un billete. Habría muchas maneras de hacer complejo el sistema o de intentar simplificarlo, pero siempre habrá cuatro datos indispensables: origen, destino, cuándo y cuántos.

Ejemplos del proceso de reserva de Vueling, easyJet e Iberia

Conclusión

Siempre debes intentar simplificar todos los elementos y funcionalidades, pero también debes ser consciente que hay ciertas funcionalidades que son indispensables e inmutables. No debemos intentar modificar esos mínimos que nos garantizan la funcionalidad mínima de nuestro producto.

Referencia:
· Tesler’s Law
· Ley de Tesler | Leyes de UX

Compartir es construir