Como reduzir o atrito do UX no desenvolvimento seguro de produtos

No desenvolvimento de produtos, muitas vezes a aparência acaba recebendo toda a atenção. Uma interface de usuário agradável é importante, mas UX é o que faz ou quebra seu produto.

Como gerente de produto, passo a maior parte do meu tempo pensando em como reduzir o atrito em todo o UX. Com isso quero dizer reduzir o número de etapas que um usuário final deve seguir para atingir seus objetivos ou reduzir a complexidade dessas etapas. Um aplicativo de comércio eletrônico que faz você passar por três medidas de segurança para fazer uma compra não funcionará tão bem quanto um aplicativo que requer apenas uma.

No entanto, o baixo atrito não pode prejudicar a segurança de organizações que mantêm dados confidenciais de clientes, como instituições financeiras e seguradoras.

Como a facilidade de uso e a segurança de dados pessoais geralmente estão em desacordo, encontrar o equilíbrio certo pode ser complicado. Aqui está como fazê-lo.

A antiga batalha entre segurança e conveniência

Por décadas após o nascimento do cartão de crédito na década de 1950, os emissores, preocupados com fraudes, exigiam que os comerciantes ligassem para eles sempre que uma transação excedesse o “limite mínimo” – o valor máximo que um portador de cartão poderia cobrar sem pré-autorização. Isso é muito atrito para um consumidor esperando para comprar um carro ou geladeira novo. Como resultado, ao estabelecer limites mínimos, bancos e empresas de cartão de crédito tiveram que pesar seu apetite por risco em relação à tolerância de seus consumidores a inconveniências.

Um cliente com um limite de crédito de US$ 10.000 provavelmente tem mais valor para um banco - e maiores expectativas de serviço - do que um com limite de US$ 1.000. Você pode decidir aumentar o limite mínimo para esse tipo de cliente para minimizar o atrito que eles experimentam. Mas e se essas contas de maior valor também forem mais vulneráveis ​​a fraudes? Você pode acabar introduzindo um nível de risco que causaria mais danos ao seu resultado final do que a perda de alguns desses clientes.

Avanço rápido para a era digital e essa gangorra de demandas concorrentes permanece, embora com ameaças em rápida mudança e consumidores menos pacientes. Não existe uma fórmula exata para conciliar essas demandas, portanto, os gerentes de produto que trabalham em software e aplicativos precisam calibrar constantemente seu UX para manter o equilíbrio e a segurança.

Menos fraude nem sempre significa mais lucro

Na maioria dos softwares e aplicativos seguros, há dois conjuntos de clientes que os gerentes de produto devem atender:

1. A organização que prioriza a maior proteção possível.
2. O usuário final que deseja um produto UX perfeito.

Um banco, por exemplo, preferiria 100% de proteção contra fraudes por vários motivos, incluindo:

• Satisfação do cliente.
• Redução de perdas por fraude.
• Reputação da marca.
• Minimização de ataques cibernéticos.

Por outro lado, o usuário final tem requisitos concorrentes: eles querem acesso fácil e rápido à sua conta. Isso não vai acontecer se o UX do banco for projetado para 100% de proteção contra fraudes.

Em vez disso, o usuário final encontrará alto atrito toda vez que usar o aplicativo. Por exemplo, depois de inserir uma senha, o usuário pode precisar inserir um código de autenticação de dois fatores enviado ao telefone, seguido por uma verificação biométrica ou um desafio CAPTCHA. O tempo de atraso resultante pode levar alguns usuários a reduzir o uso do aplicativo ou, pior, a procurar um novo banco. Nesse cenário, o banco terá economizado dinheiro em perdas por fraude, mas terá perdido dinheiro em sua base de clientes cada vez menor.

Para complicar as coisas, diferentes usuários finais podem ter diferentes limites para a quantidade de atrito que tolerarão antes de procurar outro provedor de serviços.

Bloqueie as metas, os custos e a tolerância ao risco do cliente

Agora que estabelecemos que tentar fornecer 100% de proteção contra fraudes não faz sentido para os negócios, precisamos determinar o que faz. Comecemos pelos recursos do banco: dinheiro e pessoas.

