LP
Larissa Praxedes
Voltar para pagina inicial
CASE STUDY · MAGALUPAY
Fazer dez mil pagamentos de uma só vez já é uma realidade no MagaluPay.
Se tempo é dinheiro, podemos dizer que quem opera o Painel Admin no MagaluPay está milionário. Não é nem possível estimar quanto tempo do usuário foi poupado com essa nova forma de gerenciar Eventos.
Papel
Product Designer
Área
Backoffice
Período
Out 2024 a Fev 2025
Plataforma
Web
O ponto de partida
No MagaluPay, um evento é o registro que movimenta saldo entre carteiras digitais. É o mecanismo por trás de cashback, promoção, reembolso e ajuste de saldo. Alguns eventos são positivos e creditam a carteira. Outros são negativos e debitam.
Esses eventos viviam espalhados entre um portal legado e as APIs internas. O novo Portal Admin nasceu para concentrar a operação, começando por gestão e listagem. A criação de lotes foi habilitada depois, e é sobre ela que este case fala.
- Desenhei o fluxo que permite enviar até dez mil pagamentos de uma vez, por planilha, com validação automática linha a linha e aprovação humana registrada antes de qualquer $$$ sair.
- Atuei do discovery ao handoff, e o trabalho foi menos sobre o upload em si e mais sobre a rede de proteção em volta dele: o que acontece quando a planilha vem com erro, quando tem linha duplicada, quando ninguém aprova a tempo.
Problema × Solução
Problema
Lançamento unitário: um evento por vez, um formulário por vez, inviável para quem paga milhares de recebedores no mesmo dia
Conferir milhares de linhas na mão não é possível, e o erro só apareceria depois do dinheiro sair
Corrigir um arquivo com problema significaria recomeçar o lote do zero
Nenhum registro de quem autorizou o pagamento e em que momento
Solução
Criação de lote por planilha, em três etapas guiadas, com modelo padrão disponível para download
Validação automática linha a linha antes de qualquer pagamento, com relatório de erros e relatório de duplicidade baixáveis
Ação de substituir arquivo, que dispara nova validação sem descartar o lote nem o trabalho já feito
Workflow de aprovação com responsáveis configurados, oito estados visíveis e sete e-mails notificando cada mudança
Discovery
Esse projeto não começou com entrevistas de usuário, começou com conversas recorrentes com o PO e com os desenvolvedores para mapear o que o sistema permitia, o que a operação já fazia na mão e onde as coisas quebravam em escala.
Percebi que o conjunto de restrições é o problema de design nesse caso.
O que recebi pronto e o que decidi
- Algumas regras chegaram definidas. O teto de dez mil eventos por lote, por exemplo, veio do time. O que coube a mim não foi o número, foi decidir que ele precisava ser visível antes do envio, e não depois da falha. Por isso o limite aparece no conteúdo de ajuda e a recusa acontece ainda na pré-validação, quando o usuário não perdeu tempo nenhum.
O FAQ como evidência do levantamento
- Escrevi o conteúdo de ajuda respondendo perguntas bem específicas: qual a quantidade mínima e máxima, onde baixar a planilha padrão, por que um lote é recusado, o que acontece se ninguém aprovar a tempo. Cada uma dessas perguntas existe porque alguém perguntou. O FAQ virou o registro visível do que foi descoberto.
A jornada
Desenhei a criação quebrada em etapas curtas, em vez de um formulário único, para que o usuário resolvesse uma decisão por vez.
Etapa 01
Informações do lote
Tipo de evento e data de pagamento. Sem os dois, não avança.
Etapa 02
Envio do arquivo
Upload com pré-validação de colunas e formato, antes de processar o conteúdo.
Etapa 03
Revisão
Resumo do que será lançado, com quantidade e valor total, antes de confirmar.
O maior desafio veio logo depois
Desenhar o caminho feliz levou pouco tempo. O trabalho real foi tratar tudo o que acontece quando a planilha não está perfeita. Criei dois relatórios baixáveis, relatório de erros e relatório de duplicidade, para que a correção acontecesse no próprio arquivo em vez de virar caça ao problema na tela. E a ação de substituir arquivo revalida o lote sem obrigar a recomeçar.
Bloquear ou avisar
A duplicidade recebeu tratamento diferente do erro de formato, e essa foi uma decisão de produto, não de tela: linha duplicada às vezes é intencional. Então em vez de bloquear, o sistema avisa, mostra quais são e devolve a decisão para quem enviou.
Estados como espinha dorsal
O lote virou um objeto com ciclo de vida próprio, e cada estado ganhou card, drawer e comunicação específicos:
- O card de lote é um componente com oito variantes. A estrutura nunca muda: status no canto, identificador e tipo do evento à esquerda, valor no centro e o botão de detalhes sempre no mesmo lugar. Quem acompanha vinte lotes visualiza a coluna de status e vai direto ao que pede atenção.
- A cor entra só quando significa alguma coisa. Estados em andamento ficam em cinza, porque não exigem nada de ninguém. Aprovado, rejeitado e erro ganham cor no selo e no contorno do card, e o olho encontra a exceção antes de ler qualquer palavra.
- O componente também explica a si mesmo. Estados ambíguos trazem um ícone de ajuda com a explicação no próprio lugar, e o aviso de erro informa quantos eventos precisam de correção, o que isso impede e onde está o relatório. Data de pagamento e faixas de aviso aparecem apenas onde fazem diferença.
Aguardando aprovador
Lote de eventos
#002
-
Ação judicial
Pagamento:
23/11/2024
Valor total do lote
R$
21.940,37
Conferir valores
Lote rejeitado
Lote de eventos
#005
-
Ação judicial
Pagamento:
23/11/2024
Valor total do lote
R$
11.000,00
Detalhes do lote
Problema na validação
Lote de eventos
#012
-
Ação judicial
Valor total do lote
R$
21.940,37
Detalhes do lote
Pagamento:
23/11/2024
5090
Eventos lançados necessitam ser corrigidos para o envio do lote para o aprovador.
Lote abortado
Lote de eventos
#014
-
Ação judicial
Pagamento:
23/11/2024
Valor total do lote
R$
21.940,37
Detalhes do lote
Validando lote
Checando todos os eventos lançados na planilha. Isso pode demorar alguns minutos.
Lote de eventos
#014
-
Ação judicial
Valor total do lote
R$
21.940,37
Detalhes do lote
Pagamento:
23/11/2024
Lote expirado
Lote de eventos
#008
-
Ação judicial
Pagamento:
23/11/2024
Valor total do lote
R$
11.000,00
Detalhes do lote
Regras viram interface
Comecei pela tabela, que é onde o seller passa o tempo dele. Três decisões definiram o redesenho, e nenhuma delas foi estética.
Teto de dez mil eventos
Acima disso o arquivo precisa ser dividido. A tela avisa antes do envio, não depois da falha.
Expiração amarrada ao pagamento
Se a correção não acontece até a data de pagamento, o lote expira. O prazo fica visível desde o início.
Abortar o lote é irreversível
Ação destrutiva isolada, com confirmação explícita nomeando o lote que será excluído.
Quem cria não aprova
Criar, aprovar e rejeitar são permissões distintas. Nenhuma pessoa sozinha move o saldo.
Ao clicar em Criar Novo Lote o usuário segue com o fluxo todo em um drawers lateral, que já é um padrão do Portal Administrativo.
Depois da criação vem a aprovação
Como já mencionei, apenas uma pessoa que não tenha criado o lote tem a capacidade para o aprovar.
Em backoffice financeiro, a tela mais importante não é a do sucesso. É a que aparece quando algo deu errado com dez mil linhas.
Onde chegamos
01
Extrato de vendas redesenhado
Tabela, colunas de desbloqueio, motivo do bloqueio e acesso ao detalhe do pedido.
02
Navegação e filtros
Padrão da Central de Relatórios, ordenação invertida e paginação revista.
03
Extrato de Recebimento
A fusão de repasse e extrato, com cards de antecipação e de dívidas.
04
Fluxo de primeiro acesso
Proposto por mim, especificado e entregue como épico próprio.
Nove entregas concluídas entre outubro de 2025 e fevereiro de 2026, em parceria com produto e com outra designer do time.
O impacto
Um processo auditável de ponta a ponta, no qual nenhum saldo se move sem passar por validação automática e por uma aprovação humana registrada, feita por alguém diferente de quem criou o lote.
01
Fluxo de criação
Da configuração do lote ao upload e à revisão final.
02
Sistema de estados
Oito estados com cards, drawers e detalhamento por lote.
03
Sete e-mails
Um para cada momento do ciclo, com destinatário e gatilho definidos.
04
Conteúdo de ajuda
FAQ cobrindo limites, planilha padrão, erros e expiração.
O que levo comigo
Esse projeto me ensinou que, em backoffice, o fluxo de erro é o produto. Desenhar o caminho feliz é a parte rápida. O que define se a ferramenta será usada com confiança é o que acontece quando a planilha vem torta, e se a pessoa consegue entender o problema, corrigir e seguir sem recomeçar. Ganhar tempo sem perder a segurança.
E aprendi a separar o que recebi do que decidi. Várias regras deste produto chegaram prontas, definidas por produto e engenharia. O desafio não estava em criá-las, estava em escolher o momento em que cada uma se torna visível para quem está prestes a mover o dinheiro de dez mil pessoas.