Contexto

O GESTCOM digitalizou a gestão de estoque das lojas Leroy Merlin. Um aplicativo Android e um sistema web substituíram os formulários impressos nas operações de IRC, Ajuste Pontual e Conferência Linear.

Meu papel

Fui o único designer do projeto, do entendimento dos fluxos que já existiam até a experiência mobile e os painéis de acompanhamento. Fiz o discovery com os usuários internos, mapeei os processos, defini a arquitetura da informação e os fluxos, prototipei, validei e acompanhei a implementação com o time de tecnologia.

O trabalho pedia traduzir processos feitos em papel, planilhas e vários sistemas em uma experiência mobile simples o bastante para ser usada no meio da operação da loja.

Time18 pessoas. Squad de 13, com product owner, agile master, tech lead, 5 desenvolvedores, QA, tester, automação, especialista SAP e eu como único designer. Mais 2 líderes de domínio e 3 pessoas de Controle Interno (coordenação, análise de gestão e estágio).

Problema

As lojas controlavam o estoque com formulários impressos, carimbos e assinaturas. Cada operação levava em média 8 minutos, custava R$ 3,18 e passava por 3 equipes.

O efeito aparecia em três frentes: baixa acuracidade, retrabalho e um volume de papel entre 100 mil e 210 mil folhas por ano. A satisfação dos times de loja com o processo era baixa.

Discovery

Entrevistas e shadowing com assistentes de gestão durante inventários, levantamento de requisitos com Operações, TI e Supply Chain e análise de logs do SAP.

• 60% do tempo era perdido na conferência manual
• Documentos impressos ficavam expostos nas lojas, um risco de compliance
• Os mesmos lançamentos eram feitos em planilhas locais e no SAP

Decisões

A decisão mais difícil

A primeira tentação em uma transformação assim é reproduzir no celular as mesmas etapas e os mesmos campos dos formulários impressos. O processo mudaria de meio e continuaria tão complexo quanto antes.

Decidi reorganizar o fluxo a partir da tarefa que o operador precisava executar. Cortei etapas, deixei na tela só a informação necessária naquele momento e passei boa parte da interação para o scanner. O que era secundário saiu do caminho principal.

Essa escolha pesava ainda mais pelo contexto de uso: o app roda em aparelhos corporativos, no depósito, muitas vezes com conexão limitada.

Outras decisões

• Aplicativo nativo em Kotlin, pelo desempenho e pela integração com scanners industriais
• Funcionamento offline-first para depósitos com Wi-Fi limitado
• Interface limpa, com retorno imediato a cada leitura para reduzir erro humano
• Login simplificado com SSO corporativo
• Sistema web com acompanhamento em tempo real e dashboards de acuracidade
• Comunicação direta com o SAP por API, sem redigitação

Processo

1. Imersão na operaçãoEntrevistas e shadowing com quem executava as tarefas na loja.
2. Mapeamento dos processosIRC, Ajuste Pontual e Conferência Linear, com os gargalos e as oportunidades de digitalização.
3. Arquitetura dos fluxosFluxos mobile e priorização das informações que aparecem durante a tarefa.
4. Interações de leituraScanner e leitura de produtos, com estados de erro, confirmação e sincronização.
5. Alinhamento técnicoLimites dos aparelhos e da conectividade com o time de tecnologia, e regras do SAP com a operação.
6. ImplantaçãoAcompanhamento do desenvolvimento e da entrada em loja, com os resultados operacionais validando a solução.

Resultado

• R$ 144 milde economia anual projetada
• 9 mesespara o investimento se pagar
• NPS internocolaboradores passaram de detratores a promotores
• Sem arquivo físicoos documentos deixaram de ser guardados em loja
• Prêmio Abrappe 2022Melhor Case de Gestão de Estoques

Números publicados na apresentação do case para a premiação.

Aprendizados

Em produto operacional, o ponto de partida é a tarefa de quem executa. O formulário que existia antes diz pouco sobre ela.

Com o fluxo mais curto, o app nativo e a integração direta com o SAP, a rotina da loja mudou, o custo caiu e o time passou a querer usar a ferramenta.

Contexto

O projeto colocou totens e app de autoatendimento nas lojas para o cliente fazer a compra inteira sozinho, com preço e estoque vindos do SAP e pontos do programa de fidelidade em tempo real.

Meu papel

Fui o único designer do time, responsável por definir e evoluir a experiência de self-checkout, ligando as necessidades dos clientes, os objetivos do negócio e as restrições técnicas da operação de loja.

