UX de permissão

A etapa natural depois de receber um PushSubscription e salvá-lo no servidor é acionar uma mensagem push, mas há uma coisa que eu ignorei de forma flagrante. A experiência do usuário ao pedir permissão para enviar mensagens push.

Infelizmente, poucos sites consideram como pedir permissão ao usuário. Por isso, vamos analisar brevemente a UX boa e ruim.

Padrões comuns

Alguns padrões comuns estão surgindo e podem ajudar você a decidir o que é melhor para seus usuários e caso de uso.

Proposta de valor

Peça aos usuários para se inscreverem nas notificações push quando o benefício for óbvio.

Por exemplo, um usuário acabou de comprar um item em uma loja on-line e concluiu o processo de finalização da compra. O site pode oferecer atualizações sobre o status da entrega.

Há várias situações em que essa abordagem funciona:

  • Um item específico está esgotado. Quer receber uma notificação quando ele estiver disponível?
  • Esta notícia de últimas notícias será atualizada regularmente. Quer receber notificações conforme a matéria se desenvolve?
  • Você deu o lance mais alto. Quer receber uma notificação se alguém der um lance maior?

Esses são todos os pontos em que o usuário investiu no seu serviço e há uma proposta de valor clara para que ele ative as notificações push.

Exemplo de Owen Campbell-Moore de uma boa UX para push.

Owen criou um modelo de um site de companhia aérea hipotético para demonstrar essa abordagem.

Depois que o usuário reserva um voo, ele pergunta se o usuário quer receber notificações de atrasos.

Essa é uma interface personalizada do site.

Exemplo de Owen Campbell-Moore de uma boa UX para o pedido de permissão.

Outro toque legal na demonstração de Owen é que, se o usuário clicar para ativar as notificações, o site adiciona uma sobreposição semitransparente em toda a página quando mostra o pedido de permissão. Isso chama a atenção do usuário para a solicitação de permissão.

A alternativa a esse exemplo, a UX ruim para pedir permissão, é solicitar permissão assim que um usuário acessa o site da companhia aérea.

Exemplo de Owen Campbell-Moore de UX ruim para push.

Essa abordagem não fornece contexto sobre por que as notificações são necessárias ou úteis para o usuário. O usuário também é impedido de concluir a tarefa original (por exemplo, reservar um voo) por essa solicitação de permissão.

Permissão dupla

Você pode achar que seu site tem um caso de uso claro para mensagens push e, como resultado, quer pedir permissão ao usuário o mais rápido possível.

Por exemplo, mensagens instantâneas e clientes de e-mail. Mostrar uma mensagem para uma nova mensagem ou e-mail é uma experiência do usuário estabelecida em várias plataformas.

Para essa categoria de apps, vale a pena considerar o padrão de permissão dupla.

Primeiro, mostre uma caixa de diálogo controlada pelo seu site, explicando o valor para o caso de uso do site. A caixa de diálogo pode oferecer botões para acionar ou dispensar a solicitação de permissão necessária. Se o usuário der um sinal positivo, solicite a permissão, acionando o prompt de permissão real do navegador.

Com essa abordagem, você mostra uma solicitação personalizada no seu app da Web que primeiro fornece contexto. Ao fazer isso, o usuário pode escolher ativar ou desativar sem que seu site corra o risco de ser bloqueado permanentemente porque o usuário se irritou com uma solicitação de permissão inesperada. Se o usuário selecionar "Ativar" na interface personalizada, mostre a solicitação de permissão real. Caso contrário, oculte a caixa de diálogo personalizada e respeite a escolha do usuário.

Leia mais sobre as práticas recomendadas de permissões e como o Google Meet melhorou o fluxo de permissões.

Painel de configurações

Você pode mover as notificações para um painel de configurações, oferecendo aos usuários uma maneira fácil de ativar e desativar as mensagens push, sem precisar sobrecarregar a interface do app da Web.

Quando você carrega a página pela primeira vez, não há um comando.

Um bom exemplo disso é o site do Google I/O. Quando você carrega o site do Google I/O pela primeira vez, não é preciso fazer nada, o usuário pode explorar o site.

O painel de configurações no app da Web do Google IO para mensagens push.

Depois de algumas visitas, clicar no item de menu à direita revela um painel de configurações que permite ao usuário configurar e gerenciar notificações.

O app da Web do Google I/O mostrando a solicitação de permissão.

Ao clicar na caixa de seleção, o comando de permissão é exibido. Sem surpresas ocultas.

Depois que a permissão é concedida, a caixa de seleção é marcada e o usuário pode continuar. O melhor dessa interface é que os usuários podem ativar e desativar as notificações em um único local no site.

Abordagem passiva

Uma das maneiras mais fáceis de oferecer push a um usuário é ter um botão ou uma chave de ativação/desativação de mensagens push em um local na página que seja consistente em todo o site.

Isso não incentiva os usuários a ativar as notificações push, mas oferece uma maneira confiável e fácil de ativar e desativar o engajamento com seu site. Para sites como blogs, que podem ter alguns visitantes regulares, além de altas taxas de rejeição, essa é uma opção sólida, porque segmenta os visitantes regulares sem incomodar os visitantes casuais.

No meu site pessoal, tenho um botão de alternância para mensagens push no rodapé.

Exemplo de botão de ativação/desativação de notificação push do Gauntface.com no
rodapé

Ele fica um pouco fora do caminho, mas para visitantes regulares, deve chamar atenção suficiente dos leitores que querem receber atualizações. Os visitantes únicos não são afetados.

Se o usuário se inscrever para receber mensagens push, o estado do botão de alternância vai mudar e será mantido em todo o site.

Exemplo do Gauntface.com com notificações
ativadas

A UX ruim

Essas são algumas das práticas comuns que notei na Web. Infelizmente, há uma prática ruim muito comum.

A pior coisa que você pode fazer é mostrar a caixa de diálogo de permissão aos usuários assim que eles acessarem seu site.

Eles não têm contexto sobre o motivo de receberem uma solicitação de permissão, talvez nem saibam para que serve seu site, o que ele faz ou o que oferece. Não é incomum que os usuários bloqueiem as permissões nesse momento por frustração, já que esse pop-up está atrapalhando o que eles estão tentando fazer.

Se o usuário bloquear a solicitação de permissão, seu app da Web não poderá pedir permissão novamente. Para receber permissão depois de ser bloqueado, o usuário precisa mudar a permissão na interface do navegador, o que não é fácil, óbvio ou divertido para o usuário.

Não peça permissão assim que o usuário abrir o site. Considere outra interface ou abordagem que incentive o usuário a conceder permissão.

Ofereça uma saída

Além de considerar a UX para inscrever um usuário em notificações push, pense em como um usuário deve cancelar a inscrição ou desativar as mensagens push.

O número de sites que pedem permissão assim que o carregamento de página ocorre e depois não oferecem uma interface para desativar as notificações push é impressionante.

Seu site precisa explicar aos usuários como desativar as notificações push. Se você não fizer isso, é provável que os usuários escolham a opção nuclear e bloqueiem a permissão permanentemente.

A seguir

Code labs