Uma pessoa abre o aplicativo para terminar uma tarefa. Um banner promocional se mexe, aparece uma janela de chat e uma notificação anuncia algo que poderia esperar. O software está muito empenhado. A pessoa continua tentando terminar a tarefa.
O tema da Organização Mundial da Saúde para 10 de outubro de 2026 destaca a voz de quem viveu problemas de saúde mental e sua influência nas decisões. O tema diz respeito aos sistemas de saúde; não é uma certificação para aplicativos. Para quem desenvolve produtos, propomos uma pergunta mais específica: as pessoas afetadas pela interface participam das decisões sobre seu comportamento? OMS: Dia Mundial da Saúde Mental de 2026.
O que a pesquisa permite concluir
Em um experimento de laboratório apresentado na CHI 2008, Gloria Mark, Daniela Gudith e Ulrich Klocke observaram que os participantes terminavam mais rápido as tarefas interrompidas, mas relatavam mais estresse, frustração e esforço. A tarefa simulava trabalho de escritório com e-mail. Não era um estudo clínico de longo prazo e não demonstra que uma notificação cause um transtorno de saúde mental. Estudo original, PDF.
Outro experimento, publicado em 2019, distribuiu aleatoriamente 237 participantes entre diferentes horários de notificações durante duas semanas. Três grupos diários de mensagens apresentaram benefícios em várias medidas autorrelatadas em comparação com a entrega habitual; retirar todas as notificações não reproduziu o mesmo padrão. Um estudo curto, com amostra e implementação específicas, não identifica um horário universal para todas as pessoas e profissões. Fitz e colegas, Computers in Human Behavior.
A conclusão prática que propomos para a engenharia é tornar o momento e o controle das interrupções verificáveis. Não é prescrever três horários para todo mundo, chamar qualquer interrupção de prejudicial ou vender uma interface como tratamento. Uma pessoa cuidadora esperando uma atualização urgente e alguém lendo um documento longo podem precisar de comportamentos diferentes no mesmo dispositivo.
Comece pelo acontecimento, não pela bolinha vermelha
Antes de adicionar um alerta, escreva quem precisa dele, que ação pode tomar e a partir de quando a informação chega tarde. “O usuário ainda não abriu o aplicativo hoje” não responde a nenhuma dessas perguntas. “A exportação falhou e é necessário corrigir um campo” já dá à equipe um problema concreto para resolver.
Pense em um aplicativo fictício de reservas. Um cancelamento que afeta o agendamento de hoje pode justificar uma notificação imediata. Um resumo semanal de atividade geralmente pode esperar. Um novo tema decorativo não é um agendamento nem uma emergência. Separar esses acontecimentos permite oferecer escolhas úteis, em vez de um único botão chamado “Tudo”.
Para cada categoria, defina o comportamento inicial, os canais disponíveis, o horário de silêncio, o limite de repetições e onde a informação permanece acessível. Respeite as permissões e preferências do sistema operacional. Uma notificação dispensada não deve voltar logo depois usando um chapéu ligeiramente diferente.
O controle precisa ser visível e persistente
As normas de acessibilidade oferecem referências concretas. O critério 2.2.4 das WCAG 2.2, de nível AAA, trata de adiar ou suprimir interrupções, com exceção de emergências. Ele não deve ser apresentado como uma exigência de nível AA nem como uma ordem para esconder todos os alertas. W3C: interrupções.
O critério 2.2.2, de nível A, cobre determinadas situações de movimento e atualização automática e mecanismos para pausar, parar, ocultar ou controlar esse conteúdo. As condições e exceções exatas importam. Um carrossel promocional que se move enquanto alguém lê merece um mecanismo real de pausa, não a esperança de que a pessoa passe a ler mais rápido. W3C: pausar, parar e ocultar.
Uma verificação útil é saber se a preferência continua valendo durante a navegação e em outra visita, quando o produto promete essa persistência. Confira também se o teclado alcança o controle, se o nome explica a ação e se pausar não muda o foco inesperadamente. Um botão que existe no desenho, mas não pode ser usado, não dá controle a ninguém.
Escute antes de escolher o comportamento inicial
Convide pessoas com necessidades de acesso e contextos de trabalho diferentes para realizar uma tarefa real. Pergunte onde a interface interrompeu, que informação passou despercebida e o que esperavam que acontecesse depois. Não exija um diagnóstico para justificar uma preferência. Evite tratar um participante como representante de todas as pessoas com experiências parecidas.
Dê consequência ao que ouviu. Registre a mudança proposta, quem será responsável e como ela será verificada. Se uma sugestão não puder ser adotada porque entra em conflito com outra necessidade, explique a escolha. Uma sessão de escuta que nunca altera uma decisão é boa para produzir atas; é uma ambição modesta para pesquisa de produto.
Um pequeno experimento que a equipe pode fazer
Escolha uma categoria de notificações não urgentes. Ofereça entrega imediata, resumo e silêncio, mantendo a informação disponível no aplicativo. Teste a clareza dos nomes, a persistência e a possibilidade de mudar de escolha. Defina separadamente os acontecimentos realmente urgentes; não retire sua prioridade sem aviso durante o experimento.
Avalie tarefas concluídas, acontecimentos importantes que passaram despercebidos, pedidos de ajuda e as explicações das pessoas. Menos sessões pode significar que o produto ficou mais eficiente, não que perdeu utilidade. Compare os resultados com o objetivo da função, em vez de premiar a versão que gera mais toques. É uma proposta de avaliação de produto, não um ensaio clínico nem um relato de resultados da Zephyrus.
Por fim, facilite a recuperação. Preserve um rascunho quando fizer sentido, explique o limite de tempo antes que o trabalho seja perdido e indique o próximo passo após um erro. Ninguém deveria precisar de concentração excepcional para sobreviver a um formulário comum. Um software útil pode pedir atenção quando é necessário — e ter a educação de esperar quando não é.