Privacidade UX: melhores notificações e solicitações de permissão

• Parte 1: Preocupações com privacidade e privacidade em formulários da Web
• Parte 2: Melhores experiências de consentimento de cookies
• Parte 3: Melhor UX de Notificações e Solicitações de Permissão
• Parte 4: Estrutura de design sensível à privacidade

Imagine que você está atrasado para uma daquelas reuniões para as quais você realmente não quer se atrasar. Você apressadamente coloca seus sapatos e seu casaco e pega as chaves da porta e agarra a maçaneta da porta - apenas para sair a tempo. Ao descer as escadas, você enfia a mão no bolso e pega seu celular para verificar o horário do metrô ou pedir um táxi.

Uma breve olhada na tela é suficiente para você suar: você percebe que esqueceu de carregar seu telefone durante a noite e ele está funcionando orgulhosamente com os 2% de carga restantes da bateria. Enquanto você corre pela rua, cheio de esperança e fé, você diminui o brilho da tela e procura o ícone do aplicativo certo na tela inicial. É claro que, naquele exato momento, uma série de notificações cai em cascata na tela, pedindo sua atenção total para novos seguidores, atualizações, lembretes e mensagens.

As chances são altas de que você sabe muito bem como é isso. Qual a probabilidade de você agir na pilha de notificações em cascata nessa situação? E qual a probabilidade de você desativar completamente as notificações quando outro lembrete chegar a você alguns minutos depois, exatamente quando você perdeu sua conexão? Essa é uma daquelas situações em que as notificações estão literalmente atrapalhando da maneira mais perturbadora possível, e apesar de todos os fluxos de usuários cuidadosamente elaborados e pixels polidos e preciosos.

Com tantos aplicativos e serviços e pessoas e máquinas e chatbots lutando por nossa atenção, manter o foco é um luxo que precisa ser saboreado e protegido , e não é à toa que as notificações não gozam de uma reputação decente nos dias de hoje. Mais do que isso, muitas vezes eles se sentem fora do ponto e manipuladores também.

“Eles geralmente aparecem nos momentos em que são menos relevantes e criam uma falsa sensação de urgência, diluindo o foco e causando frustração.”

— Alex Potrivaev, Intercom

Isso vale para janelas flutuantes na tela inicial, tanto quanto a poderosa contagem não lida nas barras de ferramentas. Isso também é verdade para mensagens de marketing mascaradas como notificações, bem como atualizações sociais divididas em muitas pequenas mensagens para chamar permanentemente a atenção para o serviço.

Todas essas notificações exigem atenção imediata e parecem incrivelmente invasivas , jogando com nossos desejos de não perder e ficar conectado com nossos grupos sociais. Na verdade, eles interrompem a privacidade de uma forma que nenhum padrão obscuro pode – exigindo e chamando a atenção incondicionalmente, não importa o que o usuário esteja fazendo no momento.

No entanto, não é culpa das notificações que elas pareçam invasivas; é que nós os projetamos de tal forma que eles muitas vezes atrapalham. Os usuários não querem perder notificações importantes e perder mensagens oportunas ou vendas limitadas, mas também não querem se sentir incomodados por uma maré interminável de atualizações barulhentas. Se isso acontecer com muita frequência, os usuários desativam completamente as notificações, muitas vezes com um sabor amargo em relação ao aplicativo e à marca devido à sua “imploração desesperada por atenção”, como disse um usuário. Um único culpado pode arruiná-lo para todos os outros, e isso apesar do fato de nenhuma notificação ser igual a outra.

As muitas faces das notificações

As notificações são distrações por natureza; eles chamam a atenção de um usuário para um evento (potencialmente) significativo do qual ele não está ciente ou pode querer ser lembrado. Como tal, eles podem ser muito úteis e relevantes, prestando assistência e trazendo estrutura e ordem para a rotina diária. Até que não sejam.

Em geral, as notificações podem ser informativas (lembretes de calendário, notificações de atraso, resultados da noite eleitoral) ou incentivar ações (aprovar o pagamento, instalar uma atualização, confirmar uma solicitação de amizade). Eles podem transmitir de várias fontes e podem ter vários impactos:

