hunter soares

Busca

Cases, contato e CV

Contato
EN

Produto · três frentes ao mesmo tempoleitura de 9 min

CPF Seguro

Proteção contra fraude em três lugares: a loja, o app de um parceiro e a mesa do operador

+34%
de conclusão no cadastro dentro do aplicativo do parceiro, depois do fluxo de seis telas.
3
superfícies no ar sobre um sistema só: loja, aplicativo de parceiro e painel de operação.
88
peças de tela com opções, valores e padrão declarados num lugar só.
22
fluxos auditados por programa, com saída legível.

Produto em produção. Product Designer na Diletta Solutions, a empresa de software onde eu trabalho, de novembro de 2021 até hoje.

A home do aplicativo próprioO estado do CPF ocupa o topo inteiro porque quem compra proteção chega com medo, e a primeira pergunta dele é se está protegido agora. Embaixo, a ação de maior consequência do produto, e depois o histórico de quem entrou onde com o seu nome.

00 Arquivo

Produto CPF Seguro · proteção de identidade
Onde ele aparece app próprio na loja · dentro do app de um parceiro · painel de operação
Papel Product Designer · Diletta Solutions
Plataforma Flutter, iOS e Android · painel na web
Ferramentas Figma, Flutter, Git
Escopo 3 superfícies, e eu levo as três
Parceiro no ar o TicTac, feed de ofertas de loja da Directo, uma empresa de tecnologia para o varejo
Período novembro de 2021 até hoje

Uma linha. O mesmo produto tem que funcionar sozinho na loja de aplicativos, embutido no app de outra empresa com a marca dela, e operado por um time interno. Três públicos com expectativas opostas, um sistema por baixo.


01 Resumo

Problema. No Brasil, alguém abre conta e contrata dívida usando o CPF de outra pessoa. A vítima descobre pela cobrança, não pelo ato. O produto vende monitoramento e reação a isso.

O que eu fiz. Um sistema de tela para os três lugares, com a marca do parceiro tratada como caso previsto e não como exceção. E mudei o lugar onde a tela é editada: ela deixou de morar no código e passou a morar numa descrição que tanto o desenho quanto o programa leem.

Resultado. 88 peças de tela com as opções declaradas, 22 fluxos medidos por programa, e o produto no ar em três lugares ao mesmo tempo.

Papel. Product Designer na Diletta Solutions, ponta a ponta: pesquisa, definição do problema, UI e entrega para a engenharia.


02 Contexto

Quem compra proteção de CPF está com medo. Ele não chega curioso, chega desconfiado, e muitas vezes chegou depois de já ter sido fraudado.

Isso muda o desenho inteiro. Num app de banco, o inimigo é o atrito. Aqui o inimigo é a dúvida: cada elemento que parece golpe custa uma conversão, porque o usuário já viu golpe usando exatamente essa linguagem visual.

E o produto é vendido de duas formas. Direto ao consumidor, na loja de aplicativos. E embutido no app de empresas parceiras, com a marca delas na frente.


03 Restrição

A linguagem em que este produto é escrito é o design system Diletta. O parceiro onde a versão embarcada está no ar é o TicTac, da Directo.

Marca de outra empresa dentro do nosso produto. No modo embutido, parte da tela é da marca do parceiro e parte é nossa. Isso é regra de composição, e regra de composição não cabe num arquivo de configuração de cores.

Dado pessoal sensível, ambiente regulado. Consentimento e verificação de identidade não são lugar para criatividade.

Três superfícies, um time. O painel de operação não pode virar projeto órfão, porque é ele que sustenta o atendimento quando algo dá errado.

O parceiro decide quando atualiza. O app dele consome o nosso sistema como dependência versionada. Versão que quebra tela não é adotada.


04 O problema em número

  • Uma fraude é aplicada a cada 16 segundos no Brasil. Fórum Brasileiro de Segurança Pública, 2024.
  • O golpe padrão: abrir conta, pedir cartão e assinar contrato no nome de outra pessoa. Em muitos casos o golpista também usa foto ou vídeo da vítima para passar pela verificação por reconhecimento facial.
  • As perdas com fraude em pagamento instantâneo no Brasil podem chegar a US$ 1,937 bilhão até 2028, o maior crescimento projetado do mundo.
  • Até maio de 2025 havia pelo menos 14 sites falsos usando dados reais de brasileiros junto com a identidade visual de páginas do governo e de birôs de crédito.

