Contexto
Quando uma resposta demora, a pessoa precisa entender se o sistema está trabalhando, quanto já avançou e o que pode fazer enquanto espera. O tratamento deve considerar duração esperada, progresso mensurável, escopo afetado e possibilidade de continuar sem bloqueio.
Escolha o indicador pelo tipo de espera e pelo escopo afetado. Para uma espera curta, evite fazer o indicador piscar. Para uma espera variável, use um estado indeterminado e contextualizado. Quando o avanço puder ser calculado, mostre progresso determinado. Em tarefas longas, preserve o trabalho e permita continuar em segundo plano, cancelar ou recuperar o resultado quando isso for seguro.
Em operações com menos de um segundo, normalmente não exiba um indicador para evitar um flash. Entre um e três segundos, use carregamento indeterminado e localizado se a espera for perceptível.
Acima de três segundos, prefira progresso determinado quando houver uma estimativa confiável. Caso contrário, mantenha o estado indeterminado com contexto. Acima de dez segundos, evite um spinner indefinido: informe o estado, preserve a tarefa e, quando possível, permita continuar, cancelar ou acompanhar depois.
Use skeleton quando a estrutura do conteúdo for conhecida e as partes puderem aparecer gradualmente. Substitua o carregamento por sucesso, erro ou cancelamento assim que o estado mudar.
Em envios, impeça cliques duplicados sem apagar dados nem esconder o estado da operação.
Base da recomendação
Os intervalos são heurísticas cruzadas de NN/g, Primer e Carbon, não limites universais. Baymard fornece evidência contextual de impaciência e cliques repetidos em fluxos lentos; o W3C define como comunicar mensagens de status sem exigir mudança de foco.
Porque isso importa?
Sem feedback, uma espera parece falha ou travamento. A pessoa pode repetir o clique, abandonar a tarefa ou perder a confiança no resultado.
A NN/g relaciona indicadores dinâmicos à redução da incerteza e à maior tolerância à espera. Em testes de checkout, a Baymard observou impaciência e cliques repetidos quando etapas demoravam vários segundos sem indicar que o sistema estava trabalhando. Um indicador claro não torna o processo mais rápido, mas ajuda a pessoa a decidir se deve esperar, continuar ou tentar outra ação.
O estado também precisa ser comunicado a tecnologias assistivas sem mover o foco. Quando existe avanço real, a porcentagem pode informar a situação; quando não existe, um status curto e atualizado é mais apropriado.
Quando usar?
- Buscas, filtros ou carregamento de dados que podem levar mais que alguns segundos.
- Envios, salvamentos, importações, exportações e cálculos demorados.
- Operações cujo tempo varia conforme a rede, o volume de dados ou um serviço externo.
- Processos que podem continuar em segundo plano sem impedir a tarefa principal.
Quando evitar?
- Operações tão rápidas que o indicador apenas pisca.
- Spinner indefinido sem contexto, saída ou estado de erro.
- Vários indicadores competindo na mesma tela.
- Overlay de página inteira para uma área pequena.
- Porcentagem que parece precisa, mas não representa avanço real.
- Skeleton usado quando não se conhece a estrutura do conteúdo.
Recomendações
Faça
- Indique o escopo da espera.
- Mostre progresso mensurável.
- Preserve contexto e dados.
- Ofereça recuperação.
Evite
- Spinner sem explicação.
- Bloqueio desnecessário.
- Cliques duplicados.
- Promessas de tempo imprecisas.