• As notificações da interface do usuário aparecem como cartões sutis nas interfaces do usuário à medida que os usuários interagem com a interface da Web - como tal, são amplamente aceitas e menos invasivas do que algumas de suas contrapartes.
• As notificações push no navegador são mais difíceis de dispensar e chamam a atenção para si mesmas, mesmo que o usuário não esteja acessando a interface do usuário.
• As notificações no aplicativo ficam em aplicativos para desktop e dispositivos móveis e podem ser tão simples quanto as notificações da interface do usuário, mas podem ter um papel mais central com mensagens enviadas para a tela inicial ou o centro de notificações.
• As notificações do sistema operacional , como atualizações de software ou alterações de operadora de celular, também entram no mix, geralmente aparecendo junto com uma ampla variedade de notas, atualizações de calendário e tudo mais.
• Por fim, as notificações podem chegar a aplicativos de e-mail, SMS e mensagens sociais, provenientes de chatbots, sistemas de recomendação e humanos reais.

Você pode ver como as notificações – considerando todos os seus sabores e fontes – podem se tornar esmagadoras em algum momento. Não é que prestemos exatamente a mesma atenção a todas as notificações que recebemos. Para a grande maioria dos usuários, pode levar semanas até que eles instalem uma atualização de software solicitada pela notificação do sistema operacional, enquanto geralmente não leva mais do que algumas horas para confirmar ou recusar uma nova solicitação do LinkedIn ou do Facebook.

Nem todas as notificações são iguais e o nível de atenção que os usuários concedem a elas dependerá de sua natureza ou, mais especificamente, de como e quando as notificações são acionadas.

Em seu artigo sobre “Análise crítica de sistemas de notificação”, Shankar Balasubramanian fez uma pesquisa notável dividindo os gatilhos de notificação em alguns grupos:

Não podemos deduzir que um grupo de gatilhos seja sempre mais eficaz que outro, mas algumas notificações de todos os grupos tendem a ser muito melhores em capturar a atenção do que outras:

• As pessoas se preocupam mais com novas mensagens de amigos e parentes próximos, notificações de colegas selecionados durante o horário de trabalho, transações bancárias e alertas importantes, notificações de calendário, eventos programados, alarmes e quaisquer confirmações ou liberações acionáveis ​​e aguardadas.
• As pessoas se preocupam menos com atualizações de notícias, atualizações de feeds sociais, anúncios, novos recursos, relatórios de falhas, notificações na web, mensagens informativas e automatizadas em geral.

Sem surpresa, os usuários tendem a atender notificações de bateria fraca ou confirmações de pagamento imediatamente; além disso, lembretes de calendário, atualizações de progresso (por exemplo, ETA de entrega de pacotes) e mensagens individuais são mais importantes do que outras notificações. Na verdade, em todas as conversas que tivemos com os usuários, uma mensagem de outro ser humano era muito mais valorizada do que qualquer notificação automática. As prioridades podem mudar um pouco, é claro, se um usuário estiver aguardando impacientemente uma notificação, mas poucas pessoas deixariam tudo para trás em uma corrida desesperada para verificar o 77º como em sua foto.

Assim, as notificações podem ser diferentes, e notificações diferentes são percebidas de forma diferente; no entanto, quanto mais pessoais, relevantes e oportunas forem as notificações, maior o envolvimento que devemos esperar. Mas o que tudo isso significa para o design das notificações e como podemos torná-las menos intrusivas e mais eficientes?

Não confie em padrões genéricos: configure os modos de notificação

Geralmente, há uma boa razão pela qual os clientes optaram por se inscrever em um serviço. Poucas pessoas acordam de manhã esperando criar uma nova conta naquele dia. Na verdade, eles podem sentir que seu serviço pode ajudá-los em suas tarefas diárias ou melhorar seu fluxo de trabalho. Espero que eles não precisem de notificações para entender como um serviço funciona, mas talvez precisem receber notificações para entender o valor que o serviço oferece.

Talvez eles tenham recebido uma mensagem importante de um empregador em potencial, ou talvez haja uma correspondência de perfil de namoro que valha a pena conferir. Eles podem não querer perder essas mensagens apenas porque se esqueceram de fazer check-in no serviço por um tempo. Como designers, precisamos colocar a pitada certa de notificações na mistura para manter o cliente motivado, enquanto fornecemos apenas indicadores relevantes e acionáveis ​​para eles.