Esse último dado é o que mais afeta o desenho. O golpe imita a interface da instituição séria. Então a interface séria não pode se parecer com a média do mercado, ela precisa parecer verificável.


05 Decisões

D1 · A marca do parceiro é um caso previsto, não uma exceção

A identidade do parceiro entra por funções de cor próprias e por uma posição fixa na barra superior. Ela não entra sobrescrevendo as nossas cores.

Por quê: sobrescrita é convite à divergência, porque cada parceiro novo pede uma exceção. Função nomeada é contrato: o parceiro preenche o que é dele e não alcança o que não é.

Medido: as medidas dessa composição estão escritas em pixel, num arquivo, não na memória de quem desenhou.

Prova em campo: está no ar dentro do TicTac, da Directo. Cliente real, marca real, e o mesmo produto segue na loja como app próprio.

01SMS de convite
02Boas-vindas
03CPF
04Criar senha
05Código por SMS
06Biometria
FluxoA entrada pelo app do parceiro. O cliente recebe um SMS, cria a conta e sai com biometria ligada, sem nunca abrir a nossa loja.
01Checkout · resumo do pedido
02Checkout · novo cartão
03Checkout · aprovado
FluxoO pagamento dentro da loja do parceiro. A marca dele fica no pedido, a nossa fica no meio de pagamento, e as duas dividem a mesma tela sem disputar hierarquia. É a mesma regra da barra superior aplicada a outra superfície.

D2 · A tela mora na descrição, não no arquivo de código

Cada tela é descrita num formato que o desenho e o programa leem. O programa que monta a tela é um só, e ele lê essa descrição. Editar tela virou editar a descrição.

Por quê: com duas fontes de verdade, o Figma e o app divergem em uma semana, e depois ninguém sabe qual das duas está certa.

Abri mão de: liberdade de escrever tela solta, do jeito que der na hora. Em troca ganhei a possibilidade de medir e comparar.

D3 · Peça com opções declaradas, não componente com parâmetro solto

São 88 peças de tela com as opções, os valores possíveis e o valor inicial escritos num só lugar. É isso que permite montar tela sem programar e verificar cobertura por programa.

O que eu aprendi errando: só as opções que a peça sempre mostra podem receber dado de verdade. As que aparecem apenas em certas condições recebem o dado e não mostram nada, sem erro e sem aviso. Descobri isso por acaso, e virou regra escrita.

D4 · Fluxo se mede, não se olha

Um programa audita os 22 fluxos do produto e devolve número. Uma verificação automática não consegue ver que uma tela está feia, mas consegue ver que uma tela está faltando, e esse é o erro que mais escapa.

D5 · A credencial é do domínio, não do aparelho

A pessoa cadastra uma chave de acesso no nosso produto e ela passa a valer nos outros aplicativos do mesmo domínio, sem digitar senha de novo. Para o aplicativo de um parceiro entrar nessa lista, ele declara o nosso domínio no arquivo de domínios associados dele.

A ordem do fluxo saiu dessa decisão: primeiro pergunta se a pessoa vai usar em mais de um aparelho, depois oferece a chave e a biometria, e senha fica por último.

Por quê: biometria local resolve desbloqueio e não resolve identidade. Ela é do aparelho, não é compartilhada entre aplicativos, e não é ela que evita a pessoa digitar a mesma senha em cinco lugares.

Limite escrito, e ele importa: só funciona dentro do mesmo domínio. Dois gerenciadores diferentes não compartilham a chave, e trocar de celular só migra junto dentro do mesmo ecossistema. Recurso com limite escrito é recurso que não vira promessa quebrada na tela.

De volta, sem digitar de novo
Credencial recusada
A volta e a recusa, as duas telas que decidem se a pessoa entra. Na primeira o perfil já está salvo e a entrada é um toque, com as três ações de maior uso à mão. Na segunda a credencial não passou, e o aviso fica em cima do campo que errou, com o texto dizendo o que fazer em vez de repetir que deu erro.

D6 · A marca no login se decide com pesquisa, não com gosto

Nos aplicativos dos parceiros a nossa marca estava solta: cada tela pensada uma a uma, sem regra. O risco é direto, e é de conversão: a pessoa entra num aplicativo com uma credencial que ela não reconhece. "Entrar com o Google" tem hegemonia para fazer isso. Nós ainda não temos.

