O estado de carregamento é o produto

Some todos os estados de carregamento que seu produto exibe em um ano. Todo usuário, toda sessão, todo refresh. Esse número, em horas de usuário, é a tela mais assistida que você entrega. A maioria dos times trata isso como se ninguém estivesse olhando.

O dashboard passa por revisão de design. O estado vazio, se você leu estados vazios são o produto, passa por revisão de design. O estado de carregamento ganha um spinner de 16 pixels de uma folha de estilos de 2012 e uma oração. É a única tela que o usuário sempre vê, e a que ninguém desenha.

O estado de carregamento é uma impressão de marca

Todo estado de carregamento é um contrato de confiança. O produto está dizendo ao usuário: "Estou trabalhando, não travei, a espera é de propósito." O que a tela disser a seguir vira a forma como a marca lida com pressão.

Os estados de carregamento do Linear têm cara de Linear. Linhas skeleton no formato da lista de issues, criação inline que confirma antes de o servidor responder, transições de marca com cadência deliberada. Os do Stripe têm cara de Stripe. O shimmer do botão de pagamento, os skeletons em formato de card no dashboard, o recibo se resolvendo no estado final. Os dois tratam a espera como o produto.

A versão ruim é o gif girando herdado sobre fundo branco. Sem forma de conteúdo, sem sinal de progresso, sem marca. Ao usuário se diz: "ficamos ocupados e esquecemos que você estava aqui." Isso é uma impressão de marca. Só não é a que o time queria entregar.

Os cinco arquétipos de estado de carregamento

A maioria dos times trata "estado de carregamento" como um único problema de design. São cinco. Cada um serve a um tipo de espera e falha por um motivo diferente.

1. Skeleton screen

Um layout placeholder que espelha a forma do conteúdo final. Linhas onde haverá linhas, cards onde haverá cards. O olho se fixa na estrutura antes de o conteúdo chegar, e a espera parece algo se resolvendo, não começando.

A lista de issues do Linear entrega skeletons em formato de linha que batem com a lista final no pixel. O Stripe Dashboard entrega skeletons em formato de card na seção de métricas que se resolvem nos cards preenchidos. O Notion entrega placeholders em formato de bloco que viram blocos reais quando o documento carrega. Mesma promessa: a forma do carregamento prevê a forma final.

Use quando a estrutura é conhecida. Evite quando o layout é dinâmico o bastante para o skeleton mentir sobre o que vem a seguir.

2. UI otimista

Renderize a ação do usuário imediatamente, antes de o servidor confirmar. Reconcilie em segundo plano. Se o servidor concorda, a UI não pisca. Se discorda, a UI faz rollback com um caminho de desfazer visível.

A criação inline de issues do Linear é o padrão-ouro. Aperte C, digite um título, dê enter, e a issue já está na lista antes de a ida e volta terminar. O cursor e os movimentos de seleção do Figma são otimistas durante toda a sessão multiplayer. O usuário nunca sente a rede.

Use quando a falha é rara e reversível. Evite quando a ação é destrutiva ou o usuário precisa da resposta do servidor para seguir.

3. Streaming parcial

Renderize o primeiro pedaço enquanto o resto ainda está na rede. A espera desaparece dentro do resultado porque o usuário já está consumindo a saída.

O stream de tokens do Claude é o exemplo mais limpo em produção, com uma cadência suavizada que lê em velocidade humana. O Cursor faz stream do diff token por token, então o usuário está lendo código antes de o modelo terminar de escrever. A Vercel faz stream do log de deploy ao vivo, então o usuário está assistindo ao build, não esperando por ele. O texto sobre design para latência de IA cobre a estratégia de latência de forma mais ampla.

Use quando o resultado tem uma cadência natural. Evite quando os pedaços não são úteis isoladamente.

4. Progresso como conteúdo

A espera em si é o valor. O log de deploy, o pipeline de build, o rastro de raciocínio do agente. O usuário não está esperando pelo resultado. Ele está lendo o resultado.

A tela de deploy da Vercel é o exemplo canônico. O log de deploy é o estado de carregamento, e a tela mais entregue da plataforma. O GitHub Actions faz o mesmo com a saída passo a passo da execução. O painel de agente do Cursor mostra o rastro de raciocínio enquanto trabalha, então uma tarefa de vários minutos parece ter propósito em vez de travada. v0 e Lovable entregam isso em superfícies de prompt para app, onde o streaming do build é o estado de carregamento e o preview é a recompensa.

