Estruturando um serviço de segurança usando biometria
Figma
Arquitetura de Serviço
Design UX/UI
Liderei o design ponta a ponta de um serviço de verificação biométrica para o app Trizy, conduzindo a arquitetura do serviço, o fluxo de usuário e a UI de todas as telas envolvidas. O projeto resolveu um problema recorrente de fraude em pátios de carga, onde motoristas não autorizados usavam documentos falsificados para roubar cargas no valor de milhares de reais.
Resumo
Sobre o produto
O Trizy é um aplicativo mobile que auxilia motoristas de caminhão oferecendo uma interface simples para comunicação com empregadores e clientes. O app cobre agendamento de carga e descarga, negociação de frete, check-in em pátio e outras tarefas operacionais.
Sobre a equipe
Atuei como product designer, com apoio do time de Desenvolvimento na análise de segurança e performance da validação facial e na integração do serviço. O time de product design utilizou o modelo Double Diamond, dividindo o processo em descoberta e entrega.
Meu papel
Liderei o design de produto em três camadas:
Arquitetura de serviço: mapeei o fluxo ponta a ponta, avaliei fornecedores de biometria e desenhei a integração com a API oficial de identidade.
UX: produzi e validei os fluxos de usuário, defini casos de borda e estados de erro, e testei a jornada internamente antes do rollout.
UI: desenhei todas as telas da jornada de verificação, incluindo a exibição do selo de verificado na página de perfil e o fluxo de recuperação que surgiu como desdobramento desse trabalho.
O time de Desenvolvimento ficou responsável pela implementação e pelos testes de segurança. A liderança de Produto conduziu a seleção do fornecedor junto comigo.
Sobre a persona do usuário
Nossa base de usuários é composta por motoristas de caminhão com idade média de 42 anos. A maioria opera em ambientes hostis a interfaces digitais: pátios de carga com iluminação ruim, conectividade instável, luvas, poeira, sol direto na tela e janelas curtas de tempo. Muitos têm familiaridade limitada com padrões modernos de app como face ID ou verificação em múltiplas etapas.
Essas restrições direcionaram decisões específicas de design: áreas de toque maiores, tipografia de alto contraste, telas com uma ação por vez, instruções explícitas com reforço visual antes da câmera abrir, e caminhos de recuperação que assumem que o usuário pode falhar na primeira tentativa sem entender o motivo.
Discovery
O problema
Devido ao valor das cargas transportadas, os donos da carga enfrentam risco constante de golpes em pátios de carregamento.
O propósito principal dessa feature era reforçar a segurança e melhorar a confiabilidade que os donos da carga teriam ao atribuir cargas para motoristas. As fraudes aconteciam em pátios menores, quando um motorista não autorizado subia um documento falsificado no app Trizy, combinando nome e número do documento do motorista designado com a própria foto editada. O app mostrava o nome do motorista designado com a foto do golpista, e o operador encaminhava ele para a doca de carregamento. Quando os operadores percebiam o que tinha acontecido, o golpista já estava a quilômetros de distância com a carga roubada.
A pesquisa mostrou que esse problema ocorria com frequência, inclusive com documentos físicos falsificados. Esse comportamento já é crime por si só, mas para quem rouba milhares de reais em carga, era só o começo.
A solução
A feature virou um projeto de segurança que beneficiaria tanto o operador do pátio quanto o motorista.
Definimos que a comparação facial e a consistência das informações, validadas por uma API capaz de verificar documentos oficiais, resolveriam o problema.
Em conversas com o lead developer, concluímos que construir um serviço de biometria facial do zero exigiria muito tempo de desenvolvimento e teste. O caminho certo era buscar um fornecedor que entregasse todo esse processamento.
Delivery
Pesquisei soluções para validação facial, comparação facial e detecção de liveness. Encontrei vários fornecedores e filtrei a lista para quatro, cada um com um diferencial.
A liderança de Produto e eu agendamos reuniões ao longo da semana com os consultores e representantes para a América Latina das quatro empresas. Selecionamos a opção mais custo-efetiva que atendia aos requisitos, integrava com nosso app em Flutter e tinha presença consolidada no mercado com clientes em bancos e e-commerce.
Com a API do fornecedor escolhida, estudei a documentação para desenhar um fluxo eficiente para desenvolvimento e identificar capacidades adicionais que poderíamos aproveitar. O conceito que construímos foi o Perfil Verificado.
Esbocei fluxos de usuário para expressar as ideias e discuti com os times de Produto e Desenvolvimento. Após algumas iterações, tínhamos um caso de uso sólido.
Apresentamos o fluxograma junto com slides explicando o conceito para o restante da empresa e para as gerenciadoras de risco parceiras. A proposta foi aprovada com algumas observações que foram incorporadas na entrega.
O fluxo funcionava assim: usuários existentes recebiam uma notificação informando que podiam verificar o perfil gratuitamente escaneando o rosto. Novos usuários podiam verificar durante o cadastro.
A interface explicava como verificar o perfil e os benefícios: mais segurança e confiabilidade no uso do app, além de maior visibilidade na atribuição de cargas para usuários em conformidade.
O usuário era instruído a tirar uma foto sem boné, óculos ou qualquer item bloqueando o rosto, sem opção de subir imagem da galeria. Um algoritmo de validação facial checava se havia um rosto nítido. Se a validação falhava, uma tela de erro orientava a recuperação. Se passava, a imagem era salva no banco.
Esse passo exigia um liveness check para evitar fraudes com software de manipulação de câmera ou ataques de "foto da foto".
O próximo passo verificava se o usuário já tinha carregado um documento de identificação. Se não, o upload se tornava obrigatório.
A partir do documento carregado, capturávamos a foto e armazenávamos. Em seguida, rodávamos OCR no documento para extrair os campos e enviávamos os dados junto com a foto em base64 para a API oficial de identidade. A API retornava um percentual de precisão com base nos registros oficiais do Detran.
Em resumo, a API oficial verificava:
O documento carregado continha informações consistentes.
A foto do documento batia com a foto oficial na base do governo com precisão de 90% ou mais.
Uma vez aprovadas essas checagens, comparávamos a foto do liveness com a foto oficial verificada.
Quando todas as condições batiam, o usuário recebia o status Verificado. A verificação aparecia como um selo ao lado do nome do usuário na página de Perfil. Usuários verificados tinham maior probabilidade de receber cargas, e os donos da carga ganhavam confiabilidade nas atribuições.
Decisões de interface
Algumas escolhas moldaram a UI do fluxo de verificação:
Telas de instrução antes da câmera: Adicionei uma etapa dedicada explicando o que ia acontecer, o que tirar (boné, óculos, máscara) e por quê. Isso reduziu falhas de primeira tentativa causadas pelo usuário não saber o que fazer.
Uma ação principal por tela: Considerando o ambiente de uso (externo, pressão de tempo, baixa familiaridade digital), cada tela apresenta exatamente uma ação.
Estados de erro como orientação, não rejeição: Uma falha de liveness ou OCR retorna uma tela explicando o que deu errado e como corrigir, em vez de só um botão de "tente de novo". Isso era crítico para o público 40+, onde um erro genérico costuma virar "o app está quebrado, desisti".
Selo de verificado: O selo aparece ao lado do nome do usuário na página de perfil e na tela de atribuição de carga para operadores. Evitei linguagem de gamificação como "subiu de nível" ou "desbloqueou". O objetivo era comunicar confiança, não progressão.
Resultados
Testamos o fluxo com 3.500 usuários ao longo de uma semana.
72% foram verificados na primeira tentativa. Dos 28% restantes:
60% falharam por documento inválido, principalmente documentos vencidos bloqueados por uma regra existente.
40% falharam por incompatibilidade entre a foto do liveness e a foto do documento. Esse era o padrão de fraude que a feature foi criada para capturar, com alguns casos mostrando menos de 20% de similaridade entre os rostos, claramente pessoas diferentes.
Acompanhamos de perto dois indicadores do lado das falhas:
Falsos negativos (motoristas legítimos bloqueados): identificamos um conjunto pequeno nos testes iniciais, ajustamos os limiares e adicionamos um caminho de revisão manual para que usuários honestos não ficassem trancados fora do app.
Abandono após a primeira falha: monitoramos a taxa de desistência após a primeira tentativa malsucedida para garantir que a feature não estivesse afastando usuários legítimos.
Apresentamos os resultados para clientes e parceiros de Risk Management, que pressionaram pelo rollout em produção. A feature subiu duas sprints depois. Quando os clientes começaram a filtrar atribuições de carga apenas para motoristas verificados, as tentativas de fraude caíram fortemente e o volume de verificações disparou.
Trabalhar com biometria abriu uma nova oportunidade.
Construímos uma nova feature para usuários verificados que usava o liveness check como autenticação multifator e como método de recuperação de conta.
O design levou uma sprint e o desenvolvimento outra. Isso reforçou ainda mais a segurança do app e da conta, e ampliou a confiança que os usuários verificados sentiam na plataforma.
Conclusão
A feature resolveu o problema de fraude que nos propusemos a resolver e abriu uma segunda oportunidade: com a verificação biométrica em vigor, passamos a usar o liveness como MFA e como recuperação de conta. Esse desdobramento levou duas sprints entre design e desenvolvimento.
O que levei desse projeto:
Comprar vence construir quando a competência central está em outro lugar. A conversa que mais importou foi a com o lead developer sobre escopo, não as com os fornecedores.
UX de segurança vive ou morre nos estados de erro. Uma taxa de 28% de falha é aceitável se esses usuários sabem o próximo passo. É um desastre se não sabem.
Uma feature construída para um problema (fraude) gerou valor em dois adjacentes (MFA, recuperação). Vale desenhar com casos de uso secundários em mente desde o início.
Se eu fizesse de novo, investiria mais cedo no caminho de revisão manual para falsos negativos, e testaria as telas de instrução com usuários em ambientes reais de pátio em vez de no escritório.
Matheus Gomes / 2025