A posição do negócio hoje é seguir com a marca do cliente enquanto não houver escala. Em vez de defender gosto contra isso, fui buscar o padrão mínimo de apresentação de marca em fluxo de login para trazer dado para a mesa.

E levantei a questão que ninguém tinha levantado: login intermediado tem que ficar claro para quem entra, e isso é obrigação da lei de proteção de dados, não acabamento. O modelo é o de transbordo, o mesmo de pagar com a carteira do telefone: a pessoa sabe que passou por outra instituição.

Proposta mínima que saiu: uma linha de "autenticação pela CPF Seguro" abaixo do logotipo do parceiro, mantendo as cores dele. Custa uma linha de texto e resolve transparência e reconhecimento ao mesmo tempo.


06 Craft

Visão geral do operador1440×1027A terceira superfície, a que ninguém mostra em portfólio. Aqui o operador vê o funil de cadastro do aplicativo próprio quebrado por fase, com a queda entre um degrau e o outro. É a tela que responde onde o cadastro está perdendo gente, e é ela que sustenta o atendimento quando um alerta chega errado.
A conta de um cliente1440×1077A mesma pessoa vista pelo operador. A aba CPF Seguro traz o "Pausar CPF", que é a ação de maior consequência do produto, e as duas listas de quem gerencia o CPF de quem: a relação que o aplicativo mostra como duas linhas na home aparece aqui inteira, com convite pendente e resposta em aberto.
  • 88 peças de tela com opções, valores e padrão declarados num só lugar.
  • 22 fluxos auditados por programa, com saída legível.
  • Carteiras de banco desenhadas uma por uma, com a regra de uso definida no sistema e a arte no produto.
  • Documentação navegável publicada na web, atrás de autenticação.
  • Verificação rápida em 16 segundos, completa em 2 minutos, e testes de imagem comparando cada tela com a versão aprovada.
  • Na migração para o sistema novo, mantive 200 apelidos de nome para que nenhuma chamada existente no app quebrasse.

07 Resultado

  • Três superfícies em um sistema, com o modo parceiro previsto, medido e no ar.
  • O sistema chega no app por versão numerada, com um registro que diz o que muda em cada uma.
  • O que esse registro expôs quando nasceu: 176 versões publicadas desde a última que o app havia adotado, e nenhuma linha dizendo o que mudou.

Dois produtos no mesmo esqueleto de tela. O aplicativo próprio tem dois públicos que não são o mesmo: quem usa de verdade, que precisa do que está pronto, e a demonstração para parceiro e investidor, que precisa mostrar o caminho todo. A saída foi tratar como dois produtos com o mesmo esqueleto, e deixar o servidor decidir o que aparece em cada ambiente. Antes disso a mesma tela tentava servir os dois, e o resultado é o que sempre é: função visível sem ação por trás.

E o processo, que era o gargalo maior que a tela. As demandas chegavam uma a uma, cada uma mexendo em várias telas, e nenhuma definição estava escrita. Sem isso, cada pessoa defende a sua leitura e a discussão vira quem fala mais alto. Propus um comitê de produto interno, duas vezes por semana, com três obrigações: escrever o objetivo de cada tela, versionar a página inicial e guardar o histórico de decisão. A proposta foi aceita. Ela não é desenho, e é a coisa que mais mudou o meu trabalho ali.

Onde o número é medido. O painel de operação quebra o cadastro por fase e mostra a queda de um degrau para o outro, então a pergunta "onde estamos perdendo gente" tem uma tela para responder. Foi essa leitura que sustentou o corte do fluxo embarcado para seis telas, com entrada por SMS e sem passar pela loja de aplicativos: o degrau mais caro do funil é a instalação, e o modo parceiro é a versão do produto que não tem esse degrau.


08 O que eu faria diferente

Um ícone sumia em silêncio e eu levei tempo para achar. Quando o sistema é instalado como dependência, os arquivos de imagem mudam de lugar, e o programa que os carrega devolvia vazio em vez de erro. A tela ficava certa, só sem o ícone. Custou dez testes de imagem antes de alguém notar.

Falha silenciosa é a pior categoria de defeito em qualquer produto. Num produto que vende confiança, é a pior de todas: o usuário não vê um erro, vê uma instituição desleixada. Hoje eu faria a busca de imagem falhar alto.


Próximo case
Directo · Creator
  • design systems
  • product design
  • fintech
  • ia no processo
  • multimarca
  • acessibilidade
  • pesquisa