Uma mensagem de erro aparece quando alguém tenta concluir uma tarefa e algo impede essa ação. Se ela apenas informa que houve um problema, a pessoa fica sem saber se deve corrigir um dado, esperar, tentar novamente ou pedir ajuda. Para as equipes de produto e tecnologia, o objetivo não é disfarçar a falha: é ajudar a decidir o próximo passo e evitar que a pessoa perca o trabalho ou repita uma ação com consequências.
Criar mensagens úteis exige conhecer a origem do erro, as informações que ainda estão disponíveis e as opções de recuperação. Também é necessário alinhar o texto ao comportamento real da aplicação. Uma instrução como “Tente novamente” pode ser prejudicial se a operação já foi concluída ou se repeti-la pode criar uma duplicidade.
Classifique o erro antes de redigir a mensagem
Comece identificando o que impede a conclusão da tarefa e quem pode resolver o problema. Essa classificação ajuda a escolher tanto o conteúdo quanto a ação disponível:
- Erro que a pessoa pode corrigir: falta um campo obrigatório, o formato de um dado é inválido ou uma seleção não atende a determinada condição. Explique o que deve ser verificado e indique o campo específico.
- Problema temporário no sistema: a aplicação não consegue concluir uma operação devido a uma falha ou condição transitória. Informe se convém esperar ou tentar novamente e o que acontecerá com os dados.
- Dependência externa: um serviço conectado não responde ou recusa a solicitação. Não atribua a causa à pessoa nem prometa quando o problema será resolvido. Comunique o que a aplicação sabe e ofereça uma alternativa viável.
- Situação que exige assistência: a pessoa não consegue resolver o bloqueio pela interface ou o caso requer uma verificação. Informe como entrar em contato com o suporte e quais dados úteis deve fornecer.
Não é necessário expor a arquitetura técnica para fazer essa distinção. Porém, é preciso combinar com a equipe de desenvolvimento qual foi o estado da operação, se as alterações foram salvas e se é seguro repeti-la. Sem essas informações, a equipe de conteúdo não pode oferecer instruções confiáveis.
Explique a causa, o impacto e o próximo passo
Uma mensagem prática responde, em linguagem cotidiana, a três perguntas: o que aconteceu, o que isso significa e o que a pessoa pode fazer agora. Se for relevante, informe também se os dados foram preservados. Não é necessário explicar todos os detalhes internos; basta fornecer contexto suficiente para que a pessoa possa agir.
Por exemplo, “Não foi possível salvar o formulário porque falta o telefone. Adicione um número no campo Telefone e salve novamente” identifica o resultado, o motivo e como corrigir o problema. Já “Erro ao processar a solicitação” não indica onde agir. Para um problema temporário, uma mensagem como “Não foi possível carregar seus resultados. Seus filtros continuam disponíveis; tente novamente” só ajuda se a interface realmente preservar esses filtros.
Verifique cada texto em relação ao estado real do produto. Se não puder confirmar que os dados foram salvos, não diga que estão seguros. Se não souber a causa, não a invente: comunique o resultado e uma ação segura. Uma explicação limitada e precisa é melhor do que uma promessa tranquilizadora que a aplicação não pode cumprir.
Escolha uma forma de recuperação que não piore o problema
A ação sugerida deve corresponder ao tipo de falha e às consequências de repetir a operação. Antes de exibir um botão ou uma instrução, responda a estas perguntas:
- A pessoa pode corrigir o problema? Se sim, direcione a atenção ao campo ou à decisão que precisa de alteração e preserve o restante sempre que possível.
- É seguro tentar novamente? Se a operação pode ter sido concluída mesmo que a interface não confirme isso, não ofereça uma nova tentativa às cegas. Verifique o estado ou explique como conferi-lo.
- É possível continuar por outro caminho? Se houver uma alternativa funcional, como salvar um rascunho ou concluir o processo mais tarde, deixe-a visível sem ocultar a opção principal.
- É necessário entrar em contato com o suporte? Informe um canal disponível e, se for útil, um identificador de referência. Não faça do contato a única saída quando a pessoa puder resolver o problema por conta própria.
Em operações sensíveis — por exemplo, enviar um pedido, realizar um pagamento ou publicar conteúdo — combine com a equipe de desenvolvimento como o resultado será confirmado e como evitar a repetição de ações. A mensagem exibida deve refletir esse comportamento; o texto, por si só, não pode garantir que uma operação seja segura.
Escreva com clareza e sem culpar
Escreva para a pessoa que está tentando concluir uma tarefa, não para quem está depurando o sistema. Evite códigos internos, nomes de componentes e expressões como “solicitação inválida” quando elas não explicam o que precisa ser corrigido. Um código pode ser útil para o suporte, mas deve acompanhar uma explicação compreensível, nunca substituí-la.
Use uma voz direta e neutra. “Não foi possível validar o endereço” descreve o resultado sem acusar ninguém. “Você informou o endereço errado” atribui a falha à pessoa e pode estar incorreto: talvez o formato esperado não esteja claro. Evite também instruções vagas, como “Verifique seus dados”, quando puder indicar qual dado precisa de atenção.
Ser breve ajuda, mas não se deve omitir uma consequência importante. Se uma resposta foi apagada, se o processo continua pendente ou se a pessoa pode tentar de novo sem criar duplicidades, informe isso. Quando não souber qual dessas situações se aplica, interrompa a redação e peça à equipe técnica que defina o estado.
Faça com que a mensagem seja percebida e possa ser usada
O texto deve aparecer perto do elemento afetado ou em um local coerente com o alcance do problema. Um erro em um campo costuma ser mais útil junto a esse campo do que em um aviso distante. Se a tarefa inteira estiver bloqueada, uma mensagem geral pode explicar a situação e oferecer uma ação principal. Não dependa apenas da cor para comunicar que algo deu errado: inclua texto que identifique o problema.
Verifique se a mensagem pode ser compreendida com o teclado e com tecnologias assistivas e se a pessoa consegue localizar o campo relacionado sem ter de adivinhar. Em formulários, confira se o erro continua visível depois que o dado é corrigido e se o foco ou a navegação permitem prosseguir. Acessibilidade não se resolve apenas com uma frase correta se o aviso não chega a quem precisa dele.
O momento também importa: um aviso que desaparece antes de poder ser lido, ou que aparece antes de a pessoa terminar de digitar, pode aumentar a confusão. Valide o comportamento na interface real e nos estados relevantes, não apenas o texto em um documento.
Documente e valide uma matriz de erros
Para evitar respostas diferentes para a mesma falha, crie uma matriz compartilhada entre produto, design, desenvolvimento e atendimento ao cliente. Inclua pelo menos:
- Nome do estado e origem conhecida do problema.
- Tarefa que a pessoa estava realizando e alcance do impacto.
- Dados preservados, descartados ou ainda pendentes de confirmação.
- Texto exibido, localização e ação disponível.
- Responsável por confirmar o comportamento e critério para encaminhar o caso ao suporte.
Priorize os erros que bloqueiam tarefas importantes, podem causar perda de dados ou geram consultas recorrentes. Teste as mensagens em tarefas reais: observe se a pessoa entende o que aconteceu, encontra o próximo passo e consegue prosseguir sem instruções externas. Registre em que ponto ela desiste ou tenta novamente, junto com as consultas recebidas pelo suporte, e compare esses sinais antes e depois das mudanças. Uma redução nas consultas, por si só, não comprova que o problema foi resolvido: pode significar que as pessoas deixaram de tentar concluir a tarefa.
Revise a matriz quando o fluxo, as dependências ou a lógica de salvamento mudarem. A qualidade de uma mensagem não se mede pelo tom simpático, mas pela precisão com que descreve o estado e pela possibilidade de agir. Quando o produto ainda não conhece o resultado, a melhor decisão pode ser evitar uma nova tentativa automática, explicar a incerteza e oferecer uma forma segura de verificar o que aconteceu ou pedir assistência.