Quanto tempo uma notificação temporária deve permanecer

Defina a duração de uma notificação temporária conforme o conteúdo, a urgência, a ação esperada e a possibilidade de consultar a informação depois.

Wireframe de uma notificação temporária com indicador de tempo e histórico persistente.
Nível de impácto
Médio
Status
Usar com atenção
Nível de evidênica
Evidência moderada

Contexto

Notificações temporárias existem para dar um retorno breve sem interromper o fluxo. O tempo de exibição é uma decisão de UX, não um número universal: deve considerar o tamanho da mensagem, a urgência, a ação esperada, o dispositivo e a possibilidade de consultar o conteúdo depois.

Use uma duração curta apenas para mensagens breves e de baixa consequência. Como ponto de partida, teste entre 4 e 10 segundos e ajuste com base no conteúdo e no comportamento real das pessoas.

Se a mensagem tiver uma ação, como desfazer, tentar novamente ou revisar algo, mantenha-a disponível até a ação ser realizada ou dispensada. Nesse caso, prefira um padrão persistente.

Se a informação for importante, ofereça outra forma de consultá-la depois, como uma área de notificações, um estado persistente na página ou um registro da atividade.

Mostre uma notificação por vez quando houver uma sequência de mensagens. Evite que uma nova mensagem reinicie ou esconda o tempo de leitura da anterior.

Mensagem da Atlassian informando que a sessão expirou e oferecendo o link Login
Exemplo real — Atlassian Design: a mensagem informa que a sessão foi encerrada por inatividade e oferece a ação Login. Como há uma consequência e uma ação necessária, esse tipo de aviso deve permanecer disponível até a pessoa agir ou fechá-lo. Fonte: Atlassian Design — Info messages — https://atlassian.design/foundations/content/designing-messages/info-messages

Porque isso importa?

Uma mensagem que desaparece cedo demais pode ser perdida por pessoas que precisam de mais tempo para ler, localizar ou compreender o conteúdo. Uma mensagem que permanece por tempo excessivo pode cobrir controles, distrair e aumentar a carga cognitiva.

O problema é maior quando a notificação é a única forma de saber o que aconteceu ou quando contém a única ação para corrigir o problema. A duração precisa preservar o acesso à informação sem transformar cada feedback em uma interrupção.

Base da recomendação

Esta orientação combina um critério normativo do W3C sobre limites de tempo, orientações de acessibilidade do Carbon, comportamentos documentados por Material e Atlassian e princípios de feedback oportuno do Nielsen Norman Group e da Interaction Design Foundation.

As fontes convergem em que mensagens temporárias devem ser breves, pouco interruptivas e usadas para situações de baixa consequência. Quando existe uma ação, um erro importante ou uma informação que só está disponível na notificação, o conteúdo precisa permanecer acessível por outro caminho ou até a pessoa agir.

Não há base para tratar 4–10 segundos como uma lei de UX. Esse intervalo é uma referência de implementação de alguns sistemas e deve ser validado com o conteúdo, o dispositivo, a leitura assistiva e testes com usuários. Por isso, este artigo é classificado como evidência moderada: há forte convergência normativa e de padrões, mas não um tempo universal comprovado experimentalmente.

  • Use duração automática para sucesso simples e de baixo impacto.
  • Use duração automática para informação curta sem ação obrigatória.
  • Comece testando entre 4 e 10 segundos para textos curtos.
  • Aumente o tempo quando o conteúdo exigir mais leitura.
  • Use permanência quando houver desfazer, tentar novamente ou outra ação.
  • Permita consultar depois o que for relevante.
  • Exiba uma mensagem por vez.
  • Não faça erros importantes desaparecerem.
  • Não temporize a única confirmação de uma ação.
  • Não temporize mensagens com ação necessária.
  • Não use o mesmo tempo para textos diferentes.
  • Não empilhe mensagens concorrentes.
  • Não use toast para conteúdo longo.
  • Não trate 4 ou 10 segundos como regra universal.
Captura do Atlassian Design mostrando uma flag de sucesso que informa fechamento automático em 8 segundos.
Exemplo real: a Atlassian demonstra uma flag temporária que se fecha automaticamente em 8 segundos. Ela é adequada para feedback breve e de baixa consequência; uma mensagem com ação ou consequência deve continuar acessível. Fonte: Atlassian Design — Auto dismiss flag: https://atlassian.design/components/flag/auto-dismiss-flag

Recomendações

Faça

Práticas recomendadas
  • Use o conteúdo para definir o tempo.
  • Comece com 4–10 s para mensagens curtas.
  • Mantenha ações disponíveis.
  • Mostre uma mensagem por vez.
  • Ofereça fechamento manual.
  • Permita consultar depois.
Wireframe de notificação com tempo suficiente, fechamento manual, ação persistente e registro no histórico.
Exemplo correto: a mensagem curta permanece tempo suficiente para leitura, oferece fechamento manual e deixa o resultado importante disponível no histórico; a notificação com ação permanece até a pessoa agir ou dispensá-la.

Evite

Práticas a evitar
  • Não use tempo fixo para tudo.
  • Não faça erro desaparecer.
  • Não esconda a única confirmação.
  • Não empilhe notificações.
  • Não use ação que some.
  • Não interrompa sem necessidade.
Wireframe com notificações longas empilhadas, tempo insuficiente e ausência de histórico persistente.
Exemplo incorreto: mensagens longas, erros e ações importantes usam tempos muito curtos, competem entre si e desaparecem sem deixar uma alternativa de consulta.

