Tooltips: el patrón warm window de 200ms que mejora tu UX

El problema: tooltips que aparecen sin permiso

Un tooltip es uno de los componentes más simples de una interfaz y, al mismo tiempo, uno de los más fáciles de hacer mal. Cuando el desarrollador deja el retardo en 0 ms, cualquier paso del cursor sobre un elemento dispara la etiqueta: el usuario va hacia un botón y, de paso, recibe seis tooltips que no pidió. Cuando el desarrollador lo compensa con un retardo fijo (por ejemplo, 500 ms), la experiencia se vuelve lenta y los usuarios dejan de leer la información que sí querían.

El autor del blog técnico Master.dev documentó exactamente este dilema en FrontPrep, su producto de preguntas de entrevista. En las páginas donde aparecen logos de empresas, configurar el retardo a 0 ms hacía que cada barrido del cursor abriera tooltips en cadena; subirlo a un valor fijo, en cambio, penalizaba la navegación entre logos vecinos. La solución que terminó adoptando no es nueva, pero rara vez se nombra: la llama patrón warm window («ventana caliente»), y consiste en tres números que cooperan entre sí.

La solución: tres números y dos estados

El patrón se resume así, según la documentación de FrontPrep:

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

200 ms de retardo de apertura. Por debajo de 150 ms, un cursor que solo pasa por encima del elemento abre el tooltip. Por encima de 250 ms, la espera se siente rota. 200 ms es el punto medio.
300 ms de «ventana caliente». Cuando un tooltip se cierra, arranca una cuenta atrás. Si durante esos 300 ms el usuario entra en otro tooltip, este se abre al instante, sin animación ni retardo.
0 ms de retardo de cierre. Salir del elemento debe sentirse inmediato; cualquier espera extra se percibe como lag.

El concepto clave es que la página solo tiene dos estados: fría (se aplica el retardo de 200 ms) y caliente (no hay retardo). Mientras el usuario se mueva entre tooltips dentro de la ventana caliente, la página se mantiene caliente; cuando expira el cooldown, vuelve a estar fría y el siguiente tooltip volverá a esperar 200 ms. Sin ese paso de «enfriamiento», el primer tooltip habría apagado el retardo para siempre en toda la página.

Por qué 200 ms es el número correcto

La intuición detrás del 200 ms es que un clic es siempre intencional, pero un hover nunca lo es. El cursor atraviesa la pantalla para llegar a un destino, y en el camino pasa por encima de elementos que no le interesan. El tooltip no puede distinguir, a partir del evento onMouseEnter, si el usuario quería abrirlo o si simplemente iba de paso. El retardo es la forma en que el componente lo averigua: si el cursor sigue ahí 200 ms después, es porque quería quedarse.

Este razonamiento coincide con la regla general de Material Design de Google, que define un retardo de 400-700 ms para tooltips largos y 200-300 ms para tooltips cortos, y con la guía de Apple Human Interface Guidelines, que recomienda un pequeño retardo antes de mostrar ayuda contextual para evitar parpadeos en interfaces densas (según la entrada sobre tooltip de Wikipedia, que recopila estas especificaciones de los principales sistemas de diseño).

Cómo implementarlo en React

En FrontPrep los tooltips se construyen sobre Radix UI y Motion, pero el patrón funciona con cualquier librería. El núcleo son cuatro piezas:

Un provider compartido (TooltipProvider) que mantiene un useRef con el estado warm y otro con el temporizador de cooldown. Usar un ref en lugar de un useState evita re-renderizar todos los tooltips de la página cada vez que cambia el estado.
handleEnter en cada tooltip: si la página está caliente, abre al instante; si no, programa un setTimeout(show, 200).
show abre el tooltip, copia el valor de isWarm a una variable instant y notifica al provider con markOpened(), lo que pone la página en estado caliente y cancela cualquier cooldown pendiente.
handleLeave cancela el temporizador de apertura si el cursor salió antes de los 200 ms (un barrido rápido no debe abrir nada), y si el tooltip estaba abierto, llama a markClosed(), que arranca el cooldown de 300 ms.

El truco visual para que un tooltip «salte» la animación cuando la página está caliente es un atributo data-instant="true" que el CSS interpreta para poner transition-duration: 0ms:

.tooltip[data-instant="true"] {
  transition-duration: 0ms;
}

El propio autor publicó una versión posterior del artículo donde replica el mismo comportamiento sin una sola línea de JavaScript, apoyándose solo en transition-delay y selectores CSS.

Accesibilidad: lo que exige WCAG 2.2

El patrón no es solo una cuestión de gusto. El criterio de éxito 1.4.13 Content on Hover or Focus de las Web Content Accessibility Guidelines (WCAG) 2.2, publicadas por el W3C, exige que el contenido que aparece al pasar el cursor sea descartable, hoverable y persistente. En la práctica, eso significa que un tooltip debe poder cerrarse sin mover el cursor, debe permitir al usuario mover el ratón sobre su contenido sin que se cierre, y debe permanecer visible hasta que el usuario lo descarte o hasta que la información deje de ser válida.

Un tooltip que aparece instantáneamente al pasar el cursor suele violar la primera condición (es difícil descartarlo si parpadea con cada movimiento del ratón). El retardo de 200 ms ayuda a cumplirla porque reduce la aparición accidental; la ventana caliente de 300 ms, en cambio, hay que combinarla con un método de cierre explícito (Escape, clic fuera, o focus en otro elemento) para no romper la persistencia cuando el usuario necesita leer el contenido.

Qué significa esto para tu startup

El patrón warm window no es una optimización prematura. Es el tipo de detalle que separa a un producto que funciona de uno que se siente profesional, y los usuarios lo notan aunque no sepan ponerle nombre. Tres acciones concretas que puedes aplicar esta semana:

Audita los tooltips de tu producto preguntándote si un barrido rápido del cursor abre más de uno a la vez. Si la respuesta es sí, tienes el bug que FrontPrep documentó, y cualquier valor entre 150 y 250 ms de retardo va a mejorar la experiencia de inmediato.
Si tu interfaz tiene clusters de elementos con tooltip (filas de iconos, tablas densas, listas de empresas), no te quedes con un retardo fijo: implementa la lógica de página caliente para que mover el cursor entre triggers vecinos sea instantáneo.
Integra la regla en tu AI tooling. El autor convirtió el patrón en un skill de Claude para auditar codebases; tú puedes hacer lo mismo con las convenciones de UX de tu equipo (colores, tipografía, accesibilidad, formularios) y pasarlas como contexto a tu generación de código. La IA produce componentes correctos; los detalles pulidos los defines tú y se los enseñas.

La reflexión final del artículo original es la más incómoda para un founder: si le pides a una IA que construya un tooltip, te devolverá un tooltip funcional. Pero la diferencia entre funcional y pulido la pone el criterio humano, ese que se forma con años de práctica. El patrón warm window es un ejemplo perfecto: cualquier asistente lo podría codificar en cinco minutos, pero reconocer que el problema existía requirió que alguien se sintiera molesto dos días seguidos por un cursor que abría cosas sin permiso.