UX de permissão

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

Infelizmente, poucos sites consideram muito a forma como pedem permissão ao usuário, então vamos analisar rapidamente a UX boa e a ruim.

Padrões comuns

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

Proposta de valor

Peça que os usuários se inscrevam para receber 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 fluxo de finalização da compra. O site pode então oferecer atualizações sobre o status de entrega.

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

  • Um item específico está esgotado. Você quer receber uma notificação quando ele estiver disponível?
  • Esta última notícia será atualizada regularmente. Você quer ser notificado à medida que a matéria se desenrola?
  • Você deu o maior lance. Quer receber uma notificação se o lance for superado?

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

O exemplo de Owen Campbell-Moore de uma boa UX para impulsionar.

criou um modelo do site de uma companhia aérea hipotética para demonstrar esta abordagem.

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

Esta é uma interface personalizada do site.

Exemplo de Owen Campbell-Moore de boa UX para a solicitação de permissão.

Outro bom toque na demonstração do Owen é que, se o usuário clicar para ativar as notificações, o site vai adicionar uma sobreposição semitransparente à página inteira quando a solicitação de permissão for mostrada. Isso chama a atenção dos usuários para a solicitação de permissão.

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

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

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

Permissão dupla

Você pode achar que seu site tem um caso de uso claro para mensagens push e, por isso, quer solicitar a permissão do 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 essas categorias de apps, vale a pena considerar o padrão de permissão dupla.

Primeiro, mostre uma solicitação de permissão falsa que seu site controla, com botões para permitir ou ignorar a solicitação. Se o usuário clicar em "Permitir", solicite a permissão, acionando a solicitação real de permissão do navegador.

Com essa abordagem, você exibe uma solicitação de permissão personalizada no app da Web que pede para o usuário ativar as notificações. Assim, o usuário pode ativar ou desativar o recurso sem que seu site corra o risco de ser bloqueado permanentemente. Se o usuário selecionar "Ativar" na interface personalizada, mostre a solicitação de permissão real. Caso contrário, oculte o pop-up personalizado e pergunte em outro momento.

Um bom exemplo disso é . Depois que você faz login, aparece uma solicitação na parte superior da página perguntando se quer ativar as notificaçõ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 sobrecarregar a interface do app da Web.

Quando a página é carregada pela primeira vez, não aparece nenhuma solicitação.

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

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

Após algumas visitas, clique no item de menu à direita para revelar um painel de configurações que permite ao usuário definir e gerenciar notificações.

App da Web do Google IO mostrando a solicitação de permissão.

A solicitação de permissão aparece quando você clica na caixa de seleção. Sem surpresas.

Depois que a permissão for concedida, a caixa de seleção será marcada e o usuário estará pronto para prosseguir. O melhor dessa interface é que os usuários podem ativar e desativar as notificações de um 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 que ativa / desativa as mensagens push em um local da página consistente em todo o site.

Isso não faz com que os usuários ativem as notificações push, mas oferece uma maneira confiável e fácil de ativar e desativar a interação com seu site. Para sites como blogs que podem ter espectadores regulares e taxas de rejeição altas, essa é uma boa opção, porque segmenta espectadores regulares sem incomodar os visitantes de passagem.

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

Exemplo de alternância da notificação push do Gauntface.com no
rodapé.

Ele está meio fora do caminho, mas, para visitantes regulares, ele deve receber atenção suficiente dos leitores que querem receber atualizações. Visitantes únicos não são afetados.

Se o usuário se inscrever para receber mensagens push, o estado da chave vai mudar e o manterá em todo o site.

Exemplo do Gauntface.com com notificações
ativadas

A experiência do usuário ruim

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

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

Eles não têm contexto sobre por que estão solicitando uma permissão e podem nem saber para que serve seu site, o que ele faz ou o que ele oferece. Não é incomum bloquear permissões nesse momento por frustração. Esse pop-up atrapalha o que a pessoa está tentando fazer.

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

Seja qual for o caso, não peça permissão assim que o usuário abrir o site. Considere usar outra interface ou abordagem que incentive a permissão.

Ofereça uma saída

Além de considerar a UX para inscrever um usuário no envio de push, considere como um usuário pode cancelar a inscrição ou desativar as mensagens push.

É surpreendente o número de sites que pedem permissão assim que a página é carregada e não oferecem IU para desativar as notificações push.

Seu site deve explicar aos usuários como eles podem desativar o envio por push. Se você não fizer isso, os usuários provavelmente vão usar a opção nuclear e bloquear a permissão permanentemente.

A seguir

Laboratórios de códigos