Primeiro, identifique a taxa de fraude atual do banco e quanto em perdas ele pode absorver. Avalie também a economia líquida que espera obter com este novo produto em relação ao custo de desenvolvimento e manutenção. (Você pode descobrir que a proteção contra fraudes custa mais do que a própria fraude.)

Em seguida, descubra quantos casos suspeitos e “falsos positivos” a equipe do banco pode processar por dia. Os falsos positivos acontecem quando o banco remove ou restringe a conta de um usuário devido a um erro de cálculo de risco. Esses falsos positivos aumentam o atrito para o usuário, drenam o tempo dos funcionários do banco e podem prejudicar a reputação da marca.

Você pode começar a definir o escopo do seu produto depois de definir o que o banco pode gastar ou perder em dinheiro e mão de obra. Com essas informações, você pode determinar quais pontos de dados coletar dos usuários finais para calcular sua pontuação de risco de fraude em tempo real.

Identifique quais dados coletar dos usuários finais

Software e aplicativos seguros verificam:

• Quem é você. Esses são seus comportamentos, que incluem coisas como seus locais de login ou movimentos do mouse.
• O que você tem. Estes são os dispositivos registrados para você ou que você usa regularmente.
• O que você sabe. Isso inclui senhas, perguntas de segurança, aniversários e outras informações pessoais.

Depois que o software coleta essas informações, os modelos de aprendizado de máquina usam as entradas de cada categoria para atribuir ao usuário um perfil de risco de fraude. Com base nesse perfil, uma organização pode decidir se permite acesso, nega acesso, solicita autenticação adicional, restringe a funcionalidade ou qualquer combinação dessas opções.

Como gerente de produto, é tentador coletar o máximo de informações possível. No entanto, isso nem sempre é a melhor prática. Isso porque quanto mais informações você coletar de cada usuário, mais tempo e recursos serão necessários para calcular a pontuação de risco no back-end. Isso, por sua vez, aumenta o tempo de atraso para o usuário, ou seja, mais atrito.

Em vez disso, comece com os indicadores que parecem ser os significantes mais simples da identidade de um usuário, como localização, dispositivos conhecidos e senhas. Em seguida, pense nas maneiras pelas quais um ator mal-intencionado poderia contornar esses indicadores. Criminosos sofisticados podem falsificar a localização e o dispositivo de um usuário e podem ter acesso a senhas comprometidas por vazamentos de dados ou ataques de malware. Para fechar essas brechas, você também pode analisar os movimentos do mouse ou verificar se o usuário fez compras semelhantes no passado.

Antes de adicionar um novo indicador, avalie seu impacto na prevenção de fraudes em relação aos custos iniciais de adicioná-lo ao produto. Você também deve levar em consideração os custos recorrentes de mão de obra e financeiros que vêm com cálculos adicionais e armazenamento de dados.

Lembre-se de que encontrar o conjunto certo de indicadores é um exercício de tentativa e erro. A única maneira de determinar verdadeiramente o benefício de cada indicador é adicionar e subtrair cada um deles, monitorando o impacto de cada combinação na sua taxa de fraude e na experiência do usuário tanto para o cliente quanto para os usuários finais.

Incorporar com clientes para avaliar seus indicadores

Embora o cliente possa priorizar a redução de fraudes, a usabilidade para seus próprios funcionários (como analistas de fraudes) também é importante no back-end. Portanto, é aconselhável certificar-se de que os pontos de dados que você planeja coletar os ajudarão e não os impedirão.

Uma estrutura de design thinking é uma abordagem útil para produtos que atendem a dois conjuntos de usuários. É centrado no ser humano em vez de centrado no problema e pede aos designers que tenham empatia com os usuários para que possam imaginar suas necessidades futuras. O design thinking pode ajudar os gerentes de produto a desenvolver um produto dinâmico que atenda a interesses concorrentes – neste caso, segurança e conveniência.