Acessibilidade

Não use um temporizador para mensagens críticas, emergenciais ou que exigem uma decisão. Para informações sem ação, use uma região semântica adequada, como status ou log, sem mover o foco. Use uma comunicação mais assertiva apenas quando a urgência justificar.

Se a mensagem contiver uma ação, ela precisa permanecer disponível para teclado e leitor de tela até a ação ser realizada ou dispensada. O foco não deve ser perdido quando a notificação for fechada, e uma mensagem temporária não deve ser o único meio de acessar uma informação importante.

A WCAG 2.2 exige que limites de tempo possam ser desativados, ajustados ou ampliados quando aplicável. Um toast pode desaparecer sem esse mecanismo quando existe uma alternativa equivalente para consultar a mesma informação; sem alternativa, o conteúdo precisa continuar acessível.

Teste o tempo com teclado, zoom, leitor de tela, diferentes tamanhos de texto e configurações de acessibilidade do dispositivo.

Checklist

  • A mensagem é curta?
  • A informação é de baixa consequência?
  • A pessoa não precisa agir?
  • O tempo foi definido pelo conteúdo?
  • O texto pode ser lido antes de desaparecer?
  • Existe alternativa para consultar depois?
  • A ação permanece disponível?
  • Uma nova mensagem não esconde a anterior?
  • O foco e a leitura assistiva foram preservados?
  • O comportamento foi testado com teclado, zoom e leitor de tela?

Referências

Carbon Design System — Notification Pattern. Relaciona prioridade e nível de interrupção ao tipo de notificação e recomenda não usar temporizador para mensagens críticas ou emergenciais. Consultar o padrão de notificações do Carbon.

Carbon Design System — Notification Usage. Explica que toasts são temporários, enquanto notificações inline permanecem até serem dispensadas ou resolvidas; também orienta evitar empilhamento confuso e manter o conteúdo curto. Consultar as orientações de uso do Carbon.

Carbon Design System — Notification Accessibility. Recomenda papéis semânticos adequados, cuidado com temporizadores e disponibilidade por teclado e leitor de tela quando houver ação. Consultar as orientações de acessibilidade do Carbon.

Material Design — Snackbars. Usa de 4 a 10 segundos como referência para snackbars breves, recomenda exibir uma por vez e alerta que a mensagem não deve ser a única forma de acessar uma função essencial. Consultar as diretrizes oficiais de Snackbars.

Android Developers — Snackbar. Documenta durações curta, longa e indefinida e recomenda considerar duração indefinida quando houver um controle de fechamento. Consultar a API oficial de Snackbar.

Atlassian Design — Auto dismiss flag. Documenta um exemplo de mensagem que é dispensada automaticamente após oito segundos, útil como referência de implementação, não como regra universal. Consultar o Auto dismiss flag.

Padrão Digital de Governo — Message. Recomenda evitar mensagens que desaparecem automaticamente, pois podem passar despercebidas; também orienta manter mensagens importantes visíveis. Consultar o componente Message do Gov.br.

W3C — WCAG 2.2, Success Criterion 2.2.1 Timing Adjustable. Explica quando limites de tempo devem ser desativáveis, ajustáveis ou ampliáveis e ressalta que uma notificação temporária pode ser aceitável quando existe outra forma de acessar a mesma informação. Consultar a orientação da W3C sobre limites de tempo.

Adobe Spectrum — Toast. Apresenta o toast como uma mensagem temporária e contextual dentro de um sistema de componentes. Consultar o componente Toast da Adobe Spectrum.

Exemplo visual real — Dell Design System. A página compara mensagens persistentes, dispensáveis e temporárias, ajudando a relacionar duração e comportamento ao nível de consequência. Consultar o componente Message Bar da Dell.

AMAWeb — UNIFESP. O checklist e o manual apoiam a verificação de leitura, teclado, foco e compreensão de mensagens temporárias. Consultar o checklist do AMAWeb e o manual de conteúdo.

Nielsen Norman Group — Visibility of System Status. A heurística recomenda manter as pessoas informadas por meio de feedback adequado e oportuno. Ela sustenta a necessidade de comunicar mudanças de estado, mas não define um número universal de segundos. Consultar as heurísticas de usabilidade.

Interaction Design Foundation — Feedback and Notifications in Mobile Design. Recomenda feedback claro, relevante, pouco interruptivo e fácil de dispensar, além de considerar preferências e contexto de uso em dispositivos móveis. É uma fonte de síntese, não uma medição universal de duração. Consultar o artigo sobre feedback e notificações.

MeasuringU — Benchmarking. Apoia a decisão de testar diferentes durações com tarefas reais e métricas como sucesso, tempo, erros e satisfação. A duração final deve ser uma decisão validada no produto, não apenas copiada de outro sistema. Consultar o material sobre benchmarking de UX.

Baymard Institute — critério de pertinência. A Baymard oferece pesquisa e benchmarking robustos, especialmente para e-commerce, checkout e formulários. As fontes públicas consultadas não fornecem uma regra direta para o tempo de permanência de notificações; por isso, Baymard não é usada aqui como prova de um número específico. Consultar a metodologia da Baymard.

Critério editorial da CamaraUX. Os valores de 4–10 segundos do Material e de 8 segundos documentado pela Atlassian são referências de implementação. Eles devem ser cruzados com W3C, acessibilidade, conteúdo e teste real antes de serem adotados.

Veja também

Esta recomendação foi útil para você?