Deja de exprimir milisegundos y muestra qué está pasando

Toda acción en una interfaz tiene un tiempo de espera, por rápido que sea el sistema. Lo que más pesa en cómo se vive esa espera es si la pantalla responde en el momento y deja claro qué está pasando, más que bajar unos milisegundos.

Es fácil pasar semanas optimizando una consulta y dejar el botón igual que antes: se toca, no cambia nada durante un segundo y medio, y después aparece el resultado. En ese segundo y medio la persona no sabe si el toque se registró. Vuelve a tocar, recarga o se va.

Tres umbrales que conviene tener a mano

Jakob Nielsen resumió hace décadas tres límites de tiempo de respuesta que siguen siendo una buena guía:

• Hasta una décima de segundo, la respuesta se siente instantánea y basta con mostrar el resultado.
• Hasta un segundo, la persona nota la demora pero no pierde el hilo. Pasado ese punto conviene indicar que el sistema está trabajando.
• Hacia los diez segundos se pierde la atención. Una espera así necesita mostrar avance y, si se puede, cuánto falta.

La conclusión práctica es que casi ninguna acción real queda por debajo de la décima de segundo cuando hay red, base de datos o un modelo de lenguaje de por medio. Así que casi todas necesitan alguna señal.

Responde al toque, no al resultado

Imagina una app para reservar citas. La persona elige un horario y toca «Confirmar». El servidor tarda dos segundos en guardar la reserva y enviar el correo.

Sin feedback, esos dos segundos se viven como un fallo. Con feedback, se ven así:

1. Al instante, el botón cambia de estado: se desactiva y dice «Confirmando…». Eso responde al toque y evita la segunda reserva por un doble clic.
2. Si la espera pasa de un segundo, aparece una línea que dice qué está ocurriendo: «Guardando tu cita».
3. Al terminar, la pantalla confirma lo concreto: el servicio, el día y la hora reservados.
4. Si falla, el mensaje dice qué pasó y qué hacer, y conserva lo que la persona ya eligió.

Ninguno de esos pasos hace más rápido al servidor. Lo que cambian es que la persona sabe en todo momento que su acción está en curso.

Dónde poner feedback primero

No hace falta revisar toda la interfaz de una vez. Empieza por las acciones donde una duda cuesta más:

• Las que crean algo: una reserva, un pago, un pedido. Ahí un segundo toque duplica.
• Las que dependen de un modelo de IA. Sus tiempos varían mucho entre una respuesta y otra, y un indicador que muestre las etapas (leyendo, redactando, revisando) hace tolerable una espera larga.
• Las que cambian de pantalla. Un esqueleto con la forma del contenido dice «ya viene» mejor que una pantalla en blanco.

Cómo pedírselo a un agente

Si un agente construye o modifica la interfaz, incluye el feedback en el encargo en lugar de esperar que aparezca solo. Una forma de pedirlo:

• Lista las acciones que tardan más de una décima de segundo.
• Para cada una, define el estado inmediato, el mensaje si pasa de un segundo, la confirmación final y el mensaje de error.
• Prueba cada acción con la red lenta del navegador y con un fallo forzado.

La última línea es la que más se omite y la que más encuentra. Con la red simulada lenta se ven los botones que no responden y los dobles envíos.

La comprobación final

Toma la acción más importante de tu producto, activa la red lenta y úsala como lo haría alguien por primera vez. Si en ningún momento te preguntas si el toque funcionó, el feedback está bien resuelto. Solo entonces vale la pena volver a mirar los milisegundos.

Los tres límites vienen de Response Times: The 3 Important Limits, de Jakob Nielsen, en Nielsen Norman Group. La app de citas es un ejemplo para ilustrar el método.