Investir no estágio de empatia significa fazer perguntas e incorporar no fluxo de trabalho diário do seu cliente. Isso permite que você se envolva com RFPs para prever mudanças de mercado e ver como os dados do cliente se alinham com seu cenário de ameaças em tempo real. Depois de entender esses desafios estratégicos e táticos, você pode começar o desenvolvimento.

Planeje passar o máximo de tempo possível com seu cliente durante as fases de desenvolvimento e teste. Embora o feedback lhe dê uma noção da lista de desejos do cliente, o shadowing ajuda a identificar falhas de comunicação, lacunas de conhecimento e falhas de design que não aparecerão no auto-relato.

O sombreamento é bastante simples se você for um gerente de produto interno compartilhando espaço de escritório com analistas de fraude. Se você for um consultor ou funcionário externo, precisará agendar visitas ao local com a maior frequência possível. Se viajar não for uma opção, as sessões virtuais com compartilhamento de tela valem o esforço.

Verifique semanalmente com analistas de fraude assim que seu produto estiver funcionando para garantir que o design de UX esteja atendendo a eles, principalmente quando você lança novos recursos: Por que eles executam tarefas em uma determinada ordem? O que acontece quando eles clicam em um botão específico? Como eles reagem quando recebem uma notificação? Que mudanças eles estão percebendo em seu dia-a-dia de trabalho?

Colete seus dados

A tecnologia de coleta de dados permite que as organizações aproveitem centenas de pontos de dados para verificar a identidade de um usuário. Também ajuda os sites e aplicativos de comércio eletrônico a adaptar a experiência do usuário ao seu perfil demográfico. Um usuário que se encaixa em um determinado perfil pode até obter ofertas personalizadas ou acionar assistência automatizada.

Então, como isso funciona em aplicativos de segurança?

• Navegadores da Web: Cada vez que um usuário navega para um site protegido em um navegador, os “coletores” de JavaScript incorporados coletam informações de identificação. Isso pode incluir pontos de dados como localização, detalhes do dispositivo e movimentos do mouse.
• Aplicativos nativos: os aplicativos nativos são projetados para uma plataforma de dispositivo específica, como iOS ou Android. Ao acessar um serviço a partir de um dispositivo móvel, esses aplicativos usam kits de desenvolvimento de software (SDKs) para coletar informações de identificação, que podem incluir toques e deslizes de dedos em vez de movimentos do mouse.

Seus modelos de aprendizado de máquina atribuirão uma pontuação de risco de fraude com base no padrão geral que esses pontos de dados formam. Se a pontuação de risco estiver acima da média, faz sentido introduzir mais atrito na forma de autenticação de dois fatores ou perguntas de segurança. No entanto, se muitos de seus usuários estiverem acionando etapas extras de verificação, talvez seja hora de reconsiderar seu limite de risco ou estratégia de coleta de dados.

Continue reduzindo o atrito do usuário final

Assim que seu produto estiver em execução, acompanhe as reclamações dos usuários finais registradas nos call centers ou nas lojas de aplicativos para descobrir pontos problemáticos e sugestões de melhoria. Mesmo os melhores testes de pré-lançamento não detectarão todos os pontos de atrito, e novos sistemas operacionais e versões de dispositivos podem causar complicações inesperadas que atrasam os usuários finais.

Para empresas construídas no comércio eletrônico, os custos dessas desacelerações são visíveis. Em 2022, o Baymard Institute estimou que 17% dos abandonos de carrinho evitáveis ​​foram devidos a um processo de checkout excessivamente longo ou complicado; outros 18% dos entrevistados culparam a falta de confiança na segurança de suas informações de cartão de crédito. Baymard estima que o checkout lento e a falta de confiança na segurança do site estão entre um conjunto de fatores que contribuíram para US$ 260 bilhões em vendas perdidas nos EUA e na UE. Isso apresenta uma oportunidade incrível para os gerentes de produtos de comércio eletrônico repensarem suas soluções de ponto de venda. Mas, independentemente do seu setor, reduzir o atrito do usuário e garantir a confiança na proteção de seus dados deve ser uma prática contínua que pode gerar clientes mais satisfeitos e grandes inovações nos negócios.

