Design e UX, Ops, Processos e Métodos

Por que produtos deveriam se preocupar com mensagens de erro?

Lidar com erros deveria ser um esporte colaborativo do time.

Por que produtos deveriam se preocupar com mensagens de erro?
Imagem de Yansou Girard.

Este artigo de Jenni Nadler, UX writer e team lead na Wiix, está viralizando nas redes sociais e nos convida a refletir sobre o que fazer quando temos um cenário negativo, mas previsto, e precisamos orientar o cliente?

No artigo ela relata que no Wix conseguiram fazer o levantamento de 7.643 mensagens de erro e transformá-las em mensagens acessíveis, respeitosas, que davam o devido direcionamento ao cliente do que fazer naquela situação. A imagem,inclusive, é um exemplo em inglês da forma mais recomendada, segundo a autora, de como lidar com um cenário negativo que precisa ser informado.

Ela traz um passo a passo de como resolver este impasse:

  • Dizer o que aconteceu;
  • Dizer porquê aconteceu;
  • Confortar o cliente;
  • Ajudar a se resolver sozinho;
  • Dar a ele uma saída.

Parece até que óbvio o que ela traz no artigo, mas normalmente a visão de produtos sobre desenho de cenários é tendenciosa, assim como nossa visão de produtos em si. Ela tende a ser horizontal, pensamos muito bem na próxima feature que queremos trabalhar, no próximo produto, no próximo item de backlog. Mas e o que deixamos para trás?

Sabia que também são responsabilidades nossa de enquanto profissionais de produtos?

Como diria minha mãe, o diabo mora nos detalhes.

Em diversas empresas que já trabalhei o time de produtos tende a se esquecer que o software que ele perfeitamente desenhou pode falhar, ou pode apresentar uma mensagem desagradável ao cliente, mas que é esperada pelo negócio.

Vamos começar com essa diferença:

  • O que é um erro e o que é uma mensagem de alerta.

ERRO

Um erro é uma resposta inesperada do software. Imagine o seguinte cenário: você está pesquisando em um app de supermercado por um tipo de banana em específico, banana maçã, no caso. Porém, quando o desenvolvedor criou o software ele não relacionou que “banana maçã” é um tipo de banana, não que são duas frutas diferentes “banana” e “maçã”. Neste caso, o sistema ou te devolverá ambas as frutas, ou responderá com NullPointer.Exception (resposta nula inesperada). Com sorte aparece alguma coisa na tela, mas provavelmente a gente de negócios nem sabe da existências desses problemas.

Vamos para um cenário mais simples: você está tentando acessar um site que não existe e aparece um erro 404 (site não encontrado). Provavelmente você verá um erro assim:

Imagem do Google

Na imagem acima, o erro 404 apareceu foi apresentado como uma mensagem que traz muitos termos técnicos, um usuário leigo provavelmente não saberia interpretar facilmente que se trata de uma falha de entendimento entre o servidor e o usuário, podendo inclusive ser por outros fatores:

  • Pode ser um problema de digitação do termo pelo usuário;
  • O sistema operacional do usuário pode estar desatualizado, ou desprotegido;
  • O navegador do usuário pode estar desatualizado;
  • Conexão instável;
  • Problemas de cachê;

Dessa forma, como existem muitas variáveis que podem ser a causa do problema, o ideal é tentar uma forma que unifique as soluções, uma boa sugestão seria:

“Solicitação não processada.
O servidor não entendeu ou não aceitou este termo pedido. Por favor, verifique o termo informado. Caso persista tente atualizar seu dispositivo e navegador.”

Neste exemplo, podemos ver a aplicação prática dos conceitos trazidos por Jenni Nadler:

  • “Solicitação não processada” - Informa o que aconteceu;
  • “O servidor não entendeu ou não aceitou este termo pedido” - Informa o porque aconteceu;
  • “Por favor, verifique o termo informado” - Uma solução imediata para o problema do usuário;
  • “Caso persista tente atualizar seu dispositivo e navegador.” - Uma última alternativa caso tudo venha a falhar.

Neste exemplo, o usuário tem um direcionamento melhor, mesmo estando frente a frente com um cenário inesperado, mas mesmo assim com direcionamento.

Mensagem de alerta

Vou contar um relato que passei recentemente, essa semana para ser exato. Eu tinha um cartão de crédito que eu não usava há um tempo, recebi uma comunicação para voltar a usar, pois perderia o limite conquistado.

Na primeira compra fui bloqueado. Não só o cartão foi classificado possível fraude, mas também bloquearam meu acesso ao App, não contente com isso, me bloquearam nas centrais de atendimento telefônico. Só fiquei sabendo que era uma medida de proteção quando acionei o Bacen. Não tive dúvidas quando a ouvidoria entrou em contato: cancelei o cartão.