Infelizmente, na maioria dos serviços, não é incomum se inscrever, apenas para perceber alguns momentos depois que a caixa de entrada está cheia de todos os tipos de mensagens (principalmente puramente informativas), muitas vezes enviadas imediatamente após a outra e raramente acionáveis. As notificações por e-mail geralmente são ativadas por padrão, com o consentimento do usuário implícito ao concordar com termos e condições longos e não gerenciáveis. Ninguém gosta de ser bombardeado com um fluxo de mensagens não solicitadas, e isso vale tanto para e-mails de spam quanto para notificações indesejadas.

Em vez de configurar uma frequência de notificação padrão para todos os clientes por padrão, poderíamos começar a enviar apenas algumas notificações selecionadas com pouca frequência. À medida que o cliente continua usando a interface, podemos pedir que ele decida sobre o tipo de notificação que prefere e sua frequência. O mesmo vale para as solicitações de consentimento de cookies: podemos fornecer opções recomendadas predefinidas com um “modo calmo” (baixa frequência), um “modo regular” (média frequência) e um “modo de usuário avançado” (alta frequência).

No entanto, poderíamos ser mais granulares do que isso. O Basecamp, por exemplo, introduziu as opções "Always On" e "Work Can Wait" como parte de sua experiência de integração, para que novos clientes possam selecionar se desejam receber notificações à medida que ocorrem (a qualquer momento) ou escolher um horário específico intervalos e dias em que as notificações podem ser enviadas. Ou, ao contrário, podemos perguntar aos usuários quando eles não querem ser incomodados e suspender as notificações nesse momento. Nem todo cliente deseja receber notificações relacionadas ao trabalho fora do horário comercial ou no fim de semana, mesmo que seus colegas possam estar trabalhando horas extras no sábado à noite do outro lado do planeta.

Com o passar do tempo, o formato das notificações também pode precisar de ajustes. Em vez de ter notificações enviadas uma a uma à medida que os eventos ocorrem, os usuários podem escolher um “modo de resumo”, com todas as notificações agrupadas em uma única mensagem autônoma entregue em um horário específico a cada dia ou a cada semana.

Essa é uma das configurações que o Slack oferece quando se trata de notificações; na verdade, o sistema também adapta a frequência das notificações ao longo do tempo. Inicialmente, como os canais do Slack podem ser bastante silenciosos, o sistema envia notificações para cada mensagem postada. À medida que as atividades se tornam mais frequentes, o Slack recomenda reduzir o nível de notificação para que o usuário seja notificado apenas quando for realmente mencionado.

Outro recurso que o Slack oferece é permitir que os usuários destaquem uma seleção de palavras para que os usuários sejam notificados apenas quando um tópico de seu interesse for mencionado:

Pode parecer que a frequência das notificações está recebendo muita atenção neste momento, mas quando perguntado sobre pontos problemáticos comuns com notificações, o problema mais comum foi, de longe, sua alta frequência, mesmo que as mensagens fossem relevantes ou acionáveis.

A linha inferior é: comece a enviar notificações lentamente, mas de forma constante ; configurar modos de notificação e fornecer opções granulares, como a escolha de gatilhos e o formato das notificações. Melhor enviar muito pouco do que muito: você pode não ter outra chance se o cliente desejar desativar as inúmeras notificações que estão dando nos nervos na hora errada.

Escolha o tempo com cuidado

Podemos não gostar de admitir, mas para muitos de nós, o dia não começa com uma saudação pacífica e consciente do sol nascente; em vez disso, começa com um olhar tedioso e reflexivo para a tela brilhante de nossos telefones celulares. Mais especificamente, a primeira coisa que vemos todas as manhãs nem é a hora atual ou nossos entes queridos, mas a pilha de notificações que se acumulavam incansavelmente enquanto dormíamos.

Esse estado de espírito não é necessariamente a melhor oportunidade para lembrar os usuários de uma política de privacidade atualizada, novos recursos brilhantes ou despesas pendentes que precisam ser finalizadas. Notificações pessoais, como novos compartilhamentos sociais e reações de círculos sociais, podem ser muito mais relevantes, assim como os próximos compromissos e tarefas do dia.

O tempo é importante, assim como as notificações oportunas . Você provavelmente não vai querer incomodar seus clientes no meio da noite quando eles chegarem a um destino remoto com jet lag pesado. Portanto, é uma boa ideia acompanhar a mudança de fusos horários e hora local e ajustar a entrega de notificações de acordo. Por outro lado, os clientes não ficarão particularmente satisfeitos com a exibição de uma notificação importante quando ela não for mais relevante; portanto, se eles estiverem rastreando um evento ou anúncio importante, você terá que decidir se o evento é crítico o suficiente para perturbá-los um momento desconfortável.

