Con solo tocar una vez la pantalla, la cámara del teléfono inteligente ajusta automáticamente el enfoque y el brillo. Antes, quien tomaba la foto tenía que calcular por su cuenta la apertura del diafragma y la velocidad de obturación, pero hoy la máquina hace esos cálculos. ¿De verdad ha desaparecido entonces la complejidad de tomar una foto? El principio que responde a esta pregunta diciendo que «la complejidad no desaparece, solo cambia de lugar» es la ley de Tesler (Tesler's Law of Conservation of Complexity).
En pocas palabras, la ley de Tesler sostiene que «todo sistema tiene una complejidad que no se puede reducir más, y lo que queda por decidir es quién la asume». El científico informático Larry Tesler, que perfeccionó interfaces de usuario en el Centro de Investigación de Palo Alto de Xerox (Xerox PARC) y en Apple, formuló este principio, conocido también como «ley de conservación de la complejidad».
En este artículo veremos, por orden, cómo surgió la ley de Tesler, quiénes son los tres actores que se reparten la complejidad, algunos ejemplos cotidianos y los principios y límites de su aplicación al diseño.
La ley de Tesler y el diseño que decide dónde recae la complejidad
¿Qué es la ley de Tesler?
En el Centro de Investigación de Palo Alto de Xerox, Larry Tesler investigó formas de edición sin modos (modeless), en las que el usuario no quedaba atrapado en un modo específico. En 1980 se incorporó a Apple y participó en el desarrollo de la interfaz de usuario del ordenador Lisa. También es conocido por haber popularizado las operaciones de cortar, copiar y pegar que hoy usa todo el mundo.
En un texto retrospectivo, Tesler contó que, ante la objeción de que almacenar temporalmente el contenido cortado aumentaría la carga de desarrollo, defendió que «es preferible que la carga recaiga en el desarrollador antes que en el usuario». Después afinó ese argumento y, hacia 1984, lo formuló así.
«Toda aplicación tiene una complejidad inherente que ya no se puede reducir. Solo queda una pregunta. ¿Quién se ocupará de ella, el usuario, el desarrollador de la aplicación o el desarrollador de la plataforma?»
La palabra «conservación» (Conservation) en el nombre de la ley responde a la misma idea. Al igual que la energía, que solo cambia de forma y no desaparece, la complejidad puede ocultarse en la interfaz, pero no eliminarse. También se conoce como «teoría de la cama de agua» (Waterbed Theory), porque al presionar un lado de una cama de agua, el otro se abulta.
Los tres actores que se reparten la complejidad
Según la formulación de Tesler, la complejidad irreducible acaba recayendo en alguno de los tres actores siguientes.
- Usuario (User). El propio usuario tiene que elegir la configuración, memorizar el orden de los pasos y corregir los errores.
- Desarrollador de aplicaciones (Application Developer). Quien crea el producto dedica más esfuerzo a resolver el problema y escribe más código para reducir el trabajo del usuario.
- Desarrollador de plataformas (Platform Developer). El sistema operativo o las herramientas de desarrollo incorporan de antemano funciones comunes, de modo que varios productos se reparten la misma carga.
De estas opciones, la que más preocupaba a Tesler era trasladar la carga al usuario. En una entrevista publicada en el libro del diseñador Dan Saffer, señaló que, si un millón de usuarios pierden cada uno 1 minuto al día por una complejidad que un ingeniero podría eliminar con solo una semana más de trabajo, eso equivale a castigar a los usuarios para ahorrarle trabajo al ingeniero.
El enfoque de esta ley difiere del de la ley de Hick (Hick's Law), según la cual cuantas más opciones hay, más se tarda en decidir, y del de la ley de Fitts (Fitts's Law), según la cual cuanto más lejos está un objetivo y más pequeño es, más cuesta pulsarlo. Las dos leyes ofrecen un marco para medir el tiempo que emplea el usuario, mientras que la ley de Tesler aborda la cuestión de quién debe asumir la complejidad.
Ejemplos sencillos para entender cómo se desplaza la complejidad
Es fácil ver cómo se desplaza la complejidad en los servicios que usamos a diario.
(1) Cuadro de búsqueda
El usuario solo escribe unas pocas letras, pero en segundo plano el sistema realiza cálculos para corregir errores tipográficos, sugerir términos de búsqueda y ordenar los resultados. Así, el sistema asume el esfuerzo de dar con los términos de búsqueda precisos.
(2) Introducción de una dirección
Una interfaz que completa el resto de la dirección con solo introducir el código postal o unas pocas letras del nombre de la vía es el resultado de trasladar a los datos y al desarrollo la carga de escribir correctamente una dirección larga.
(3) Automóviles e indicaciones de ruta
Donald Norman explicó en su libro «Living with Complexity», publicado en 2010, que los sistemas informáticos de los automóviles se vuelven más complejos cada año y que, gracias a esa complejidad oculta, conducir resulta más sencillo y seguro. El cálculo de la mejor ruta también ha pasado del conductor al sistema de navegación.
En los tres ejemplos, el trabajo del usuario se aligera y, en la misma medida, aumentan las exigencias de diseño y cálculo para quienes crean el producto. La cantidad total de complejidad se mantiene y solo cambia quién soporta la carga.
Aplicación y límites en el diseño
Para aplicar la ley de Tesler al diseño, primero hay que identificar dónde está la complejidad irreducible de la tarea. Después, conviene dejar en manos del usuario solo las decisiones que necesariamente debe tomar y hacer que el sistema se encargue del resto mediante valores predeterminados, autocompletado e instrucciones paso a paso. En lugar de dar por hecho que un usuario ideal actuará siempre de forma racional, es más eficaz mostrar una ayuda breve en el punto exacto en que un usuario real se atasca.
Sin embargo, ocultar toda la complejidad tampoco resuelve el problema. Si se oculta demasiado, el usuario pierde la posibilidad de hacer ajustes a su gusto. Por eso conviene ofrecer, por ejemplo, instrucciones paso a paso a quienes usan el producto por primera vez y opciones avanzadas a quienes ya están familiarizados con él. El diseñador de interfaces Bruce Tognazzini también sostenía que la gente no acepta sin más que su vida se vuelva menos compleja. Según él, cuando un programa se vuelve más fácil de usar, los usuarios se atreven con tareas proporcionalmente más complejas.
La ley de Tesler nos recuerda que una interfaz parece sencilla porque alguien se ha hecho cargo de su complejidad, que sigue presente. Por eso, un buen diseño puede evaluarse más por dónde sitúa la complejidad que por cuánto la reduce.
El primer paso para diseñar pensando en el usuario es que quien crea el producto asuma de entrada la carga que de otro modo recaería en quien lo usa.