Ou seja, uma regra não explicada, um cenário negativo para mim, mas esperado pelo negócio me fez cancelar um cartão de quase cinco anos e romper meu relacionamento com a instituição.

Como este banco poderia ter me notificado:

“Por motivos de segurança seu cartão foi bloqueado.
Para sua segurança, bloqueamos o seu cartão e seus acessos temporariamente para termos certeza que é realmente você quem está fazendo essa transação atípica. Para desbloquear, entre em contato com nossa central especial e confirme sua identidade nas centrais XXXX."

Neste exemplo, podemos ver a aplicação dos conceitos e de outros

  • “Por motivo de segurança seu cartão…” -Informa o que aconteceu;
  • “Para sua segurança” - conforto ao usuário;
  • “Bloqueamos o seu cartão…” - Informa o porque aconteceu;
  • “Para desbloquear, entre em contato…” - Uma solução imediata para o problema do usuário;

Onde você entra em tudo isso?

Como negócios, se existem cenários que seriam negativos para os usuários seguem algumas dicas adicionais aos conselhos da Jenni, que, aliás, vale muito a pena a leitura.

  • Torne suas mensagens de erro acessíveis (reforçando o que a autora traz): não se discute mais no mundo da tecnologia, acessibilidade é lei prevista no Brasil e deveria ser obrigação de todas as empresas;
  • Torne suas mensagens tagueadas: parte do nosso trabalho é analisar funil e entender de onde o cliente vem e para onde ele vai, usar seu analytics neste momento pode te trazer dados para saber o tamanho de um possível problema;
  • Exija que seu time de TI rastreie logs dessas mensagens de alerta ou erro: em pleno 2022, ainda existem empresas que não guardam registros das ações que acontecem em seus sistemas e suas devidas respostas. Novamente: sem dados não há como ter evolução. Isso te ajudará inclusive em possíveis crises e como sustentar seu produto;
  • Como será a performance destes erros? Se já é normal em um site comum que um segundo de delay pode representar quase 7% de diminuição de conversão, imagina se esse tempo de delay for para apresentar um erro?;
  • Tudo bem não conhecer todos os cenários negativos que podem acontecer no código, seu time de TI serve para te ajudar a pensar neles também. Para nós, profissionais de produtos, é difícil imaginar um cenário onde não há internet, um servidor que cai, uma página que não existe, mas é nosso dever nos refinamentos trazer o time para discussão e co-criação destes cenários e de como tratá-los.

Outra empresa que também trabalhei, um grande banco nacional, quando nos debruçamos sobre este tipo de discussão em 2018 conseguimos mapear cerca de 4 mil mensagens de alerta que não eram claras ao usuário, dessas, inclusive mapeamos o cenário de pessoas que acessaram menus que eram próprios para clientes que haviam contratado o produtos, mas estas não tinham o produto ainda. A solução envolveu inclusive transformar esses momentos mais chatos em um oportunidade de vendas, vou transcrever um exemplo, pois por motivos de contrato não posso mostrar claramente a solução dada, mas era mais ou menos assim:

“Não foi possível acessar este menu.
Não foram encontrados produtos contratados para acessar o menu. Caso já   tenha contratado o produto, por favor entre em contato com seu gerente ou   a central de atendimento.
Ainda não é cliente? Veja oportunidades que esse produto traz para você  clicando aqui.”

Neste exemplo, podemos ver a aplicação dos conceitos e de outros

  • “Não foi possível acessar este menu” -Informa o que aconteceu;
  • “Não foram encontrados produtos contratados para acessar o menu” - Informa o porque aconteceu;
  • “Caso já tenha contratado o produto, por favor…” - Uma solução imediata para o problema do usuário;
  • “Ainda não é cliente?...” - Uma última alternativa caso não tenha o produto.

Conclusão

Quando a equipe de produtos não têm clareza dos cenários negativos que podem acontecer em seus produtos, o cliente quem sofre na ponta.

Parece muito óbvio tudo que foi relatado, mas as consequências são grandes, desde aumento significativo no número de atendimentos, até perda de vendas, exposição negativa em redes sociais, e pode chegar até rompimento de relacionamentos (meu caso, quando falei do cartão de crédito).

Em uma das empresas que passei, havia um produto que cerca quase 30% dos chamados recebidos eram de cenários mal explicados pelo time de produtos na experiência ao usuário e  que resultaram em chamadas. A consequência disso é o custo de operação de atendimento e o sentimento de que o canal não funcionava.

Referência bibliográfica

Daniel Duarte: Há 10 anos em produtos digitais e liderança. Especialista em inovação, meios de pagamentos, edtech, insurtechs, e mercado as a services.

Aproveite conteúdo ilimitado.

Inscreva-se AGORA