Sua análise informará quando seus usuários provavelmente agirão em suas notificações, portanto, é uma boa ideia estudar e rastrear as respostas com base no tempo e acionar o envio de notificações nesse período. Por exemplo, se um cliente for mais receptivo a compartilhar uma mensagem pela manhã, adie as notificações até o momento certo no horário local da manhã.

Evite situações estressantes por design

Com notificações, o tempo não é o único atributo importante a ser considerado. Lembre-se do pobre personagem esperando pegar sua conexão desde o início desta seção? Liberar um conjunto de notificações em um nível de bateria criticamente baixo não é uma boa ideia, e é tão contraproducente quando o usuário está lutando com a conectividade ou está focado em uma tarefa como dirigir um carro. Se você puder avaliar o nível da bateria e a qualidade da conexão, é uma boa ideia evitar o envio de notificações quando as condições de um usuário estiverem abaixo do ideal. Obviamente, as notificações também precisam ser relevantes, portanto, se você também puder avaliar a localização do usuário, evite enviar notificações dependentes da localização que não são aplicáveis .

Às vezes, é difícil reter notificações, pois elas podem ser críticas para a atividade atual do usuário. Se o usuário estiver dirigindo um carro, seguindo instruções em um aplicativo de navegação, pode ser necessário fornecer uma notificação mais persistente e humilde sobre a mudança de rota recomendada devido a um acidente na estrada. Nesse caso, assim como outras notificações críticas, poderíamos exibir um botão flutuante “Novas atualizações disponíveis. Atualize.” É muito menos invasivo do que uma notificação bloqueando o acesso ao conteúdo, mas é tão eficaz para indicar que a página ou o estado da página pode estar desatualizado e novas informações estão disponíveis.

Na verdade, em vez de enviar notificações em horários padrão específicos, mesmo que seja com base no comportamento anterior do usuário, você pode explorar o outro lado da moeda e aproveitar momentos felizes e bem-sucedidos . Um serviço de transferência de dinheiro, TransferWise, exibe notificações quando o cliente recebe um pagamento - e não é um momento maravilhoso para pedir uma revisão de aplicativo na App Store? Poderíamos rastrear marcos importantes e notificar os usuários sobre recursos avançados à medida que são alcançados, just-in-time , como Luke Wroblewski os chama.

Reduza a Frequência Agrupando Notificações

Não existe uma regra de ouro para a quantidade certa de notificações em um determinado dia. Assim como cada notificação é diferente, o mesmo acontece com as preferências e motivações de cada cliente. Para manter o envolvimento de um usuário, talvez seja necessário liberar gradualmente blocos de notificações, dependendo do alcance ou das preferências do cliente. É aí que o agrupamento gradual entra em ação, conforme explicado no artigo “Projetando Notificações Inteligentes” de Alex Potrivaev, designer de produto da Intercom.

A ideia é simples. Se você sabe que seus clientes recebem em média menos de cinco reações por postagem, pode ser uma boa ideia fornecer uma notificação exclusiva para cada um deles. Você também pode acionar uma notificação se uma mensagem vier de eventos importantes, como uma mensagem de amigos próximos, familiares ou pessoas influentes. Além disso, como sabemos que as notificações acionadas por uma ação de outro ser humano são mais valorizadas do que as notificações automatizadas, priorizam e focam principalmente as pessoais , para aquele determinado cliente.

Uma vez que o volume de notificações tenha aumentado, podemos começar a agrupá-las e fornecer resumos compactos no momento apropriado. Por exemplo, o Facebook resume as notificações em blocos não intrusivos, com cada linha destacando exatamente um tipo de evento, como reações a uma mensagem específica (“Stoyan Stefanov e 48 outras pessoas reagiram à sua postagem…”) . O LinkedIn, por outro lado, parece acionar quase todos os eventos um por um (“Stoyan Stefanov comentou em sua postagem”) , poluindo o fluxo de notificações e dificultando a verificação e o uso.

É claro que, com base no histórico de um usuário, poderíamos personalizar mais do que apenas o agrupamento de notificações. Assim que soubermos como um usuário reage a novas curtidas de fotos, se ele olha brevemente para elas ou se aprofunda em cada notificação, podemos fornecer notificações melhores da próxima vez. Como Alex conclui:

