Contexto
O botão “Tentar novamente” é útil quando a falha pode ser temporária e repetir a operação tem chance real de concluir a tarefa. Ele não deve ser uma resposta automática para qualquer erro.
Uma boa recuperação combina explicação breve, preservação do estado, uma ação clara e um limite para novas tentativas. Quando a operação pode ter sido concluída, o sistema deve primeiro permitir consultar o resultado ou usar um mecanismo que evite duplicidade.
Ofereça “Tentar novamente” quando a causa for provavelmente transitória, como uma interrupção de conexão, tempo esgotado ou indisponibilidade momentânea. Não use o mesmo botão para corrigir dados inválidos ou resolver uma permissão ausente.
Explique o que falhou e o que a tentativa fará. “Não foi possível carregar os resultados. Tente novamente” é mais útil do que “Erro inesperado”. Se houver espera recomendada, informe-a antes de repetir.
Preserve os dados, filtros, posição e progresso da tarefa. Ao ativar a tentativa, mostre um estado de processamento, impeça cliques duplicados e comunique quando a operação terminar ou falhar novamente.
Depois de uma ou poucas tentativas sem sucesso, ofereça uma saída: verificar a conexão, consultar o status, voltar, salvar localmente ou procurar ajuda. Evite um ciclo sem fim de tentativas idênticas.
Para ações que criam, pagam, enviam ou excluem algo, confirme o resultado antes de repetir ou use idempotência no serviço. Uma falha de comunicação pode significar que a operação foi concluída, mesmo sem resposta visível.
Porque isso importa?
Uma falha sem caminho de recuperação transforma um problema temporário em um beco sem saída. A ação de tentar novamente reduz esse bloqueio quando é previsível, segura e compreensível.
Baymard relaciona mensagens específicas, preservação de dados e recuperação guiada a uma menor fricção em formulários e checkout. Design Systems como Adobe Spectrum, Material e Carbon convergem ao recomendar uma ação contextual, curta e única — mas não tratam “tentar novamente” como solução universal.
O risco está em repetir uma operação que pode gerar cobrança, duplicar registros ou apagar dados. Nesses casos, a interface precisa distinguir “a resposta não chegou” de “a operação falhou” e conduzir a pessoa para verificar o estado antes de reenviar.
Quando usar?
- Quando a causa pode ser temporária.
- Quando a repetição é segura.
- Quando a operação não foi concluída.
- Quando o estado pode ser preservado.
- Quando há feedback durante a nova tentativa.
- Quando existe uma saída após novas falhas.
Quando evitar?
- Quando o dado está inválido.
- Quando falta permissão.
- Quando a ação pode duplicar efeitos.
- Quando a causa exige outra correção.
- Quando a tentativa falhará sempre.
- Quando não há alternativa ao loop.
Recomendações
Faça
- Explique a falha.
- Use uma ação clara.
- Preserve o estado.
- Mostre o processamento.
- Evite duplicidade.
- Ofereça uma saída.
Evite
- Não repita sem critério.
- Não limpe os dados.
- Não use “Erro” sozinho.
- Não permita cliques duplicados.
- Não crie um loop infinito.
- Não masque uma ação concluída.