Conduzi o discovery, defini os fluxos e a arquitetura da experiência, prototipei, validei e especifiquei as interfaces, em conjunto com os times de produto, tecnologia, operações, pagamentos e fidelidade.

Time18 pessoas. Squad de 13, com product owner, agile master, tech lead, 5 desenvolvedores, QA, tester, automação, especialista SAP e eu como único designer. Mais 2 líderes de domínio e 3 pessoas de Controle Interno (coordenação, análise de gestão e estágio).

Problema

As filas nos caixas tradicionais eram longas e a loja perdia vendas nos horários de pico. Quem levava poucos itens esperava na mesma fila dos carrinhos cheios.

Cada pico exigia mais operadores de caixa, o que aumentava o custo fixo. O checkout era pouco digital e desconectado do app da marca.

Discovery

Cronometragem de filas em horários diferentes, entrevistas rápidas com clientes de cesta pequena para entender o comportamento de compra e benchmark em redes internacionais de home improvement.

• 60% dos clientes que compram até 10 itens aceitariam usar self-checkout
• A confiança depende de uma interface clara e de ajuda fácil quando algo dá errado
• A integração com o programa de pontos era desejada

Decisões

A decisão mais difícil

O ponto mais delicado foi equilibrar a autonomia do cliente com a intervenção da operação. Um self-checkout simples demais deixaria a pessoa insegura ou travada quando algo desse errado. Tratar cada exceção como etapa obrigatória deixaria a compra lenta, parecida com a de um caixa convencional.

A saída foi estruturar a jornada para o cliente concluir quase tudo sozinho, com um modo de assistência que só entra em cena quando necessário. Com o fluxo principal separado dos cenários de exceção, a experiência continuou rápida e o apoio humano continuou ao alcance.

Outras decisões

• Leitura de produtos simples, com retorno visual e sonoro
• Tela de pagamento com as opções digitais em destaque
• QR Code para pagar pelo app, unindo a experiência física e a digital
• Modo de assistência para o funcionário intervir em caso de erro
• Totens conectados ao SAP para preço e estoque em tempo real
• Validação antifraude de produtos com câmeras auxiliares
• Acúmulo e resgate de pontos no próprio totem

Processo

1. DiscoveryComportamento de clientes com cestas pequenas, em loja.
2. Jornada completaDo escaneamento ao pagamento e à emissão fiscal.
3. Arquitetura e prioridadesArquitetura de informação, fluxos principais e priorização por impacto no cliente e complexidade operacional.
4. ProtótiposFluxos críticos e cenários de erro, com estados de interface e feedback para reduzir a insegurança no autoatendimento.
5. AlinhamentoEntre UX, tecnologia, pagamentos, SAP, CRM e operação de loja.
6. Implementação e validaçãoAcompanhamento do desenvolvimento, validação depois da implantação e análise dos indicadores de adoção.

Resultado

• 52%dos clientes elegíveis adotaram em 3 meses
• +23 pontosno NPS de checkout nas lojas com self-checkout. Meta: +20
• +18%de uso do programa de fidelidade no ponto de venda
• Cerca de 12%de redução de custos operacionais nas lojas piloto
• 11 mesespara o investimento se pagar
• Mais atendimentooperadores liberados para o atendimento consultivo no salão

Aprendizados

Autonomia e assistência convivem bem quando o fluxo principal e as exceções são desenhados em separado.

Uma dor clássica do varejo virou experiência positiva de marca. A loja ganhou menos fila, mais autonomia para o cliente e dados de jornada de compra para decisões de preço e sortimento.

Contexto

O PLACOM centraliza o planejamento comercial das lojas, automatiza a precificação e gerencia promoções em larga escala, mantendo o mesmo preço em todos os canais.

Meu papel

Fui o product designer na transformação do processo de planejamento comercial e gestão de preços, trabalhando direto com Pricing, Marketing, Supply Chain e tecnologia.

Minha responsabilidade era levar um processo espalhado em planilhas, e-mails e sistemas corporativos para uma experiência centralizada, com visibilidade das decisões, rastreabilidade e controle de aprovação.

Time10 pessoas.

Problema

O planejamento de preços vivia em planilhas e e-mails, com risco constante de desalinhamento entre os times. Liberar uma campanha levava mais de 72 horas.

Faltava uma visão única dos preços e promoções vigentes. A conferência entre ERP, etiquetas e e-commerce gerava retrabalho, erro de preço no ponto de venda e exposição a falhas de compliance e de margem.

Discovery

