Umbral de Doherty: la velocidad que mantiene el foco
El umbral de Doherty propone responder en menos de 400 ms para que nadie espere al sistema. Qué dice el estudio de IBM, qué critica Kent Beck y cómo aplicarlo.
¿Qué dice la pauta?
Laws of UX la formula así: la productividad sube cuando la computadora y el usuario interactúan a un ritmo que asegura que ninguno espere al otro, y recomienda dar retroalimentación del sistema dentro de los 400 ms (Laws of UX: Doherty Threshold). La idea práctica es que una respuesta inmediata mantiene a la persona dentro del hilo de lo que estaba haciendo.
No dice que todo deba terminar en 400 ms. Dice que la respuesta inicial, la señal de que algo pasó, debe llegar rápido. Esa distinción importa más de lo que parece.
¿De dónde viene?
La pauta se atribuye a un trabajo de 1982 de Walter J. Doherty y Ahrvind J. Thadani, de IBM. Según Laws of UX, ese trabajo propuso que el tiempo de respuesta de una computadora fuera de 400 ms, en lugar de los dos segundos del estándar anterior. Kent Beck, que escribió sobre la cifra, confirma el contexto: la investigación de IBM desafió la creencia de que dos segundos eran aceptables (Kent Beck: The Precious Eyeblink).
Network World resume el mismo trabajo, titulado «The Economic Value of Rapid Response Time» y atribuido a Arvind Thadhani, con una idea más amplia: la productividad mejoraba de forma no lineal cuando el tiempo de respuesta bajaba de un segundo (Network World). Ninguna de las fuentes citadas detalla el método del estudio, así que los 400 ms funcionan mejor como objetivo de diseño que como resultado experimental exacto.
¿Qué critica Kent Beck?
Beck reconoce que la investigación de IBM fue real y que la productividad mejora cuando la respuesta es rápida. Pero advierte dos cosas. Primero, que no existe investigación que diga que la atención empieza a deteriorarse exactamente a los 400 ms. Segundo, que el umbral es «practically motivated», es decir, una frontera útil para el diseño, no una constante del cerebro humano. Describe el límite como difuso («give or take») y llama a la cifra «una especificación para diseñar en torno a ella».
Esa crítica es útil para un diseñador: el número sirve como objetivo de diseño, no como argumento para dejar de medir. Si tu pantalla responde en 380 ms pero el resultado tarda cuatro segundos, la persona sigue esperando.
¿Cómo se relaciona con los otros límites?
Jakob Nielsen propone tres límites de tiempo de respuesta, que UX Tigers resume así: 0,1 segundos (100 ms) crea la ilusión de respuesta instantánea; un tiempo menor a 1 segundo permite mantener un flujo de pensamiento continuo; y 10 segundos es el máximo antes de que la atención de la persona se disperse (UX Tigers: Time scales of UX). Beck sitúa el umbral de Doherty dentro de este marco: 400 ms queda entre el primer límite y el segundo.
En la práctica, conviene tratar estas cifras como pautas de diseño y no como cortes exactos: cada una describe una banda de percepción, no un interruptor que se activa en un milisegundo preciso.
¿Qué hacer cuando la respuesta tarda?
El principio útil es responder de inmediato aunque el resultado tarde. Laws of UX destaca que las barras de progreso ayudan aunque su precisión no sea perfecta. En la práctica, eso significa:
- Cambiar el estado del botón en el mismo instante del clic: deshabilitarlo, mostrar un spinner o una etiqueta de «Guardando».
- Mostrar algo útil mientras llega el resultado, como el esqueleto de la lista. Mira skeleton vs. optimistic UI para elegir el patrón.
- Usar retroalimentación de la acción, como un cambio visual o una vibración, antes de que llegue la respuesta del servidor.
- Mostrar un mensaje claro cuando la espera supera varios segundos, con una salida si es posible.
Lo que no conviene es poner una animación bonita que tarda más que el trabajo real. Eso convierte la espera en una pausa decorativa.
Ejemplo ilustrativo
Ejemplo ilustrativo: una app de notas tarda 900 ms en guardar cada cambio y no muestra nada durante ese tiempo. Las personas repiten el clic en «Guardar» y a veces duplican la nota. El equipo cambia el botón a «Guardando…» en el mismo instante del clic y muestra una marca discreta cuando termina. El tiempo real no cambió, pero la respuesta inicial llegó en menos de 100 ms. El número de duplicados baja porque la persona sabe que algo está pasando.
Si quieres profundizar en la relación entre espera y retroalimentación, lee feedback y feedforward, y revisa la percepción de rendimiento, que trata la espera como un problema de diseño, no solo de ingeniería. Y si el sistema tarda por una razón que la persona no entiende, mira la conciencia de estado.
Errores comunes
- Creer que el umbral es una ley científica exacta.
- Optimizar solo el tiempo de servidor y olvidar la retroalimentación inmediata.
- Mostrar un spinner indefinido sin explicar qué pasa cuando la espera se alarga.
- Agregar animaciones largas a una respuesta que ya era rápida.
- Medir el rendimiento en una computadora potente y no en un celular con mala conexión.
Qué puedes hacer mañana
- Haz una lista de las cinco acciones más frecuentes de tu producto y anota cuánto tarda la primera respuesta visible de cada una.
- Para las que superan 400 ms, define un estado de carga o un cambio de botón que aparezca en el mismo instante del clic.
- Pide a desarrollo el tiempo real en un celular medio, no solo en una laptop.