Contexto
Uma falha temporária acontece quando o sistema, uma rede ou um serviço externo não consegue concluir uma operação naquele momento, embora a pessoa possa tentar novamente depois. Ela é diferente de um erro no preenchimento: o problema não está necessariamente nos dados fornecidos.
A mensagem precisa reduzir duas dúvidas: o que aconteceu e o que é seguro fazer agora. Antes de oferecer “Tentar novamente”, informe se a operação foi concluída, está em processamento ou não foi realizada. Isso evita envios duplicados, pagamentos repetidos e perda de confiança.
Explique a falha em linguagem de tarefa, sem expor detalhes técnicos desnecessários. Diga o que não foi possível fazer e, quando puder, delimite o alcance: “Não foi possível carregar seus pedidos” é mais útil do que “Ocorreu um erro”.
Informe o estado da operação antes de sugerir uma ação. Se o servidor não confirmou o resultado, prefira “Não foi possível confirmar o envio” e oriente a verificar o histórico antes de repetir. Se a operação não começou ou pode ser repetida com segurança, ofereça uma única ação principal, como “Tentar novamente”.
Preserve o que a pessoa já digitou, selecionou ou anexou. Mantenha o contexto da tarefa e permita continuar de onde parou. Se o problema for amplo ou persistente, ofereça uma alternativa concreta: voltar mais tarde, consultar o status, usar outro canal ou falar com suporte.
Escolha o formato conforme o alcance e o impacto. Use mensagem inline junto ao conteúdo afetado para uma falha localizada; uma mensagem persistente ou página de indisponibilidade para um serviço inteiro; e uma notificação temporária apenas quando a falha for breve, clara e recuperável sem registro.
Quando houver um incidente em andamento, atualize a informação sem prometer um prazo que a equipe não conhece. Registre o erro para correção operacional, mas mostre à pessoa somente o contexto e a ação que ela consegue compreender e executar.
Porque isso importa?
Falhas temporárias interrompem uma expectativa já criada: a pessoa acredita que a tarefa avançou, mas o sistema não confirma o resultado. Uma mensagem genérica aumenta a incerteza e pode levar a tentativas repetidas, abandono ou duplicação de operações.
A Nielsen Norman Group trata mensagens hostis como aquelas que transferem para a pessoa o trabalho de interpretar o problema. Para falhas do sistema, a interface deve explicar a situação em termos compreensíveis e indicar uma saída possível, sem transformar um problema técnico em culpa do usuário.
O W3C inclui avisos sobre a existência de erros e estados do aplicativo no conceito de mensagem de status. Essas alterações precisam ser identificáveis por tecnologias assistivas sem deslocar o foco. O Baymard também observa, em testes de checkout, que recuperação clara, preservação dos dados e orientação específica reduzem o esforço quando algo dá errado.
Quando usar?
- Quando uma operação falha por rede ou servidor.
- Quando um serviço externo está indisponível.
- Quando o sistema precisa de nova tentativa.
- Quando o resultado ainda não foi confirmado.
- Quando uma falha afeta uma área inteira.
- Quando há alternativa para continuar.
Quando evitar?
- Quando o problema está nos dados do campo.
- Quando a operação ainda está processando.
- Para esconder uma falha permanente.
- Para oferecer tentativas sem limite.
- Para mostrar código técnico sem contexto.
- Para prometer prazo desconhecido.
Recomendações
Faça
- Explique o que falhou.
- Informe o estado da operação.
- Preserve os dados.
- Ofereça uma ação segura.
- Mantenha o contexto.
- Mostre uma alternativa.
- Permita consultar o status.
- Atualize incidentes ativos.
Evite
- Não culpe a pessoa.
- Não diga apenas “Erro”.
- Não repita uma operação incerta.
- Não apague o preenchimento.
- Não use jargão técnico.
- Não prometa prazo incerto.
- Não limite a uma cor.
- Não esconda a recuperação.
