En corto:
Toda aplicación o proceso digital posee una cantidad de complejidad inherente que no se puede eliminar. El verdadero reto del diseño de experiencia de usuario no es hacer desaparecer esa complejidad, sino decidir estratégicamente quién la va a asumir: si el sistema a través de un diseño y desarrollo robustos, o el usuario mediante un mayor esfuerzo cognitivo.
El Problema
¿Alguna vez te has topado con un flujo de registro tan “limpio” y minimalista que terminas frustrado porque no sabes exactamente qué escribir o cómo avanzar?
Como diseñadores, es fácil caer en la trampa de obsesionarse con la estética minimalista y recortar elementos de la pantalla de manera desmedida. Creemos que al limpiar visualmente la interfaz estamos reduciendo la complejidad, pero a menudo solo estamos barriendo el polvo debajo de la alfombra.
El problema es que la complejidad de la tarea no se destruye de forma mágica; si el equipo de diseño y desarrollo decide no lidiar con ella, se traslada directamente al usuario final. Esto se traduce en pantallas misteriosas, errores constantes al llenar datos, parálisis por análisis y, eventualmente, el abandono de la plataforma.
El Concepto (Qué es y de dónde viene)
La Ley de Tesler, también conocida como la Ley de la Conservación de la Complejidad, fue planteada por el reconocido científico de la computación Larry Tesler a mediados de la década de 1980, mientras trabajaba en el desarrollo de interfaces de usuario y lenguajes de programación en Xerox PARC y, posteriormente, en Apple.
Tesler argumentaba que, para cualquier sistema o proceso, existe una cantidad fija de complejidad inherente que no puede ser eliminada. El núcleo de su teoría reside en una decisión de diseño crucial:
“Toda aplicación tiene una cantidad de complejidad que debe ser asumida por el usuario o por el programador (y diseñador)”.
Si el equipo de producto hace el esfuerzo extra de estructurar la información, automatizar procesos y escribir lógica avanzada en el código, reduce al mínimo el esfuerzo del usuario. Pero si el equipo decide tomar el camino fácil para ahorrar tiempo de desarrollo, la carga de descifrar cómo funciona el sistema recaerá por completo en las personas que lo usan.
El Principio en el Espacio (Impacto en el diseño táctico de interacción y Arq. Info)
En el diseño de interfaces y la arquitectura de información, la Ley de Tesler actúa como una balanza de esfuerzo. No se trata de eliminar campos o pasos al azar, sino de reorganizar la estructura para que la tecnología haga el trabajo pesado en el fondo.
En la Arquitectura de la Información (AI): En lugar de abrumar al usuario obligándolo a clasificar, buscar o indexar su propia información, el sistema debe estructurar los metadatos de forma automática. Por ejemplo, al buscar un vuelo, el sistema asume la complejidad de consultar miles de bases de datos de distintas aerolíneas en milisegundos, presentando al usuario un diseño táctico de interacción limpio y ordenado con filtros simples, en lugar de un listado crudo de datos difíciles de digerir.
En el diseño táctico de interacción: Se manifiesta en el uso de defaults inteligentes (valores predeterminados) y la automatización de inputs. Si un usuario introduce su código postal, el sistema debería rellenar automáticamente la ciudad y el estado. La complejidad de cruzar bases de datos de códigos postales recae en el sistema; el usuario solo interactúa con un layout de un único campo de texto interactivo.
Ejemplos Visuales (Do’s & Don’ts)
Do (Buenas prácticas): El checkout inteligente
Imagina una pasarela de pago en una app de delivery. En lugar de pedirle al usuario que elija manualmente su tipo de tarjeta (Visa, Mastercard, Amex), introduzca su dirección completa escribiendo calle por calle, y busque el código de su país para el teléfono, el sistema hace lo siguiente:
- Detecta automáticamente la franquicia de la tarjeta de crédito a partir de los primeros dígitos.
- Usa una API de geolocalización o de autocompletado de mapas para rellenar la dirección con un solo clic.
- Asume de manera inteligente que la moneda y el prefijo telefónico corresponden al país donde se detecta la dirección IP.
- Resultado: Una interfaz limpia, rápida y sumamente fluida. El sistema cargó con el 90% de la complejidad de la tarea.
Don’t (Anti-patrón): La ilusión de la simplicidad
- Imagina el escenario opuesto para un sistema de reserva de transporte de carga: el equipo de diseño, queriendo que la interfaz parezca “sencilla”, reduce el formulario de reserva a tres campos ambiguos: Origen, Destino y Fecha.
- No hay autocompletado, no hay mapa visual, ni validación de formatos.
- Cuando el usuario escribe “Nueva York” y pulsa buscar, el sistema genera un error porque necesitaba que especificara el código de terminal exacto (ej. “JFK”, “LGA” o “EWR”).
- Resultado: La interfaz parece “limpia”, pero es inoperable. Al intentar simplificar el diseño visual sin resolver la complejidad real de la logística, se obligó al usuario a adivinar la sintaxis del backend, creando una experiencia frustrante y rota.
Checklist para tu proyecto
Lleva estas preguntas frente a tu prototipo o archivo de diseño actual para validar si estás aplicando la ley de forma correcta:
- ¿Estamos pidiendo datos que el sistema ya conoce? (Ej. pedir el correo electrónico dos veces para confirmarlo, o solicitar el país si ya tenemos el código postal y la IP).
- ¿Hemos implementado “defaults inteligentes”? (¿Están preseleccionadas las opciones más comunes para el 80% de los usuarios, evitándoles clics innecesarios?).
- ¿La simplificación visual ha dejado al usuario sin contexto? (¿Quitamos textos de ayuda, etiquetas de campos o indicadores de error que en realidad ayudaban a entender el proceso?).
- ¿La complejidad que ahorramos en el desarrollo del backend se está trasladando como fricción cognitiva en el frontend?
Conclusión
Diseñar con la Ley de Tesler en mente nos obliga a alejarnos del minimalismo puramente estético y sin propósito. Una interfaz limpia no es aquella que carece de elementos, sino aquella donde el usuario no tiene que pensar de más para lograr su objetivo.
Al final del día, asumir nosotros la complejidad de los procesos no solo reduce la fricción en pantalla, sino que construye un puente de confianza inquebrantable con el usuario.