“Com base na maneira como você costuma interagir com o conteúdo, podem ser oferecidas melhores opções de redação e estrutura e, dependendo do comportamento padrão, você pode ver as notificações estruturadas de maneira diferente.”

Isso, é claro, também requer ciclos de feedback contínuos.

Permitir que os usuários adiem ou pausem as notificações

Dificilmente qualquer empresa descartará o valor dos dados sobre seus clientes. Na verdade, podemos obter insights valiosos de longo prazo introduzindo ciclos de feedback ; ou seja, oferecer continuamente aos clientes opções de “Ver mais” ou “Ver menos” notificações de um tipo específico. Mas, assim como tendemos a perceber a deficiência como uma condição ligada/desligada (você tem uma deficiência ou não), muitas vezes sentimos que podemos prever com precisão o comportamento do usuário com base apenas em seu comportamento passado.

A realidade, no entanto, raramente é preto e branco. Nossos usuários podem ser temporariamente impedidos de segurar um bebê em um braço, ou por causa de um acidente infeliz recente, e as condições em que se encontram podem flutuar da mesma maneira. Ações rápidas, como adiar em resposta a uma notificação recebida, podem ajudar a aliviar o problema, ainda que temporariamente.

O contexto do usuário muda continuamente . Se você notar uma queda incomum na taxa de engajamento ou se estiver prevendo um volume incomumente alto de notificações chegando (um aniversário, aniversário de casamento ou noite de eleição, talvez), considere fornecer uma opção para silenciar, adiar ou pausar as notificações , talvez pelas próximas 24 horas.

Isso pode ir muito contra nossa intuição, pois podemos querer reengajar o cliente se ele ficar em silêncio de repente, ou podemos querer maximizar seu envolvimento quando eventos importantes estão acontecendo. No entanto, pressionar com a frequência das notificações é muito perigoso na maioria das vezes. É fácil chegar a um ponto em que uma notificação aparentemente inofensiva irá afastar um cliente, potencialmente até mesmo a longo prazo. Pode haver boas razões para o usuário não estar ou não querer estar ativo por um tempo e, na maioria das vezes, não tem nada a ver com o serviço.

Outra opção seria sugerir uma mudança de meio usado para consumir notificações. Os usuários tendem a associar diferentes níveis de urgência a diferentes canais de comunicação. Notificações no aplicativo, notificações push e mensagens de texto são consideradas muito mais intrusivas do que o bom e velho e-mail, portanto, quando a frequência exceder um determinado limite, convém levar os usuários a mudar de notificações push para resumos diários de e-mail.

Definir limites e construir uma árvore de decisão de notificações

Os limites não são fáceis de definir corretamente, no entanto. Eventos importantes devem acionar notificações imediatas para serem recebidas a tempo. Eventos menos importantes podem esperar, mas pode ser útil chamar a atenção do cliente para o serviço. Notificações potencialmente irrelevantes precisam ser filtradas incansavelmente para deixar tempo e espaço para que notificações importantes sejam apreciadas e valorizadas.

Em geral, notificações mais curtas, como mensagens de amigos e colegas, são mais adequadas como notificações de interface do usuário, se não forem urgentes, ou notificações push, se forem. Notificações mais longas são melhores como e-mails — sejam urgentes ou não. Essa regra geral varia de serviço para serviço, portanto, você pode criar uma árvore de decisão de notificações para rastrear qual mídia funciona melhor para tipos específicos de notificação com base em sua urgência, duração e frequência. Além disso, você pode definir limites e acionar um prompt para adiar ou ajustar as configurações se um limite for atingido.

Torne a adesão e a desativação óbvias

Hoje em dia, é quase esperado que um serviço chegue ao extremo, tornando ridiculamente difícil para um cliente optar por não receber notificações poderosas. Palavras obscuras e rótulos obscuros habilmente escondidos em cantos remotos da interface não são incomuns. Poucas outras considerações de design podem ser mais prejudiciais e prejudiciais para uma marca. Quando os usuários não podem ajustar as configurações facilmente, eles aplicam artilharia pesada, marcando notificações por e-mail como spam ou bloqueando notificações nas configurações do sistema operacional ou configurações do navegador. Para um site ou aplicativo, não há uma maneira fácil de se recuperar disso, exceto implorar por assinaturas novamente.