Workshops de cocriação que facilitei com Pricing, Marketing e Supply Chain, mapeamento do processo e dos pontos de decisão e entrevistas com analistas sobre a jornada de aprovação de preços.

• Mais de 40% do tempo ia só para a consolidação de dados
• Sem log de alterações, auditar era difícil
• As aprovações precisavam funcionar bem no celular

Decisões

A decisão mais difícil

O mais difícil foi decidir quanto da complexidade do processo cada usuário deveria ver. Pricing, Marketing, Supply Chain e gestores têm necessidades diferentes, e colocar tudo na mesma tela daria uma ferramenta poderosa e difícil de operar.

Organizei a experiência em torno das decisões que cada perfil precisava tomar. Hierarquia visual, filtros e revelação progressiva mantêm as informações avançadas disponíveis sem pesar no fluxo principal.

Também tratei o histórico de alterações como parte da experiência, além de requisito técnico. Quem usa precisa entender quem alterou o preço, quando, qual era o valor anterior e que decisão estava sendo tomada.

Outras decisões

• Dashboard inicial com visão por categoria, margem e impacto financeiro
• Aprovação de promoções em 2 cliques
• Filtros avançados por região, loja ou canal
• Alerta visual de risco de margem negativa antes da publicação
• APIs integradas ao SAP para sincronização em tempo real
• Logs de alteração, trilha de auditoria e controle de permissões

Processo

1. Workshops e mapeamentoProcesso atual e principais gargalos, levantados com as áreas de negócio.
2. Arquitetura da plataformaArquitetura de informação e jornadas de planejamento, aprovação e publicação.
3. Dashboards de decisãoPriorização das informações e filtros por loja, região, categoria e canal.
4. Workflows de aprovaçãoEstados, permissões e cenários de exceção.
5. IntegraçõesTrabalho com tecnologia para viabilizar a ligação com o SAP e os demais sistemas.
6. Validação e refinamentoTestes com usuários de negócio e acompanhamento da implementação.

Resultado

• 85% a menosde inconsistências de preço
• 100%das alterações rastreadas em log, com quem, quando e qual preço
• Até +3,5%de margem em categorias sensíveis
• Aprovação no celularcampanhas liberadas direto pelo smartphone ou tablet
• Auditoria em diaconformidade com auditorias internas e externas
• Menos perdaredução das perdas financeiras por erro de preço

Aprendizados

Em ferramenta interna com vários perfis, mostrar a cada um só o que ele precisa decidir rende mais do que mostrar tudo a todos.

O PLACOM levou uma atividade operacional e fragmentada para um processo estruturado de decisão comercial, em que as equipes agem antes do problema de margem aparecer.

Contexto

A atualização do design system unificou a experiência em todas as plataformas, acelerou o desenvolvimento de novos produtos e trouxe consistência visual.

Meu papel

Fui o product designer na evolução do design system, com o objetivo de levar uma biblioteca visual fragmentada para uma base escalável, usada por produtos e plataformas diferentes.

Fiz a auditoria dos produtos, identifiquei padrões e inconsistências, defini componentes e tokens, estruturei a biblioteca no Figma, documentei, alinhei com desenvolvimento e ajudei a definir as práticas de governança.

Time6 pessoas.

Problema

O design system estava desatualizado. Havia componentes duplicados, inconsistência de cores, tipografia e ícones e 3 variações de botão primário em produtos diferentes.

Sem tokens centralizados, a manutenção era cara, design e front-end refaziam trabalho e o onboarding de novos times demorava.

Discovery

Auditoria de UI em 7 produtos digitais, entrevistas com designers e desenvolvedores para mapear gargalos e benchmark com Material Design 3 e Carbon Design System.

• 45% do tempo de desenvolvimento era gasto adaptando componentes
• Faltava documentação clara dos estados hover, focus e disabled
• Cada time usava uma biblioteca de ícones diferente

Decisões

A decisão mais difícil

Havia uma tendência natural de reconstruir no Figma os componentes que já existiam. Isso deixaria a origem do problema intacta: cada produto continuaria decidindo por conta própria sobre estados, espaçamentos, comportamento e acessibilidade.

Decidi estruturar o sistema em princípios, tokens, componentes, documentação e governança, para ele evoluir junto com os produtos.

Também precisei equilibrar consistência e flexibilidade. Padronizar tudo aceleraria a produção no curto prazo e criaria componentes rígidos demais para necessidades legítimas de cada produto.

Processo

