Contexto
O feedback do sistema precisa aparecer no lugar e no momento certos. Toast, alerta e mensagem inline não são variações visuais da mesma coisa: cada padrão tem um escopo, uma duração e uma necessidade de interação diferente.
Use toast para mensagens breves e não bloqueantes, como confirmação de uma ação concluída ou uma atualização de baixo impacto.
Use mensagem inline quando o feedback estiver ligado a um campo, item, formulário ou seção específica. Ela deve permanecer disponível até o problema ser resolvido ou dispensado.
Use alerta persistente quando a informação afetar a página, o serviço ou uma parte ampla da experiência e precisar continuar visível. Se houver uma ação necessária, ela deve ser clara e acessível.
Porque isso importa?
Um toast que desaparece pode esconder um erro que exige correção. Uma mensagem inline distante do campo pode dificultar a compreensão. Um alerta persistente usado para qualquer evento cria excesso de interrupções e reduz a atenção das pessoas.
A escolha correta ajuda a pessoa a entender o que aconteceu, qual parte da interface foi afetada e o que fazer em seguida.
Base da recomendação
Esta orientação cruza quatro tipos de fonte: pesquisa de usabilidade da Baymard sobre validação e recuperação de erros em formulários; heurísticas de usabilidade do Nielsen Norman Group sobre visibilidade do status do sistema e recuperação de erros; critérios de acessibilidade do W3C; e padrões de implementação do Carbon, Gov.br e Adobe Spectrum.
Há convergência em um ponto: o feedback deve ser relevante, oportuno, contextual e suficiente para indicar o próximo passo. A escolha entre toast, mensagem inline e alerta depende do escopo e da consequência da informação.
O limite da evidência também é importante: a pesquisa da Baymard consultada é focada em formulários e checkout, portanto sustenta diretamente mensagens inline e validação, mas não transforma essa conclusão em uma regra para todos os tipos de notificação. Os Design Systems mostram soluções implementáveis, não provas universais de que um padrão funcionará em qualquer produto.
Quando usar?
- Use toast para sucesso, informação breve e ações de baixo impacto.
- Use mensagem inline para erros, validações e orientações ligadas a um elemento.
- Use alerta persistente para condições que afetam uma página ou serviço.
- Mantenha mensagens com ação disponíveis até a ação ser realizada.
- Ofereça um caminho alternativo para consultar mensagens que desaparecem.
- Use modal somente quando a situação realmente exigir bloqueio ou decisão imediata.
Quando evitar?
- Não use toast para erros que exigem correção.
- Não esconda uma informação crítica em uma mensagem temporária.
- Não use mensagem inline para um problema que afeta toda a página.
- Não use alerta persistente para feedback rotineiro.
- Não empilhe várias mensagens sem prioridade clara.
- Não dependa apenas de cor ou ícone.
Recomendações
Faça
- Relacione a mensagem ao elemento afetado.
- Explique o que aconteceu.
- Mostre o próximo passo.
- Mantenha textos curtos.
- Preserve mensagens que exigem ação.
- Permita consultar mensagens importantes depois.
Evite
- Não use toast para tudo.
- Não faça erro importante desaparecer.
- Não coloque mensagem longe do problema.
- Não repita o mesmo aviso em vários lugares.
- Não use texto genérico.
- Não interrompa sem necessidade.