Uma saída muito mais simples é fornecer um controle muito granular sobre as notificações, incluindo seu conteúdo, formato, frequência e horários de não perturbe. Poderíamos fornecer uma opção para responder a uma notificação recente com "Menos e-mails" ou "Parar" para alterar a frequência, ignorando logins de sites ou logins de aplicativos (o Notion.so faz isso). Para aplicativos, forneça preferências de notificação integradas ao aplicativo em vez de depender das configurações nativas do SO. Lá, você também pode explicar o que o usuário pode esperar de cada tipo de notificação, talvez até com exemplos de como eles ficariam.

Na prática, muitos usuários pesquisarão configurações de notificação em ambos os lugares se realmente precisarem, mas quanto mais tempo demorarem para encontrar essa configuração nebulosa, menos pacientes serão. Na realidade, a maioria dos usuários busca uma forma de desligar as notificações no momento em que estão realmente frustrados ou incomodados com as notificações recentes. Esse não é um estado de espírito agradável e, como serviço, você provavelmente não deseja estender desnecessariamente esse estado de espírito às custas de se sentir incomodado e confuso por seus clientes pagantes.

Não se esqueça de explorar também o outro lado da moeda. Identifique partes da jornada do usuário em que é mais provável que um usuário assine notificações; por exemplo, uma vez que um pedido em uma loja online foi feito com sucesso ou uma reserva de voo foi confirmada. Em ambos os casos, as notificações podem ajudar os clientes a rastrear atrasos ou recuperar cartões de embarque a tempo. Esse também é um bom momento para sugerir notificações push em tempo real, o que também significa primeiro pedir permissão ao cliente para enviar esses lembretes. E esse tópico merece uma conversa à parte.

Pedindo permissão, a maneira humilde

Alguns sites são um personagem e tanto, não são? Auto-indulgente, indelicado no coração e genuinamente antipático também. Com que frequência você tropeça em uma página aparentemente modesta e despretensiosa apenas para ser recebido com um prompt de permissões maravilhoso implorando para enviar notificações? Você ainda não leu uma única palavra, mas aí está, já pedindo um compromisso de longo prazo – e, francamente, bastante invasivo .

Em termos de experiência do usuário, exibir um prompt de permissão no carregamento é provavelmente a melhor maneira de causar uma primeira impressão ruim e, na maioria dos casos, um erro irreversível. A partir de janeiro de 2019, o Chrome alterou as opções exibidas quando um prompt nativo é acionado. Embora os usuários possam dispensar uma notificação para reagir a ela mais tarde, agora eles precisam escolher se desejam "Aceitar" ou "Bloquear" as notificações. O último resulta no bloqueio permanente das notificações da Web para todo o site, a menos que o usuário encontre o caminho através das configurações do navegador para conceder acesso. Não é de admirar que a grande maioria dos usuários bloqueie esses prompts imediatamente, sem ler seu conteúdo.

Estrategicamente, é melhor pedir permissão apenas quando houver uma grande chance de um usuário realmente aceitar. Para que isso aconteça, precisamos explicar ao cliente por que realmente precisamos de sua permissão e qual valor podemos fornecer em troca. Na prática, essa estratégia geralmente é implementada na forma de 'padrão de solicitação dupla'. Em vez de pedir permissão imediatamente, esperamos primeiro uma certa quantidade de envolvimento : talvez algumas visitas à página, algumas interações, uma certa quantidade de tempo gasto no site. Eventualmente, podemos destacar o fato de que um usuário pode assinar notificações e como elas podem ser valiosas, ou que precisamos de sua permissão para resultados de pesquisa mais precisos e com reconhecimento de localização. Às vezes, o contexto da página é suficiente, como quando uma interface deseja solicitar geolocalização quando o usuário visita a página do localizador de lojas.

Em todos esses casos, um botão de call-to-action proeminente esperaria o momento em que um usuário estivesse mais receptivo para agir sobre ele. Se o usuário optar por tocar no botão, podemos supor que ele provavelmente prosseguirá com a ação. Assim, uma vez clicado, o botão solicitaria uma solicitação de permissão nativa real.

Essencialmente, estamos dividindo o prompt de permissão em duas solicitações:

1. Uma solicitação incorporada à interface do usuário,
2. Uma solicitação nativa no nível do navegador.

Como observa Adam Lynch, se o usuário ainda revogar a permissão, talvez devido a um toque ou clique errado no prompt do navegador nativo, precisamos exibir uma página de fallback que explica como habilitar manualmente a permissão por meio das configurações do navegador (ou link para uma explicação). Obviamente, não faz sentido exibir uma solicitação de notificações se o usuário já tiver concedido permissão. Podemos usar a API de permissões para consultar o status de qualquer permissão por meio de uma única interface assíncrona e ajustar a interface do usuário de acordo.