Use quando a espera é o valor. Evite quando os passos não servem a um usuário que só se importa com o estado final.

5. Spinner de marca

O micro-pulso, o gradiente, o shimmer. O momento em que o produto ganha um token de personalidade. O shimmer do botão de pagamento do Stripe, a barra de progresso em gradiente da Vercel, o micro-pulso do Linear em esperas de transição. Nenhum deles faz o trabalho sozinho. Eles vão por cima de um dos quatro primeiros padrões, adicionando polimento de marca a uma espera que já tem estrutura.

Use quando a espera é curta e a superfície é de alto risco. Evite quando não há skeleton nem stream por trás. Um spinner de marca sem um dos quatro primeiros padrões por baixo é um spinner de 1996 com um hex de 2026.

Skeletons vencem spinners quase sempre

Um skeleton prevê a forma do que está chegando. Um spinner só sinaliza que algo está acontecendo em algum lugar. Mesma espera, duas experiências diferentes.

O skeleton do dashboard do Stripe é mal mais rápido no relógio do que uma versão com spinner, mas a diferença de velocidade percebida é muito maior. O usuário vê um layout em formato de card e começa a se orientar antes de os dados chegarem. Quando as métricas se resolvem, o olho já está em posição. Com um spinner, o usuário fica encarando o centro da tela esperando permissão para olhar para qualquer outro lugar. Se você consegue prever o layout, entregue um skeleton. Se não consegue, entregue uma linha de status.

UI otimista é o código de trapaça

A espera fica invisível porque a ação é confirmada antes de a espera começar.

O Linear entregou otimismo em todo lugar. Criar issue, mudar status, trocar responsável, adicionar label, mover de ciclo. Cada um escreve no store local na intenção e reconcilia depois que o servidor responde. O multiplayer do Figma é otimista em movimentos de cursor, seleção e na maioria das edições. O Notion é otimista nas edições de documento. Cada produto parece software local porque a rede foi escondida sob a camada otimista.

Duas coisas fazem isso funcionar. A falha precisa ser rara e reversível, ou a UI pisca e o usuário para de confiar. E os erros precisam ser visíveis. Uma ação otimista que engole um erro do servidor em silêncio é pior do que nenhum otimismo, porque ensina ao usuário que a ação funcionou quando não funcionou. Toda escrita otimista precisa de um desfazer, um toast ou um rollback que o usuário consiga ver.

Cinco regras para ótimos estados de carregamento

Acerte quatro de cinco e a espera parece desenhada. Acerte três e o estado de carregamento começa a parecer um detalhe esquecido.

1. A forma do carregamento prevê a forma final. Linhas skeleton para linhas, cards skeleton para cards. Sem salto de layout quando o conteúdo se resolve.
2. A espera ganha conteúdo sempre que possível. Faça stream dos tokens, entregue o log, renderize o parcial. Um usuário lendo não está esperando.
3. Toda espera acima de 800ms recebe feedback. Abaixo de 800ms, uma transição limpa basta. Acima disso, o usuário precisa de um sinal de que o sistema está vivo, nem que seja uma divulgação progressiva de estrutura primeiro, conteúdo depois.
4. Ações otimistas precisam de um caminho de desfazer visível. Um toast, um rollback, um estado de erro claro. Otimismo sem recuperação é gaslighting.
5. Nenhum spinner sem motivo de marca. Spinners de marca vão por cima de um dos quatro primeiros padrões, nunca os substituem. Se a única coisa na tela é o spinner, o design não está pronto.

O contexto mais profundo está na análise mais ampla de princípios de web design e em como os core web vitals tratam o layout shift como falha de performance percebida.

Antipadrões que matam estados de carregamento

Seis modos de falha aparecem mais do que deveriam. Cada um tem conserto, e cada um está em produção em algum lugar agora.

O spinner indefinido sem progresso. Um spinner rodando há quinze segundos sem nenhum sinal. O usuário não sabe se a requisição está viva, morta ou travada. Troque por uma linha de status, uma barra de progresso ou uma superfície de streaming.

O modal que bloqueia a página e não pode ser dispensado. Um modal de carregamento que sequestra a tela inteira e não deixa o usuário rolar, copiar ou ler o resto do produto. A espera vira sequestro.

O layout que pula quando o skeleton se resolve. Um skeleton que não bate com o layout real. Linhas se deslocam, cards se reorganizam, o header se move. O skeleton não é outro design, é o mesmo design sem conteúdo.

