Ley de Tesler: la complejidad que nadie puede eliminar
La ley de Tesler dice que todo sistema tiene una complejidad que no se elimina, solo se desplaza. Su origen, qué recomienda y cómo decidir quién carga con ella.
¿Qué dice y de dónde viene?
Laws of UX la formula así: para cualquier sistema existe cierta cantidad de complejidad que no puede reducirse. La Wikipedia en inglés va más allá: toda aplicación tiene una cantidad fija de complejidad que no puede eliminarse ni ocultarse, y hay que manejarla durante el desarrollo o a través de la interacción con el usuario.
El nombre viene de Larry Tesler, informático especializado en interacción persona-computadora. Según su página en la Wikipedia, se incorporó a Xerox PARC a comienzos de 1973, donde trabajó en Gypsy, un procesador de textos con interfaz gráfica para el Xerox Alto, y desarrolló con Tim Mott el cortar y pegar. También defendió las interfaces sin modos. En julio de 1980 pasó a Apple, donde trabajó en la Lisa. Laws of UX y la Wikipedia cuentan que Tesler formuló la idea en Xerox PARC, y la describe una entrevista incluida en Designing for Interaction de Dan Saffer. Esas dos fuentes fechan la formulación a mediados de los años ochenta, una fecha que no encaja con su salida de PARC en 1980, así que conviene decir solo que surgió de su trabajo en Xerox PARC y Apple, sin fijar un año. La Wikipedia añade que también se la llama Waterbed Theory y la describe como un adagio de la interacción persona-computadora.
¿Por qué le importa a un diseñador?
Porque casi toda decisión de diseño es una decisión sobre dónde se paga la complejidad. Un formulario con cuarenta campos puede simplificarse en la interfaz, pero la complejidad aparece en la lógica del backend, que tiene que validar y combinar esos datos. O la interfaz puede exponer la complejidad y la persona la resuelve sola, con más errores.
La ley también sirve de freno a la tentación de esconder todo. Quitar un paso visible puede mover el trabajo a alguien que no está preparado para hacerlo. Diseñar bien implica elegir conscientemente quién lo carga y comprobar que esa elección tiene sentido.
¿Qué ejemplo da Tesler?
Laws of UX resume la postura de Tesler así: un ingeniero debería pasar una semana extra reduciendo la complejidad de una aplicación, en lugar de hacer que millones de usuarios dediquen cada uno un minuto extra a lidiar con ella. La Wikipedia recoge su argumento con otras palabras: si un millón de usuarios pierde un minuto al día por una complejidad que un ingeniero podría haber eliminado en una semana, se penaliza al usuario para facilitar el trabajo del ingeniero. La comparación es directa. El costo de simplificar una vez en el equipo de desarrollo puede ser muy inferior al costo acumulado de la complejidad que pagan muchas personas.
No es una regla para aceptar cualquier complejidad. Es una forma de calcular quién conviene que la pague.
¿Qué recomienda?
Laws of UX resume tres recomendaciones que se pueden llevar a una revisión de diseño:
- Quitar la carga del usuario tanto como sea posible. Si el sistema puede decidir un valor por defecto razonable, hacerlo.
- No diseñar para un usuario idealizado y racional. Las personas olvidan, se distraen y usan el producto con prisas.
- Ofrecer ayuda accesible en el contexto de uso. Un tooltip en el momento de la duda vale más que un manual de treinta páginas.
Estas recomendaciones se conectan con la carga cognitiva: cada decisión que el usuario tiene que tomar o recordar consume recursos. Y con los principios de diseño, que ayudan a decidir cuándo ocultar y cuándo mostrar.
Límites de la ley
Bruce Tognazzini, citado por Laws of UX y por la Wikipedia (su ensayo se titula The Complexity Paradox), sostiene que la gente resiste la simplificación: al reducir la complejidad de una aplicación, los usuarios intentan después tareas más complejas. Es una objeción seria. Quitar complejidad puede abrir nuevas expectativas que el sistema no cubre.
Además, la Wikipedia la describe como un adagio: una observación de la práctica profesional, útil para pensar, pero no una medida. La ley no dice cuánta complejidad hay en un sistema ni cuánta se puede mover. Para saber si una simplificación funciona, hace falta probarla con usuarios.
Ejemplo
Ejemplo ilustrativo: una aplicación de reservas de vuelos pedía a la persona elegir entre cuatro tipos de tarifa, con condiciones distintas, antes de ver el precio final. Las personas abandonaban en esa pantalla. El equipo decidió mostrar primero la tarifa más común como predeterminada, con un enlace claro a las demás. Los ingenieros dedicaron dos semanas a calcular las combinaciones de condiciones en el servidor, que antes se mostraban en la interfaz. La complejidad no desapareció: se trasladó al código, donde le correspondía. Las personas que buscaban otra tarifa seguían pudiendo elegirla, aunque ya no era el primer paso.
Para tu próxima pantalla: lista las decisiones que la persona tiene que tomar y pregúntate cuál de ellas podría resolver el sistema. Si la respuesta es alguna, esa es la complejidad que probablemente conviene trasladar.
¿Cuándo NO conviene trasladarla?
- Cuando la decisión es del usuario. Una elección de datos personales o de preferencias no debería resolverla el sistema.
- Cuando el sistema no puede decidir bien. Un valor predeterminado incorrecto puede ser peor que pedir la información.
- Cuando la complejidad es legal o de seguridad. Hay pasos que deben estar visibles aunque sean incómodos.
- Cuando el costo de trasladarla es mayor que el beneficio. A veces es más barato explicarla bien.
Errores comunes
- Esconder complejidad sin decidir quién la carga.
- Diseñar para el usuario ideal que lee todo y recuerda todo.
- Confundir simplicidad visual con simplicidad real: el paso puede seguir existiendo, solo que oculto.
- Quitar una decisión necesaria y generar errores que luego cuestan más.
- Dar por hecho que la simplificación funciona sin probarla.
- Ignorar la ayuda contextual cuando la complejidad es inevitable.
Relacionado en la wiki
Para el momento en que la persona debe elegir entre opciones, lee la ley de Hick. Y para entender qué esperan las personas de un sistema que ya conocen, la ley de Jakob muestra cómo los modelos mentales reducen el esfuerzo. Para la parte de roles y estados, que suele concentrar la complejidad, revisa roles, permisos y estados.