LP
Larissa Praxedes
Voltar para pagina inicial
CASE STUDY · MAGALUPAY
Senha Transacional - Às vezes o óbvio ainda precisa ser feito.
Aqui conto como criei as principais jornadas de senha transacional para pessoa física no MagaluPay. A conta PJ já tinha a dela. A PF, não.
Papel
Product Designer
Área
Conta
Período
Set 2025 a Jan 2026
Plataforma
App
O ponto de partida
A senha transacional é o que autoriza uma transferência, um Pix ou um pagamento com saldo. No MagaluPay ela já existia na conta pessoa jurídica, mas não na pessoa física. O objetivo do projeto, escrito no próprio épico, era direto: criar as jornadas de senha transacional para o MPay PF, tendo as jornadas do PJ como referência.
Não era, portanto, um caso de unificar fluxos bagunçados. Era construir do zero, com a vantagem e a armadilha de já existir um precedente interno.
A vantagem é não partir de uma folha em branco. A armadilha é herdar decisões que talvez não sirvam para um público diferente.
E há uma tensão que atravessa qualquer produto de segurança: cada camada de proteção que você adiciona é um passo a mais entre a pessoa e o dinheiro dela. Errar para o lado frouxo é risco. Errar para o lado rígido é abandono no meio do caminho.
Problema × Solução
Problema
- A conta PF não tinha senha transacional, enquanto a PJ já tinha
- A senha aparece em momentos muito diferentes: criar, recuperar, confirmar um Pix, pagar com saldo
- Cada verificação a mais é uma chance a mais de a pessoa desistir no meio
- Ter a funcionalidade disponível não significa que alguém vá criá-la
Solução
- Jornadas desenhadas por cenário, e não por tela isolada
- Um padrão único reutilizável entre criação, recuperação e uso na transação
- Verificação facial no lugar de código por mensagem, onde a segurança exigia
- Um gatilho na home convidando o cliente a criar a senha antes de precisar dela
Discovery
Mapeamos certezas, suposições e dúvidas relacionadas a criação, gestão e recuperação de senha transacional.
Em paralelo, estudei as jornadas que já existiam no PJ. A pergunta que guiou essa leitura não era "como copiar", e sim o que dessa solução serve para um cliente pessoa física e o que precisa mudar.
Pensar por gatilhos, não por telas
- A senha não tem uma tela. Ela tem momentos: quando o cliente decide criar por conta própria, quando ele esbarra nela no meio de uma transação, quando esquece, quando confirma um Pix. Mapeei esses gatilhos primeiro e só depois desenhei, o que garantiu coerência mesmo entre fluxos que começam em lugares distintos do app.
Criação de senha
Durante a transação
Recuperação de senha
Recuperação de senha
Validação da senha
Alteração de senha
Checkout (despriorizado)
A jornada
A primeira entrega saiu em novembro de 2025, com cinco jornadas: criação a partir do gatilho, criação dentro do fluxo da transação, recuperação, Pix (realização, agendamento e cadastro de chave) e pagamento com saldo no checkout e na wallet. Senha de seis dígitos.
Em janeiro chegou a revisão. Não para expandir o escopo, e sim para reduzi-lo e simplificar ainda mais.
O que era
Senha de 6 dígitosRecuperação por código enviado ao cliente (OTP)Disponível para toda a basePix e pagamento com saldo no checkoutSenha no checkout nesta entrega
O que passou a ser
Senha de 4 dígitosRecuperação apenas por verificação facialGatilho de criação apenas para clientes N2Foco apenas em transações PixCheckout adiado, com solução futura dentro da wallet
Trocar código por validação facial
A decisão mais interessante foi remover o OTP da recuperação e manter só o liveness. Parece contraintuitivo tirar uma camada de um fluxo de segurança, mas código enviado por mensagem é justamente o elo que golpistas sabem interceptar, e ainda por cima adiciona espera. A verificação facial resolve os dois problemas de uma vez: é mais difícil de burlar e acontece na hora.
Em fevereiro voltei uma última vez a esse ponto, para reposicionar o liveness dentro dos fluxos de criação durante a transação e de esqueci minha senha. Onde a verificação entra muda completamente a sensação de quem está no meio de um pagamento.
Uma funcionalidade de segurança só protege quem a ativa, e ninguém acorda com vontade de criar uma senha.
Por isso desenhei um gatilho na home: um card de utilidade com ícone de escudo, o título "Deixe sua conta mais segura" e um botão direto de criar senha, exibido para os clientes elegíveis antes que eles esbarrem na senha no meio de uma transação.
É a diferença entre disponibilizar e convidar. O fluxo mais bem desenhado do mundo não serve para quem nunca chegou nele.
Em segurança, cada camada a mais é um passo a mais entre a pessoa e o dinheiro dela.
A pergunta nunca é quanta proteção cabe, é onde ela dói menos.
Documentação e handoff
Cada jornada virou um board próprio, com cabeçalho padronizado de status, data de atualização, designer e PO responsáveis. Dentro deles, o fluxo corre da esquerda para a direita com pontos de decisão, caminhos de sucesso e de erro sinalizados, estados de fim de fluxo e cartões de anotação explicando as regras ao lado das telas.
O arquivo também separa visualmente o que foi entregue, o que aguarda validação e o que saiu do escopo. Quem abre depois entende não só o que existe, mas o que foi decidido não fazer.
Onde chegamos
5 jornadas mapeadas
Jornadas mapeadas por gatilhos de acordo com o momento que o usuário está vivendo dentro do App
3 momentos da senha
Criar, usar e recuperar, sob o mesmo padrão reutilizável.
2 caminhos de criação
Pelo gatilho na home ou dentro do fluxo da transação.
5 decisões revistas
Dígitos, público, escopo, recuperação e checkout. Todas reduzindo.
O impacto
A conta pessoa física passou a ter senha transacional com um padrão único entre criação, uso e recuperação. E a segunda versão entregou menos superfície com mais segurança: menos dígitos, menos público, menos tipos de transação e uma camada de verificação mais difícil de burlar.
O que levo comigo
Aprendi a pensar por gatilhos e cenários, não por telas. Senha não é uma interface, é um momento que se repete em contextos diferentes. Mapear os momentos primeiro foi o que garantiu coerência entre fluxos que nascem em lugares distintos do app.
Aprendi também que cortar escopo pode ser a decisão mais madura de um projeto. A revisão reduziu quase tudo: dígitos, público, tipos de transação. Defender uma entrega menor e mais segura é mais difícil do que defender uma entrega maior, porque parece menos trabalho quando é exatamente o contrário.
E levo a lembrança de que disponibilizar não é a mesma coisa que convidar. O gatilho na home foi a parte que ninguém pediu, e é a que garante que o resto do trabalho encontre alguém do outro lado.