Aqui estão dois exemplos de redução de atrito bem-sucedida no desenvolvimento seguro de produtos:

3DS

No final da década de 1990, a Visa e a Mastercard se uniram para criar o protocolo de segurança de pagamentos seguros 3D (3DS). Lançado em 2001, o protocolo original exigia que todos os usuários registrassem seus cartões no 3DS e fizessem login em cada caixa com uma senha 3DS dedicada. Se um usuário não conseguia lembrar sua senha do 3DS, era necessário recuperá-la ou redefini-la antes de concluir a compra. Em uma versão posterior, os emissores de cartões tinham a opção de substituir a senha estática frequentemente esquecida por uma senha dinâmica de uso único (OTP). No entanto, a etapa extra de login continuou a dificultar o processo de checkout.

Os desenvolvedores do 3DS perceberam esse atrito persistente e, em 2016, lançaram o 3DS 2.0, que inclui um componente SDK que permite que os aplicativos incorporem o elemento 3DS em seu código. O 3DS 2.0 é mais adequado para transações móveis e analisa mais pontos de dados para gerar uma avaliação de risco mais precisa. Como resultado, apenas uma pequena porcentagem de usuários do 3DS 2.0 precisa realizar uma etapa extra de autenticação, geralmente na forma de um OTP.

Uber

O 3DS 2.0 é um exemplo de redução do atrito do produto por meio da iteração. Mas você também pode reduzir o atrito no nível do setor introduzindo produtos disruptivos.

O modelo de negócios da Uber baseia-se na subtração do atrito de uma corrida de táxi tradicional. Com o Uber, não há mais espera em espera com um serviço de táxi ou vasculhar sua carteira no final de sua viagem.

Um processo de pagamento contínuo foi fundamental para o sucesso inicial da empresa, mas veio com alguns riscos. Cada vez que a Uber processa automaticamente uma transação em um cartão de crédito armazenado em seu aplicativo, corre o risco de um estorno (no qual o titular do cartão contesta uma transação e recebe um reembolso).

No entanto, a Uber calculou que o custo desses possíveis estornos valeu a oportunidade de otimizar a experiência do usuário. Se um usuário tivesse que sacar um cartão de crédito ou digitar uma senha toda vez que ligasse para uma carona, todo o negócio poderia ter falhado. Em vez disso, o Uber aceitou o risco do atrito e o serviço decolou.

Em ambos os exemplos, uma abordagem de gerenciamento de produto centrada no usuário que também ponderava a segurança e o risco resultou em inovações revolucionárias e lucrativas.

A melhor manutenção é uma boa ofensa

As fraudes querem ficar um passo à frente das equipes de produto. Enquanto outros tipos de desenvolvimento podem reagir a mudanças nos requisitos, os projetos de software seguro precisam antecipá-los. Isso significa que os gerentes de produto devem ler a literatura do setor e aproveitar os dados de vários clientes para aprender com as violações de segurança anteriores e desvios bem-sucedidos.

Sua equipe de produto deve fornecer relatórios regulares do cenário de ameaças e fazer referência cruzada deles com as experiências e os requisitos de seu cliente. Nem todas as novas ameaças garantem uma atualização do produto. Talvez sua equipe tenha identificado um novo tipo de ataque contra o qual seu UX não protege, mas uma discussão com seu cliente revela que ele não é relevante para o ambiente de ameaças: um cliente bancário na África do Sul pode estar lidando com uma onda de Fraude de troca de SIM, enquanto outro em Nova York pode estar sofrendo mais ataques de hackers usando VPNs. Na maioria dos casos, não seria econômico – e introduziria fricção desnecessária na experiência do usuário – proteger os dois bancos de ambos os tipos de fraude.

Como gerente de produto, sua função exige o ajuste constante de recursos para garantir que você não troque a segurança por uma experiência de usuário agradável ou vice-versa. E embora você precise de muitos dados para realmente entender as necessidades de seus clientes e usuários finais, o restante desse equilíbrio é uma mistura de tentativa, erro e arte.