De sistema terceirizado a produto proprietário para controlar o dinheiro de mais de 1.200 lojas, com mais agilidade e mais segurança
Visão geral
O tesoureiro de uma loja Magalu cuida de todo o dinheiro físico que passa pelo caixa. Ele abre e fecha o caixa, faz dezenas de sangrias e depósitos bancários por dia, controla suprimentos e notas de débito. Em uma rede com 1.246 lojas e R$ 5,2 bilhões de vendas em lojas físicas no 2T26 , qualquer atrito nesses processos se multiplica todos os dias, e qualquer brecha de segurança também.
Em 2022, o contrato com o fornecedor do sistema de tesouraria estava perto do fim. A empresa decidiu construir um produto próprio para resolver três dores: custo alto, dependência de terceiros para entregar novas funcionalidades e pouco controle sobre o numerário.
Entrei no time durante essa troca. Desenvolvi discoverys essenciais, realizei entrevistas com usuários, desenhei os fluxos das principais funções do produto (sangria, depósito bancário, criação e administração de notas de débito, entre outras), prototipei em alta fidelidade evoluindo o design system e validei tudo com stakeholders. Hoje, o sistema está implantado com sucesso em todas as lojas. A partir de 2025, incorporei IA ao meu processo de discovery, design e handoff.
O desafio
Não bastava redesenhar telas de um sistema existente. Era preciso reconstruir a operação financeira de um grande varejo em um produto novo, para perfis muito diferentes: tesoureiros de loja e de escritório, times de SRC, conciliação, antifraude e contabilidade. Cada cargo tem acessos, responsabilidades e riscos próprios.
O desafio era criar uma experiência mais simples para quem opera, sem abrir brechas para erro humano ou fraude.
Processo
1. Aprender o processo com quem o executa
Antes de desenhar qualquer fluxo, eu fazia entrevistas online e presenciais com os profissionais e times responsáveis pelo processo que iria redesenhar. Pedia que me mostrassem, na prática, como trabalhavam hoje e quais eram os pontos mais relevantes, as dores, os riscos de fraude e os riscos de erro humano.
Essas conversas eram a minha porta de entrada em um domínio novo. Ao longo de toda a sprint, eu voltava a elas para tirar dúvidas e validar conceitos com quem conhecia a operação de perto. Nesse caminho, estive em contato constante com tesoureiros e com os times de contabilidade e antifraude.
2. Pesquisa específica para cada perfil
O sistema tem visões diferentes por cargo. Por isso, a pesquisa era refeita a cada novo fluxo, respeitando o contexto de cada usuário, sem generalizar.
3. Desenhar para a segurança, mesmo quando isso incomoda
Havia dados sensíveis que só os times de escritório ou os gerentes de loja podiam acessar, e as experiências precisavam ser desenhadas sem brechas.
Em um momento do projeto, descobrimos que um dado exibido no sistema podia ser usado por colaboradores mal-intencionados para reorganizar identificadores de gastos, fechar o balanço e encobrir uma saída indevida de valores. Decidimos restringir ainda mais o acesso a essa informação. A decisão gerou bastante reclamação dos usuários, mas foi a correta para proteger o negócio.
4. Prototipação, testes e negociação
Criei fluxos de usabilidade, propus conceitos, prototipei em alta fidelidade, evoluí o design system e testei com usuários reais. Cada entrega foi negociada com tecnologia, produto e negócio. Meu papel era ser a voz dos usuários nessas conversas, sem deixar que a conveniência se sobrepusesse à segurança.
Evolução do processo com IA (a partir de 2025)
Em 2025, passei a incorporar LLMs e agentes ao meu trabalho nas demandas de tesouraria. A ideia não era substituir o olhar do designer, e sim tirar o trabalho operacional do caminho: documentar, organizar, montar versões iniciais. Isso deixava mais tempo para o que exige julgamento, como entender o usuário, decidir e defender as escolhas.
- Discovery: das conversas aos insumos
Passei a gravar as agendas de briefing e as entrevistas com usuários, com os registros documentados automaticamente. Reunia todo esse material no Gemini Notebook (antigo NotebookLM), que me ajudava a tabular entrevistas, gerar fluxos de usabilidade, mapas de empatia e mapeamento de oportunidades a partir do que os usuários realmente disseram.
- Documentação as-is automatizada
Nas entrevistas, era comum o usuário compartilhar a tela para mostrar o sistema que usava e como executava suas tarefas diárias. Aproveitei isso e desenvolvi, no Antigravity, uma aplicação em que eu subia as gravações. Ela mapeava o fluxo de uso e gerava os prints das telas, alimentando o registro as-is da documentação de discovery.
- Design: layouts a partir da biblioteca de componentes
Como a tesouraria tinha uma biblioteca robusta de componentes, usei tanto o Stitch do Google quanto os agentes do Figma para gerar sugestões de layout a partir de um prompt com as features e os dados relevantes da tela. Como partiam de componentes reais, as sugestões já nasciam alinhadas ao design system.
- Validação: testar conceito e usabilidade
Usei o Figma Make para testar conceitos e a usabilidade das telas prototipadas com usuários e stakeholders, em rodadas de validação antes de qualquer desenvolvimento.
- Handoff: fidelidade ao design system
Concluídas as validações, fazíamos o handoff com os desenvolvedores pelo MCP do Figma. Isso nos deu mais controle sobre a versão dos componentes em produção e garantiu que eles seguissem as características e os tokens definidos no design system.
| Etapa | Ferramenta | O que mudou |
| Discovery | Gravações + NotebookLM | Registros automáticos e sínteses (fluxos, mapas de empatia, oportunidades) |
| As-is | Aplicação própria no Antigravity | Fluxos e prints gerados a partir das gravações |
| Design | Agentes do Figma e Google Stitch | Sugestões de layout a partir da biblioteca de componentes |
| Validação | Figma Make | Testes de conceito e usabilidade com usuários e stakeholders |
| Handoff | MCP do Figma | Controle de versão e aderência aos tokens do design system |
Resultados do lançamento
Para medir o impacto, fui até as lojas e cronometrei os processos reais, ao vivo, comparando o sistema anterior com a Nova Tesouraria. Os cliques incluem a digitação de senhas, credenciais e valores, para refletir o esforço real do usuário.
| Processo | Antes | Depois |
| Fechamento de caixa | 49 cliques | ~23 cliques (−53%) |
| Suprimento | 16 cliques · ~1 min | ~6 cliques · ~30 s (−63% cliques, −50% tempo) |
| Abertura de caixa | 22 cliques · 1 min | ~15 cliques · ~30 s (−32% cliques, −50% tempo) |
| Depósito bancário | 10 cliques · 10 min | ~15 cliques · ~1 min (−90% tempo) |
| Notas de débito | 10 cliques · ~1 min | ~20 cliques · ~1 min |
| Sangria | 4 cliques | 4 cliques · ~10 s |
Menos retrabalho no suprimento. No sistema anterior, o valor precisava ser enviado separadamente para os PDVs e a nova experiência reduziu esse fluxo de 16 para cerca de 6 cliques.
Quando mais cliques foi a decisão certa. Em depósito bancário e notas de débito, o número de cliques aumentou de propósito. Incluímos etapas de segurança que o sistema antigo não tinha, como a justificativa digitada. Mesmo assim, o depósito caiu de 10 minutos para cerca de 1, e as notas de débito, uma tarefa diária, mantiveram o tempo médio de 1 minuto, agora com mais rastreabilidade. A meta era reduzir o tempo sem abrir mão da segurança, e não apenas contar cliques.
Mais funções no mesmo lugar. A Nova Tesouraria trouxe para dentro do produto tarefas que dependiam de outros sistemas ou não existiam:
- Pendência zero: 3 cliques, ~5 s
- Gestão de sobras: 3 cliques, ~5 s (antes exigia o sistema Kirk além da tesouraria)
- Extrato: ~5 cliques, ~10 s
- Parametrizações: ~6 cliques, ~10 s
- Troca de tesoureiros: ~15 cliques, ~1 min
- Restituição de cancelamento: agora feita direto no PDV, sem passar pela tesouraria
Impacto para o negócio. A empresa passou a ter autonomia sobre o roadmap, deixou de depender do prazo de um fornecedor externo, ganhou controle sobre o numerário e implantou o sistema em toda a rede de 1.246 lojas.
Aprendizados
Entender o trabalho vem antes de desenhar. Só consegui propor boas soluções depois de observar e ouvir quem lida todos os dias com o dinheiro da empresa. Em um domínio complexo, o repertório do designer se constrói nas conversas com os usuários.
Nem toda boa experiência é a mais rápida. Em um produto financeiro, tirar atrito do lugar errado cria risco. Aprendi a decidir onde manter o atrito e a explicar o porquê aos usuários.
Ser a voz do usuário não é dizer sempre sim a ele. É entender suas dores a fundo e, quando necessário, defender decisões impopulares com argumentos claros.
IA amplia o designer, mas não decide por ele. Automatizar o que é repetitivo me deu tempo para o que só o designer pode fazer: ouvir, interpretar e decidir. Aprendi também que o resultado depende da qualidade dos insumos, e por isso a biblioteca de componentes bem estruturada foi o que tornou os layouts gerados utilizáveis.