A mesma estratégia pode ser aplicada a qualquer tipo de solicitação de permissão, como acesso a geolocalização, câmera, microfone, Bluetooth, MIDI, WebUSB e assim por diante. A redação e a aparência dos prompts de notificação da interface do usuário são de importância crítica aqui, portanto , é uma boa ideia rastrear as taxas de engajamento e aceitação para cada permissão ou recurso e agir de acordo com elas. E isso nos leva ao rei de todos eles – rastreando as principais métricas para suas notificações.

Acompanhar Métricas para Notificações

Normalmente, as notificações não são enviadas com o propósito de informar os clientes sobre um evento que está ocorrendo ou que está por vir. Boas notificações são úteis e acionáveis, ajudando clientes e empresas a atingir seus objetivos. Para isso, as métricas relevantes devem primeiro ser descobertas e definidas.

No mínimo, talvez precisemos saber se as notificações que enviamos são relevantes em primeiro lugar.

• O texto, o formato e a frequência das notificações direcionam a ação desejada que pretendemos alcançar (seja compartilhamentos sociais, tempo gasto no site ou compras)?
• Que tipo de notificações são mais importantes do que outras?
• As notificações realmente trazem os usuários de volta ao aplicativo?
• Quanto tempo se passa entre o envio da notificação e o retorno do usuário ao site ou aplicativo?
• Quanto tempo é gasto em média entre a notificação de clique e a saída do usuário do site?

Experimente palavras, duração, tempos de envio e agrupamento e frequência de notificações para diferentes níveis de envolvimento do usuário – iniciante, usuário regular e usuário avançado. Por exemplo, os usuários tendem a ser mais receptivos a mensagens de conversação que parecem mais casuais e menos parecidas com notificações do sistema. Mencionar os nomes de seres humanos reais cujas ações acionaram uma notificação também pode ser útil.

Nunca é uma má ideia começar a enviar notificações lentamente para rastrear seu possível impacto negativo também – seja opt-outs ou desinstalações de aplicativos. Ao enviar primeiro um grupo de notificações para um pequeno grupo, você ainda tem a chance de “ajustar ou cancelar qualquer campanha de notificação prejudicial antes que seja tarde demais”, como observa Nick Babich em “O que é uma boa notificação”.

Todos esses esforços têm o mesmo objetivo em mente: evitar interrupções significativas e evitar a fadiga de notificações para nossos clientes , informando-os sobre o que desejam saber no momento em que precisam saber. No entanto, se os avisos de cookies são apenas irritantes e as notificações frequentes são apenas uma perturbação, quando se trata da segurança de dados pessoais e de como eles são gerenciados, os clientes tendem a ter preocupações muito mais urgentes.

Vale a pena notar que existem diferenças significativas em como as notificações são solicitadas, agrupadas e exibidas no Android e iOS, portanto, se você estiver projetando um aplicativo nativo ou híbrido, precisará examiná-las em detalhes. Por exemplo, no iOS, os usuários não configuram notificações do aplicativo até a integração ou uso posterior do aplicativo, enquanto os usuários do Android podem optar por não receber notificações durante a instalação, com o comportamento padrão sendo opt-in. As notificações push enviadas por um PWA se comportarão como notificações nativas em um respectivo sistema operacional.

Admittedly, these issues will not be raised immediately, but as customers keep using an interface and contribute more and more personal data, doubts and concerns start appearing more frequently, especially if more people from their social circles are involved. Some of these issues are easy refinements, but others are substantial and often underestimated blockers.

In the final article of the series, we'll be looking into notifications UX and permission requests, and how we can design the experience around them better, with the user's privacy in mind.

• Part 1: Privacy Concerns And Privacy In Web Forms
• Parte 2: Melhores experiências de consentimento de cookies
• Part 3: Better Notifications UX And Permission Requests
• Parte 4: Estrutura de design sensível à privacidade

Useful Resources And References

• “Designing Notifications For Apps,” Shashank Sahay
• “Different Types Of Notifications: Websites, Apps And Beyond,” Joanna Martin
• “It's Time For Notifications To Get Smart,” Alex Potrivaev
• “Improving User Experience With Real-Time Features,” Lauren Plews