En corto: La Ley de Doherty establece que la productividad y la atención se disparan cuando un sistema y sus usuarios interactúan a un ritmo de menos de 400 milisegundos.
El Problema
¿Alguna vez has notado que, tras tocar un botón, una pequeña demora te hace dudar si el sistema registró tu acción, llevándote a hacer clic repetidas veces con frustración?
Cuando una interfaz tarda más de medio segundo en dar retroalimentación visual, rompe por completo la concentración del usuario. Este dolor ocurre porque el cerebro humano percibe el retraso no solo como lentitud, sino como un error o una interrupción. Esto saca a la persona de su flujo de trabajo y genera la falsa percepción de que el producto digital es ineficiente, torpe o que directamente se ha “congelado”.
El Concepto (Qué es y de dónde viene)
En 1982, los investigadores Walter J. Doherty y Ahrvind J. Thadani publicaron un revelador estudio en el IBM Systems Journal. Hasta ese momento, el estándar de la industria computacional consideraba “aceptable” un tiempo de respuesta de 2 segundos.
Sin embargo, Doherty y Thadani demostraron con datos empíricos que cuando el tiempo de respuesta de una computadora caía por debajo de los 400 milisegundos (ms), la productividad de los usuarios no solo aumentaba linealmente, sino de forma exponencial.
Este descubrimiento originó la Ley de Doherty (también conocida como el Umbral de Doherty). En términos de psicología cognitiva, cuando el sistema responde en menos de 400 ms, la memoria de trabajo del usuario no tiene tiempo de disiparse. Las acciones se encadenan de manera ininterrumpida, facilitando una inmersión profunda y fluida en la tarea.
El Principio en el Espacio (Impacto en el diseño táctico de interacción y Arq. Info)
En el diseño UX/UI, aplicar la Ley de Doherty no significa que debas optimizar las bases de datos (eso es terreno del backend), sino que debes diseñar para la percepción del tiempo.
En el diseño táctico de interacción y la arquitectura de la información, esto se traduce en estructurar la interfaz para que siempre haya una reacción inmediata. Si una pantalla requiere tiempo para cargar datos pesados, el layout debe anticiparse mediante elementos estructurales como los Skeleton Screens (pantallas esqueleto), que reservan el espacio físico y evitan saltos bruscos (layout shifts).
La agrupación de componentes debe prever dónde aparecerán los indicadores de carga localizados (barras de progreso, spinners) para no bloquear toda la pantalla. Esencialmente, utilizas la estructura visual para engañar positivamente al cerebro, haciéndole sentir que el sistema ya está respondiendo y procesando la solicitud dentro del límite de los 400 ms.
Ejemplos (Do’s & Don’ts)
Do (Buenas prácticas): Un usuario completa un formulario de registro y hace clic en “Crear cuenta”. En menos de 100 ms, el botón cambia de color y el texto es reemplazado por un spinner de carga integrado, deshabilitando clics adicionales.
Aunque la base de datos tarde 2 segundos en validar la información, la pantalla siguiente hace una transición suave mostrando un skeleton screen de la interfaz principal. El usuario siente que el proceso avanza rápidamente y sin trabas.
Don’t (Anti-patrón): Un usuario hace clic en el botón “Pagar” en un carrito de compras. El sistema envía la petición al servidor, pero visualmente el botón permanece idéntico: sin cambio de estado, sin animaciones. Pasan 800 ms de parálisis visual.
El usuario, creyendo que no hizo clic correctamente o que la pantalla no funciona, presiona el botón tres veces más, arriesgándose a duplicar cargos y generando una experiencia de alta fricción y desconfianza.
Checklist para tu proyecto
- ¿Tus botones, tarjetas y enlaces cuentan con estados interactivos (como
:hovery:active) que ofrecen retroalimentación visual en menos de 100 ms? - Si un proceso requiere más de 400 ms por limitaciones técnicas, ¿estás implementando microanimaciones o indicadores de progreso dinámicos para mitigar la percepción de espera?
- ¿Utilizas skeleton screens para mantener la estabilidad del layout y mostrar que el contenido está en camino, en lugar de dejar al usuario frente a una pantalla en blanco?
- ¿La arquitectura de tu interfaz permite procesos asíncronos en segundo plano, logrando que el usuario pueda seguir navegando en otras áreas sin sentirse bloqueado?
En conclusión
Dominar la Ley de Doherty significa que dejas de diseñar simples pantallas estáticas para empezar a orquestar ritmos de interacción. Como UXers, no siempre podemos controlar la velocidad real de la red, de las APIs o de los servidores, pero tenemos el poder absoluto sobre cómo se percibe ese tiempo en nuestra interfaz.
