Estados de carga en interfaces de IA: qué mostrar mientras el modelo piensa
Qué mostrar mientras un modelo de IA responde: spinner, esqueleto, pasos reales o barra de progreso, según cuánto dure la espera y las guías de NN/g.
¿Por qué es distinto en IA?
En una app tradicional, una carga suele durar milisegundos o unos pocos segundos, y se conoce de antemano. En IA, una respuesta puede tardar dos segundos o veinte. La duración cambia según la longitud del texto, la carga del proveedor y, en un agente, la cantidad de pasos que da.
Esa incertidumbre cambia la elección. Un spinner solo dice “espera”, sin decir cuánto. Y una pantalla sin señal durante varios segundos lleva a la gente a recargar o a repetir la acción, lo que en IA suele significar pagar dos veces por la misma respuesta.
Las reglas de base vienen de Nielsen Norman Group (NN/g) y se pensaron para cargas de página, no para IA, pero el principio aplica: la forma del estado debe igualar la espera. Según NN/g:
- Con menos de 1 segundo no hace falta spinner ni esqueleto.
- Los spinners funcionan mejor en un solo módulo y con esperas de 2 a 10 segundos.
- Los esqueletos de pantalla (skeleton screens) se prefieren a los spinners en cargas de pantalla completa con espera de menos de 10 segundos, porque muestran el diseño de la página y reducen el tiempo de carga percibido.
- Con más de 10 segundos se recomienda una barra de progreso, y la espera necesita una estimación explícita de la duración.
¿Qué estado usar según la espera?
| Espera | Estado recomendado | Por qué |
|---|---|---|
| Menos de 1 segundo | Nada, o un cambio sutil en el botón | Un indicador solo añade parpadeo |
| 2 a 10 segundos, un solo bloque | Spinner o puntos pulsantes, con un texto corto | Indica trabajo sin prometer tiempo |
| Respuesta de texto larga | Streaming del texto, con un indicador breve al inicio | La persona lee mientras llega |
| Vista completa con estructura conocida | Esqueleto de la estructura | Anticipa la forma del resultado |
| Más de 10 segundos o tarea en pasos | Pasos reales, barra de progreso o estimación | Muestra que avanza y qué falta |
El sistema de diseño Cloudscape de AWS, en su patrón de pasos progresivos para IA generativa, coincide en el corte de 10 segundos. Por debajo, recomienda un estado de carga en el último paso, con detalles si es posible. Por encima, una estimación de tiempo cuando la espera es indeterminada y una barra de progreso cuando se puede medir. También aconseja no mostrar un estado de carga para esperas de menos de un segundo, porque parpadea, y empezar a mostrar el texto si el modelo responde rápido.
Un detalle que suele pasarse por alto es el texto del estado. NN/g recomienda acompañar la animación con una frase que explique la espera, como “Cargando comentarios…”, y desaconseja el “Cargando…” estático. En IA, “Pensando…” describe al modelo; “Buscando en tus facturas de marzo” describe el trabajo real y permite a la persona juzgar si va bien.
¿Cómo mostrar el progreso de un agente?
Un agente que llama herramientas tiene pasos reales: leer un archivo, consultar una API, escribir un resultado. Muestra esos pasos en una lista corta, con su estado (pendiente, en curso, hecho, falló). Así la espera deja de ser una caja negra. Cloudscape añade dos detalles útiles: el estado del paso principal debe reflejar el subpaso más urgente, y los pasos ya hechos pueden quedar en una sección plegable junto al resultado final.
Ojo con el progreso falso. Una barra que sube por tiempo, sin relación con el trabajo, miente. Si no puedes medir el avance, muestra pasos y no un porcentaje. Si tienes una estimación, márcala como estimación, por ejemplo “Este paso puede tardar hasta 15 segundos”. NN/g sugiere además ser generoso con la estimación: la gente tolera mejor una sorpresa agradable que una barra detenida.
Para entender por qué un agente da pasos intermedios, revisa el loop de un agente. Cuando lo que espera la persona es texto y no pasos, el streaming de respuestas suele ser mejor que cualquier indicador. Para saber de dónde sale la espera, mira latencia y tokens por segundo. Y si la tarea es larga y puede dejarse en segundo plano, la página de agentes en segundo plano describe ese modelo de notificación.
¿Qué pasa si tarda demasiado?
Define un umbral antes de lanzar la función. Por ejemplo (ajusta las cifras a tu caso): a los 10 segundos cambia el mensaje y ofrece cancelar; a los 60 segundos ofrece continuar en segundo plano o reintentar. Sin umbral, la pantalla se queda en “Cargando” hasta que la persona se rinde.
Y deja siempre una salida. NN/g recomienda dar una forma de detener el proceso cuando la acción tarda. Un botón de cancelar, un reintento y un mensaje que diga qué se perdió y qué se conserva valen más que cualquier animación. NN/g también desaconseja los avisos del tipo “no vuelvas a hacer clic”: es mejor mostrar que el primer clic ya se registró. Si el fallo es un error y no una espera, revisa errores de IA y cómo recuperarse.
¿Cuándo NO conviene un estado de carga visible?
Cuando la respuesta llega en menos de un segundo, un indicador solo añade parpadeo. Y en acciones que ocurren en segundo plano sin que la persona espere, una notificación al final suele ser mejor que bloquear la pantalla.
¿Cómo probar un estado de carga con personas reales?
Los estados de carga se juzgan mejor en uso. Pide a cinco personas que esperen una respuesta real sin interrumpir, y que cuenten en voz alta qué creen que pasa. Tres preguntas guían la observación:
- ¿Saben que el sistema trabaja a los dos segundos?
- ¿Saben qué hacer si tarda veinte?
- ¿Entienden qué pasó si falla?
Si alguien cree que la app se colgó, el estado no comunica lo suficiente, aunque técnicamente funcione. Prueba también con un lector de pantalla: el estado debe anunciarse, no solo verse (más en accesibilidad en interfaces de IA).
Ejemplo
Ejemplo ilustrativo: una app de finanzas personales genera un resumen mensual con IA, y la primera versión muestra un spinner durante unos 25 segundos. Con más de 10 segundos, las reglas de NN/g piden una barra de progreso o una estimación, y un spinner solo no da ninguna de las dos. Es de esperar que la gente abra el resumen dos o tres veces, creando solicitudes duplicadas.
El equipo cambia el estado por una lista de pasos reales: “Leyendo tus movimientos”, “Agrupando por categoría”, “Redactando el resumen”. Cada paso se marca al completarse. Si una categoría tarda demasiado, aparece un aviso con la opción de seguir esperando o cancelar. Para saber si funcionó, el equipo compara el porcentaje de resúmenes pedidos más de una vez antes y después del cambio.
Errores comunes
- Usar el mismo spinner para todo, desde un guardado hasta un análisis de cinco minutos.
- Prometer un tiempo que no se cumple.
- Mostrar un porcentaje que no corresponde a trabajo real.
- Dejar la pantalla bloqueada sin opción de cancelar.
- Escribir “Cargando…” sin decir qué se está haciendo.
- Olvidar el estado de error: si la carga falla, el mensaje debe decir qué pasó y qué hacer.