El estado de carga es el producto
Los estados de carga son la pantalla más vista de todo lo que lanzas. Cinco arquetipos, ejemplos reales de Linear, Vercel, Stripe, Cursor, Claude y Figma, y una auditoría de seis preguntas que puedes ejecutar hoy.
Suma todos los estados de carga que tu producto muestra en un año. Cada usuario, cada sesión, cada recarga. Ese número, medido en horas de usuario, es la pantalla más vista que lanzas. La mayoría de los equipos la trata como si nadie la mirara.
El dashboard recibe una revisión de diseño. El estado vacío, si has leído los estados vacíos son el producto, recibe una revisión de diseño. El estado de carga recibe un spinner de 16 píxeles de una hoja de estilos de 2012 y una oración. Es la única pantalla que el usuario siempre ve, y la única que nadie diseña.
El estado de carga es una impresión de marca
Cada estado de carga es un contrato de confianza. El producto le dice al usuario "estoy trabajando, no me he caído, la espera es a propósito". Lo que diga la pantalla a continuación se convierte en cómo la marca maneja la presión.
Los estados de carga de Linear se sienten como Linear. Filas esqueleto con la forma de la lista de issues, creación inline que se confirma antes de que responda el servidor, transiciones de marca con una cadencia deliberada. Los de Stripe se sienten como Stripe. El brillo del botón de pago, los esqueletos con forma de tarjeta en el dashboard, el recibo que se resuelve en su estado final. Ambos tratan la espera como el producto.
La versión mala es el gif giratorio heredado sobre fondo blanco. Sin forma de contenido, sin señal de progreso, sin marca. Al usuario se le dice "nos liamos y nos olvidamos de que estabas aquí". Eso es una impresión de marca. Simplemente no es la que el equipo quería lanzar.
Los cinco arquetipos de estado de carga
La mayoría de los equipos trata el "estado de carga" como un solo problema de diseño. Son cinco. Cada uno encaja con un tipo distinto de espera y falla por una razón distinta.
1. Pantalla esqueleto
Un layout provisional que replica la forma del contenido final. Filas donde habrá filas, tarjetas donde habrá tarjetas. El ojo se ancla a la estructura antes de que llegue el contenido, y la espera se lee como algo que se resuelve, no que empieza.
La lista de issues de Linear lanza esqueletos con forma de fila que coinciden con la lista final al píxel. Stripe Dashboard lanza esqueletos con forma de tarjeta en la sección de métricas que se resuelven en las tarjetas pobladas. Notion lanza marcadores con forma de bloque que se convierten en bloques reales cuando carga el documento. Misma promesa: la forma de carga predice la forma final.
Úsalo cuando la estructura es conocida. Evítalo cuando el layout es tan dinámico que el esqueleto mentiría sobre lo que viene.
2. UI optimista
Renderiza la acción del usuario de inmediato, antes de que el servidor confirme. Reconcilia en segundo plano. Si el servidor está de acuerdo, la UI no parpadea. Si no, la UI revierte con un camino de deshacer visible.
La creación inline de issues de Linear es el estándar de oro. Pulsa C, escribe un título, dale a enter, el issue ya está en la lista antes de que termine el viaje de ida y vuelta. El cursor y los movimientos de selección de Figma son optimistas en toda la sesión multijugador. El usuario nunca siente la red.
Úsalo cuando el fallo es raro y reversible. Evítalo cuando la acción es destructiva o el usuario necesita la respuesta del servidor para continuar.
3. Parcial en streaming
Renderiza el primer fragmento mientras el resto sigue en camino. La espera desaparece dentro del resultado porque el usuario ya lo está consumiendo.
El flujo de tokens de Claude es el ejemplo más limpio que existe, con una cadencia suavizada que se lee a velocidad humana. Cursor transmite el diff token a token, así que el usuario lee código antes de que el modelo termine de escribirlo. Vercel transmite el log del deploy en vivo, así que el usuario ve el build en lugar de esperarlo. El artículo sobre diseñar para la latencia de la IA cubre la estrategia de latencia en general.
Úsalo cuando el resultado tiene una cadencia natural. Evítalo cuando los fragmentos no sirven por sí solos.
4. Progreso como contenido
La espera misma es el valor. El log del deploy, el pipeline de build, la traza de razonamiento del agente. El usuario no espera el resultado. Está leyendo el resultado.
La vista de deploy de Vercel es el ejemplo canónico. El log del deploy es el estado de carga, y la pantalla más lanzada de la plataforma. GitHub Actions hace lo mismo con la salida paso a paso de cada ejecución. El panel de agente de Cursor muestra la traza de razonamiento mientras trabaja, así que una tarea de varios minutos se siente con propósito en vez de atascada. v0 y Lovable lanzan esto en superficies de prompt a app, donde el build en streaming es el estado de carga y la vista previa es la recompensa.
Úsalo cuando la espera es el valor. Evítalo cuando los pasos no sirven a un usuario que solo quiere el estado final.
5. Spinner de marca
El micropulso, el degradado, el brillo. El momento en que el producto se gana un token de personalidad. El brillo del botón de pago de Stripe, la barra de progreso en degradado de Vercel, el micropulso de Linear en esperas transitorias. Ninguno hace el trabajo solo. Van encima de uno de los primeros cuatro patrones, añadiendo pulido de marca a una espera que ya tiene estructura.
Úsalo cuando la espera es corta y la superficie es de alto riesgo. Evítalo cuando no hay esqueleto ni stream detrás. Un spinner de marca sin uno de los primeros cuatro patrones debajo es un spinner de 1996 con un código hex de 2026.
Los esqueletos le ganan a los spinners casi siempre
Un esqueleto predice la forma de lo que viene. Un spinner solo indica que algo está pasando en algún sitio. Misma espera, dos experiencias distintas.
El esqueleto del dashboard de Stripe es apenas más rápido en el reloj que una versión con spinner, pero la brecha de velocidad percibida es mucho mayor. El usuario ve un layout con forma de tarjetas y empieza a orientarse antes de que lleguen los datos. Cuando las métricas se resuelven, el ojo ya está en posición. Con un spinner, el usuario mira fijamente el centro de la pantalla esperando permiso para mirar a otro lado. Si puedes predecir el layout, lanza un esqueleto. Si no, lanza una línea de estado.
La UI optimista es el truco definitivo
La espera se vuelve invisible porque la acción se confirma antes de que empiece la espera.
Linear lanzó optimismo en todas partes. Crear issue, cambiar estado, cambiar asignado, añadir etiqueta, mover de ciclo. Cada uno escribe en el store local al expresar la intención y reconcilia cuando el servidor responde. El multijugador de Figma es optimista en movimientos de cursor, selección y la mayoría de las ediciones. Notion es optimista en la edición de documentos. Cada producto se siente como software local porque la red quedó escondida bajo la capa optimista.
Dos cosas hacen que funcione. El fallo tiene que ser raro y reversible, o la UI parpadea y el usuario deja de confiar. Y los errores tienen que ser visibles. Una acción optimista que se traga en silencio un error del servidor es peor que no tener optimismo, porque le enseña al usuario que la acción funcionó cuando no fue así. Toda escritura optimista necesita un deshacer, un toast o un rollback que el usuario pueda ver.
Cinco reglas para estados de carga excelentes
Cumple cuatro de cinco y la espera se lee como diseñada. Cumple tres y el estado de carga empieza a parecer una ocurrencia tardía.
- La forma de carga predice la forma final. Filas esqueleto para filas, tarjetas esqueleto para tarjetas. Sin saltos de layout cuando se resuelve el contenido.
- La espera recibe contenido siempre que sea posible. Transmite los tokens, lanza el log, renderiza el parcial. Un usuario que lee no está esperando.
- Toda espera de más de 800 ms recibe feedback. Por debajo de 800 ms basta una transición limpia. Por encima, el usuario necesita una señal de que el sistema está vivo, aunque sea una revelación progresiva de estructura primero y contenido después.
- Las acciones optimistas necesitan un camino de deshacer visible. Un toast, un rollback, un estado de error claro. Optimismo sin recuperación es gaslighting.
- Ningún spinner sin una razón de marca. Los spinners de marca van encima de uno de los primeros cuatro patrones, nunca los reemplazan. Si lo único en pantalla es el spinner, el diseño no está terminado.
El contexto más profundo está en el desglose más amplio de principios de diseño web y en cómo los core web vitals tratan el cambio de layout como un fallo de rendimiento percibido.
Antipatrones que matan los estados de carga
Seis modos de fallo se lanzan más de lo que deberían. Cada uno tiene arreglo, y cada uno está ahora mismo en producción en algún sitio.
El spinner indefinido sin progreso. Un spinner que lleva quince segundos girando sin ninguna señal. El usuario no sabe si la petición está viva, muerta o atascada. Reemplázalo con una línea de estado, una barra de progreso o una superficie en streaming.
El modal que bloquea la página y no se puede cerrar. Un modal de carga que secuestra toda la pantalla y no deja al usuario hacer scroll, copiar ni leer el resto del producto. La espera se convierte en una situación de rehenes.
El layout que salta cuando se resuelve el esqueleto. Un esqueleto que no coincide con el layout real. Las filas se desplazan, las tarjetas se recolocan, el header se mueve. El esqueleto no es un diseño distinto, es el mismo diseño sin contenido.
El texto "Cargando..." en bucle eterno. Tres puntos rotando, sin progreso, sin estado. El usuario aprende en dos sesiones a ignorarlo, lo que mata el canal para cualquier estado real que la superficie lance después.
La UI optimista que se traga los errores en silencio. La acción se confirma en la UI, el servidor falla, el producto nunca se lo dice al usuario. El arreglo es un toast visible, un botón de deshacer o un rollback.
Spinners de marca en una espera de 100 ms. Un brillo para una espera que termina antes de que el usuario la note. Puro sobrecoste. Las superficies rápidas merecen un fade. Las lentas merecen una estructura.
Diseñar fricción a propósito cubre los raros casos en que una espera debe ser visible deliberadamente. Los estados de carga no son esos. Son las esperas que deberían ser invisibles, diseñadas o convertidas en contenido.
La auditoría del estado de carga
Seis preguntas. Pasa cada superficie de carga por ellas antes del próximo release.
- ¿La forma de carga predice la forma final? Esqueletos para layouts predecibles, líneas de estado para los impredecibles. Sin salto de layout al resolverse.
- ¿La espera lleva información? Un esqueleto, un stream, un log de progreso, una línea de estado. Cualquier espera de más de 800 ms sin nada encima es una fuga.
- ¿Hay un único mensaje principal por espera? "Cargando dashboard" le gana a cuatro señales superpuestas. Una señal, con la jerarquía visual haciendo el trabajo.
- ¿El estado de carga coincide con la voz de marca? Lee el copy de carga junto a la pantalla poblada. Si el tono cambia, el estado de carga lleva puesta otra marca.
- ¿Las acciones optimistas son reversibles y visibles al fallar? Toda escritura optimista tiene un deshacer, un toast o un rollback. Nada de fallos silenciosos.
- ¿La pantalla de carga le vendería el producto a un desconocido? Si la única pantalla que vieran fuera el estado de carga, ¿se sentiría como el producto al que se apuntaron? Si no, la pantalla más vista de tu app es también la peor diseñada.
Un producto donde todos los estados de carga pasan esas seis se siente rápido incluso con una red lenta.
Elige el patrón y luego lanza la espera
Los estados de carga no son la capa de pulido. Son la capa de marca, la capa de confianza y la capa de rendimiento percibido comprimidas en la pantalla que el usuario ve más que ninguna otra. Cada espera es una decisión de diseño, la haya tomado el equipo a propósito o no.
Esqueleto donde la estructura es conocida. Optimista donde el fallo es reversible. Streaming donde el resultado tiene cadencia. Progreso como contenido donde la espera es el valor. Spinner de marca solo cuando los primeros cuatro ya hacen su trabajo. El desglose de principios de diseño de landing pages es la versión para páginas de marketing de esta disciplina.
Deja de tratar el estado de carga como una disculpa por ser lento. Acumulado, es el producto. Haz que la espera valga su tiempo.
FAQ
¿Cuál es la diferencia entre una pantalla esqueleto y un spinner de carga?
Un esqueleto predice la forma del contenido final con un layout provisional, así que el usuario empieza a orientarse antes de que lleguen los datos. Un spinner solo indica que algo está pasando, sin forma, sin estructura, sin vista previa. Los esqueletos reducen la espera percibida. Los spinners no.
¿Cuándo debo usar UI optimista frente a una respuesta en streaming?
UI optimista cuando la acción del usuario es el trabajo, como añadir un issue, cambiar un estado o mover una tarjeta. Streaming cuando el servidor hace el trabajo y el resultado tiene cadencia natural, como la generación de texto, la salida de un log o un pipeline de deploy. Los dos se combinan.
¿Alguna vez está bien lanzar un spinner sin más?
Solo como fallback de menos de un segundo, solo cuando el layout es realmente impredecible y solo con una razón de marca. Un esqueleto, una línea de estado o una superficie en streaming le gana al spinner en todas las métricas de rendimiento percibido. Por defecto, el spinner va el último.
Diseña la espera, lanza el producto
La espera es la pantalla que el usuario ve más. La impresión de marca que recibe con más frecuencia, la señal de confianza que lee más a menudo y la prueba de rendimiento percibido que ejecuta en cada carga de página. Un equipo que diseña el dashboard durante seis semanas y el estado de carga durante una tarde está repartiendo mal el trabajo respecto a donde el usuario realmente vive.
Si quieres un equipo que diseñe los estados de carga como parte del producto y no como el último sprint antes del lanzamiento, contrata a Brainy. Lanzamos productos donde la espera es parte de la marca y el rendimiento percibido supera al rendimiento literal.
Want a product where the loading states sell instead of apologize? Brainy designs perceived-performance systems and loading surfaces as part of the product, not as the last sprint before launch.
Get Started