1. Auditoria e normalizaçãoLevantamento de 120 componentes em 7 produtos, classificação dos padrões recorrentes e decisão sobre o que consolidar ou descontinuar.
2. Arquitetura e tokensEstrutura da biblioteca e tokens de cores, espaçamento, tipografia e sombras, integrados ao código com Figma Tokens e Storybook.
3. ComponentesRedesign de botões, inputs, modais e tabelas, com estados e comportamentos padronizados e critérios de acessibilidade.
4. Documentação e governançaGuidelines de uso, versionamento e processo aberto de contribuição (DesignOps), com alinhamento entre os times de produto.

Resultado

• 100%dos produtos usando a mesma biblioteca de componentes
• 120 componenteslevantados na auditoria de 7 produtos digitais
• WCAG 2.1 AAcontrastes revisados, teclado e leitor de tela nos componentes críticos
• Menos retrabalhoqueda nas inconsistências visuais encontradas em QA

Aprendizados

Trabalhar no design system é trabalhar na infraestrutura que permite a vários produtos evoluírem de forma consistente.

Bem estruturado, ele encurta o time-to-market, reduz o custo de manutenção e sustenta novos produtos com a mesma experiência.

Contexto

O projeto criou um sistema integrado de fidelidade em que o cliente troca pontos por descontos e vouchers em qualquer canal, sem atrito e com as regras à vista.

Meu papel

Fui o product designer na evolução da experiência de fidelidade omnicanal, ligando o programa de pontos à jornada de compra e transformando o resgate em uma ação de autoatendimento.

Estudei a jornada existente, analisei dados e comportamentos, desenhei a experiência de resgate e os fluxos omnicanal, prototipei, validei e alinhei tudo com os times de CRM, tecnologia, negócio e operação.

Time10 pessoas.

Problema

O programa de fidelidade era pouco usado porque os canais não conversavam. O cliente não via o saldo em tempo real e só conseguia resgatar na loja física, pelo SAC ou em campanhas específicas.

Aplicar o desconto era manual e demorado. A taxa de ativação ficava em 15% da base de clientes.

Discovery

Análise de dados de CRM e de jornadas de compra, entrevistas com clientes ativos e inativos no programa e benchmark dos programas de fidelidade líderes do mercado.

• Os clientes queriam usar os pontos na finalização da compra, sem intermediário
• As regras de acúmulo e resgate eram pouco conhecidas
• As pessoas queriam decidir quando e quanto resgatar

Decisões

A decisão mais difícil

O desafio era fazer dos pontos, até então uma informação passiva, uma ferramenta de decisão durante a compra. Mostrar só o saldo deixava o problema sem solução: o cliente precisava entender quanto podia usar, qual seria o efeito do resgate e o que aconteceria depois de confirmar.

Levei o benefício para dentro do checkout, com a escolha de quanto usar e o impacto financeiro à vista.

Foi preciso equilibrar transparência, flexibilidade e simplicidade, porque as regras do programa e as integrações de backend acrescentavam complexidade ao fluxo.

Outras decisões

• Saldo de pontos visível no carrinho e no checkout
• Seletor de quanto resgatar, parcial ou total, para dar controle ao cliente
• Confirmações claras, como “Você economizou R$ 45 nesta compra”
• Voucher digital para presentear ou usar depois
• API de fidelidade única, sincronizada com o CRM
• PDV, e-commerce, app e televendas consumindo os mesmos endpoints

Processo

1. Jornada atualAnálise da experiência de fidelidade e dos pontos de fricção no acúmulo e no resgate.
2. ComportamentoEntendimento de clientes ativos e inativos no programa.
3. Resgate no checkoutExperiência de pontos dentro da compra e arquitetura do fluxo, com resgate parcial e total.
4. Experiência omnicanalMecanismos de feedback e confirmação e tratamento de erro e indisponibilidade em todos os canais.
5. Regras e integraçãoAlinhamento da experiência com as regras de negócio do programa, junto com CRM e tecnologia.
6. ValidaçãoTeste da clareza das regras de pontos e dos benefícios.

Resultado

• 2,2 vezeso volume de resgates
• +18%no ticket médio dos clientes fidelizados
• +12%na taxa de recompra
• 60% a menosde chamadas ao SAC com dúvidas sobre pontos
• +25 pontosno NPS dos clientes do programa

Aprendizados

O programa, antes um recurso isolado, passou a fazer parte da jornada de compra omnicanal.

Simplificar o resgate e mostrar o benefício na hora da decisão transformou os pontos em motivo de retorno e aumentou o valor de cada cliente ao longo do tempo.