O texto "Carregando..." em loop eterno. Três pontinhos girando, sem progresso, sem status. O usuário aprende em duas sessões a ignorar, o que mata o canal para qualquer status real que a superfície entregue depois.

A UI otimista que engole erros em silêncio. A ação é confirmada na UI, o servidor falha, o produto nunca avisa o usuário. A solução é um toast visível, um botão de desfazer ou um rollback.

Spinners de marca em uma espera de 100ms. Um shimmer para uma espera que acaba antes de o usuário notar. Puro overhead. Superfícies rápidas merecem um fade. Superfícies lentas merecem uma estrutura.

Projetar fricção de propósito cobre os raros casos em que uma espera deve ser visível de forma deliberada. Estados de carregamento não são esses. São as esperas que deveriam ser invisíveis, desenhadas ou transformadas em conteúdo.

A auditoria de estados de carregamento

Seis perguntas. Passe toda superfície de carregamento por elas antes do próximo release.

1. A forma do carregamento prevê a forma final? Skeletons para layouts previsíveis, linhas de status para os imprevisíveis. Sem salto de layout na resolução.
2. A espera carrega informação? Um skeleton, um stream, um log de progresso, uma linha de status. Qualquer espera acima de 800ms sem nada nela é um vazamento.
3. Existe uma única mensagem principal por espera? "Carregando dashboard" vence quatro sinais sobrepostos. Um sinal, com a hierarquia visual fazendo o trabalho.
4. O estado de carregamento combina com a voz da marca? Leia o texto de carregamento ao lado da tela preenchida. Se o tom muda, o estado de carregamento está vestindo outra marca.
5. As ações otimistas são reversíveis e visíveis na falha? Toda escrita otimista tem um desfazer, um toast ou um rollback. Nada de falhas silenciosas.
6. A tela de carregamento venderia o produto para um estranho? Se a única tela que ele já viu fosse o estado de carregamento, pareceria o produto em que ele se cadastrou? Se não, a tela mais assistida do seu app também é a pior desenhada.

Um produto em que todo estado de carregamento passa nessas seis parece rápido até em rede lenta.

Escolha o padrão, depois entregue a espera

Estados de carregamento não são a camada de polimento. São a camada de marca, a camada de confiança e a camada de performance percebida comprimidas na tela que o usuário vê mais do que qualquer outra. Toda espera é uma escolha de design, o time tendo feito uma de propósito ou não.

Skeleton onde a estrutura é conhecida. Otimista onde a falha é reversível. Streaming onde o resultado tem cadência. Progresso como conteúdo onde a espera é o valor. Spinner de marca só quando os quatro primeiros já estão fazendo seu trabalho. A análise de princípios de design de landing page é a versão para páginas de marketing dessa disciplina.

Pare de tratar o estado de carregamento como um pedido de desculpas por ser lento. No acumulado, ele é o produto. Faça a espera valer o tempo deles.

FAQ

Qual é a diferença entre um skeleton screen e um spinner de carregamento?

Um skeleton prevê a forma do conteúdo final com um layout placeholder, então o usuário começa a se orientar antes de os dados chegarem. Um spinner só sinaliza que algo está acontecendo, sem forma, sem estrutura, sem prévia. Skeletons reduzem a espera percebida. Spinners não.

Quando devo usar UI otimista em vez de uma resposta em streaming?

UI otimista quando a ação do usuário é o trabalho, como adicionar uma issue, alternar um status ou mover um card. Streaming quando o servidor faz o trabalho e o resultado tem cadência natural, como geração de texto, saída de log ou um pipeline de deploy. Os dois se combinam.

Algum dia é aceitável entregar um spinner simples?

Só como fallback abaixo de um segundo, só quando o layout é genuinamente imprevisível e só com um motivo de marca. Um skeleton, uma linha de status ou uma superfície de streaming vence o spinner em toda métrica de performance percebida. O padrão é spinner por último.

Desenhe a espera, entregue o produto

A espera é a tela que o usuário mais vê. A impressão de marca que ele mais recebe, o sinal de confiança que ele mais lê e o teste de performance percebida que ele roda a cada carregamento de página. Um time que desenha o dashboard por seis semanas e o estado de carregamento por uma tarde está entregando a proporção errada de trabalho para o lugar onde o usuário realmente vive.

Se você quer um time que desenha estados de carregamento como parte do produto em vez de a última sprint antes do lançamento, contrate a Brainy. Entregamos produtos em que a espera faz parte da marca e a performance percebida vence a performance literal.