Uma pessoa abre a aplicação para terminar uma tarefa. Um banner promocional mexe-se, aparece uma janela de chat e uma notificação anuncia algo que podia esperar. O software está muito empenhado. A pessoa continua a tentar terminar a tarefa.
O tema da Organização Mundial da Saúde para 10 de outubro de 2026 centra-se na voz de quem viveu problemas de saúde mental e na sua influência sobre as decisões. Diz respeito aos sistemas de saúde, não é uma certificação para aplicações. Para quem desenvolve produtos, propomos uma pergunta mais delimitada: as pessoas afetadas pela interface participam nas decisões sobre o seu comportamento? OMS: Dia Mundial da Saúde Mental de 2026.
O que a investigação permite concluir
Numa experiência de laboratório apresentada na CHI 2008, Gloria Mark, Daniela Gudith e Ulrich Klocke observaram que os participantes terminavam mais depressa as tarefas interrompidas, mas relatavam mais stress, frustração e esforço. A tarefa simulava trabalho de escritório com email. Não era um estudo clínico prolongado e não demonstra que uma notificação provoque uma perturbação de saúde mental. Estudo original, PDF.
Outra experiência, publicada em 2019, distribuiu aleatoriamente 237 participantes por diferentes horários de notificações durante duas semanas. Três conjuntos diários apresentaram benefícios em várias medidas autorrelatadas face à entrega habitual; retirar todas as notificações não reproduziu o mesmo padrão. Um estudo curto, com uma 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 inferência útil para a engenharia é tornar o momento e o controlo das interrupções verificáveis. Não é prescrever três horários a toda a gente, classificar qualquer interrupção como nociva ou vender a interface como tratamento. Uma pessoa cuidadora à espera de uma atualização urgente e alguém a ler um documento longo podem precisar de comportamentos diferentes no mesmo dispositivo.
Começar pelo acontecimento, não pelo círculo vermelho
Antes de acrescentar um alerta, escreva quem precisa dele, que ação pode tomar e a partir de quando a informação chega tarde. “O utilizador ainda não abriu a aplicação hoje” não responde a nenhuma destas perguntas. “A exportação falhou e é necessário corrigir um campo” já dá à equipa um problema concreto para resolver.
Pense numa aplicação fictícia de reservas. Um cancelamento que afeta a marcação de hoje pode justificar uma notificação imediata. Um resumo semanal de atividade pode normalmente esperar. Um novo tema decorativo não é uma marcação nem uma emergência. Separar estes acontecimentos permite oferecer escolhas úteis, em vez de um único interruptor chamado “Tudo”.
Para cada categoria, defina o comportamento inicial, os canais disponíveis, o período de silêncio, o limite de repetições e o local onde a informação fica acessível. Respeite as permissões e preferências do sistema operativo. Uma notificação dispensada não deve regressar logo a seguir com um chapéu ligeiramente diferente.
O controlo tem de 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. 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, bem como 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 depressa. W3C: pausar, parar e ocultar.
Uma verificação útil é perceber se a preferência sobrevive à navegação e a uma visita posterior, quando o produto promete essa persistência. Confirme ainda que o teclado chega ao controlo, que o nome explica a ação e que a pausa não desloca inesperadamente o foco. Um botão que existe no desenho mas não pode ser utilizado não dá controlo a ninguém.
Ouvir antes de escolher o comportamento inicial
Convide pessoas com necessidades de acesso e contextos de trabalho diferentes a realizar uma tarefa real. Pergunte onde a interface interrompeu, que informação passou despercebida e o que esperavam que acontecesse a seguir. Não exija um diagnóstico para justificar uma preferência. Evite tratar um participante como representante de todas as pessoas com experiências semelhantes.
Dê consequências ao que ouviu. Registe a alteração proposta, quem fica responsável e como será verificada. Se uma sugestão não puder ser adotada porque entra em conflito com outra necessidade, explique o compromisso. Uma sessão de escuta que nunca altera uma decisão é boa a produzir atas; é uma ambição modesta para investigação de produto.
Uma pequena experiência que a equipa pode fazer
Escolha uma categoria de notificações não urgentes. Disponibilize entrega imediata, resumo e silêncio, mantendo a informação acessível na aplicação. Teste a clareza dos nomes, a persistência e a possibilidade de mudar de escolha. Defina separadamente os acontecimentos realmente urgentes; não lhes retire prioridade sem aviso durante esta experiência.
Avalie tarefas concluídas, acontecimentos importantes que passaram despercebidos, pedidos de ajuda e as explicações dadas pelas pessoas. Menos sessões pode significar que o produto se tornou mais eficiente, não que perdeu utilidade. Compare os resultados com o objetivo da funcionalidade, 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 de perder trabalho e indique o próximo passo após um erro. Ninguém deveria precisar de concentração excecional 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 é.