La Ley de Tesler, también conocida como Ley de Conservación de la Complejidad, ha sido durante décadas una guía fundamental en el diseño de interfaces de usuario. En 1985, Larry Tesler, reconocido científico de la computación, planteó esta ley que establece que cada sistema tiene un nivel de complejidad intrínseca que no puede ser reducido más allá de cierto punto.
Nuestro trabajo como diseñadores, o ingenieros, es pensar en cómo hacer que los usuarios no pierdan el tiempo utilizando nuestra aplicación. Para ello, dice Tesler, hay que encontrar el mínimo de complejidad del sistema. Si habéis estudiado ciencias y os acordáis de Descartes, él lo enuncia de otra forma en el segundo punto de su método: «Dividir cada una de las dificultades en tantas partes como fuera posible y como requiriese para resolverlas mejor». Es a estas partes atómicas e indivisibles a las que se refiere Tesler. Una vez que nos hemos asegurado que algo ya no se puede dividir más lo único que podemos hacer es pasar a otra tarea, pues seguir dándole vueltas a la que estamos no nos va a conducir a nada.
Cuando lo hayamos logrado habrá usuarios que intenten complejizar el sistema, esto lo estudió Bruce Tognazzini. Buscarán la manera de hacer tareas más complejas, queda en nuestra mano el darles la posibilidad o no. Quizá tengamos que añadir una opción de «avanzado» o preferíamos que esa funcionalidad quede limitada.
Pero es con ejemplos reales como mejor se ven las cosas. y se ve perfecto cuando queremos comprar un billete de avión. Podemos complejizarlo todo lo que que queramos. Pedir miles de datos para la búsqueda, pero si hacemos justo lo contrario llegamos a la conclusión de que siempre necesitaremos: origen, destino, fecha y cantidad de pasajeros. Estos elementos son inmutables y garantizan la funcionalidad mínima del proceso de reserva. Podemos quitar alguno de estos datos? en un primer paso quizá, pero es seguro que antes o después necesitaremos saberlos.
En este formulario de Iberia podemos ver los cuatro campos imprescindibles y alguna opción extra como pagar con Avios, o Ida y Vuelta.
Por contra en este formulario de KLM solo se nos piden dos datos: Salida y Llegada… hasta que los metemos y pulsamos enter.
En cuanto avanzamos podemos ver cómo se nos piden los cuatro campos imprescindibles y alguno extra.
La conclusión es que siempre debemos buscar la simplificación de los elementos y funcionalidades, pero sin perder de vista debemos ser conscientes de que hay ciertas funcionalidades indispensables que debemos mantener para garantizar la funcionalidad de nuestro producto o servicio. El equilibrio entre la reducción de la complejidad y la satisfacción del usuario es clave para lograr interfaces de usuario efectivas y atractivas.