Pix Automático · Banco do Nordeste

O time, o banco e o regulador

O Pix Automático é uma funcionalidade regulatória criada pelo Banco Central que moderniza o conceito de débito automático. Diferente do modelo tradicional — que podia levar dois ou três ciclos para entrar em vigor — ele é configurado e ativado instantaneamente, e o valor é creditado ao recebedor em tempo real.

O produto foi desenvolvido para o Banco do Nordeste, banco público com mais de 5,3 milhões de clientes e um dos maiores programas de microcrédito da América Latina. O BNB atende desde microempreendedores e pessoas físicas do interior do Nordeste até empresas de médio porte — uma base diversa, com necessidades igualmente diversas.

Atuei como único UX Designer do Time Pix, em um modelo de fábrica de software onde a G4F fornece o time técnico (UX, analistas de requisitos, devs e testers) para o banco. O equipe toda era composta por UX, PO, Analista de Requisitos, desenvolvedores, testers e QA.

O fluxo de trabalho seguia uma esteira Kanban: a PO abria o card com a demanda, eu analisava o escopo, agendava uma reunião de alinhamento, prototipava no Figma e apresentava o resultado em uma reunião de validação com PO, analistas e um dev sênior. Quando havia divergência entre dev e produto — o que acontecia com frequência — eu atuava como mediador para convergirmos em uma solução viável.

Sem discovery, mas com autonomia onde importa

No modelo de fábrica de software, a maioria das demandas chegam a partir das plenárias do Banco Central. O BACEN comunica novas funcionalidades e mudanças regulatórias com documentação detalhada — do manual do usuário às especificações técnicas. O Pix Automático era uma dessas funcionalidades com prazo obrigatório de implementação.

A PO e o time de negócios do BNB traduziam isso em cards de desenvolvimento. A margem para discovery era pequena — o banco opta por seguir a proposta do BACEN de forma bastante fiel. Não havia espaço para grandes experimentos.

Mas havia espaço onde importava: como não podia criar componentes novos ou alterar a biblioteca visual existente, concentrei minha energia em duas dimensões onde eu tinha real autonomia — simplificar ao máximo as jornadas e melhorar a qualidade da escrita das mensagens, notificações e textos de interface.

Design nem sempre é sobre a tela mais bonita. Às vezes é sobre a jornada mais curta e a frase mais clara.

Projetar dentro da caixa

O Time Pix opera com uma biblioteca de componentes depreciada — anterior ao design system moderno que o time interno do BNB desenvolveu. Para adotar o novo sistema, seria necessário que o time de desenvolvimento refatorasse todo o front-end e modernizasse as stacks. O que nunca se torna prioridade quando o negócio está funcionando.

Na prática, isso significava seguir estritamente os componentes já existentes em produção. Sempre que eu propunha melhorias visuais além desse escopo, o time de dev implementava como estava no ambiente deles — gerando divergências nos testes e retrabalho, já que o time de governança do BNB audita todas as entregas com comparações rigorosas entre protótipo e entrega final.

Para contornar isso de forma produtiva, passei a usar o time de homologação como principal referência visual. O ambiente de desenvolvimento não reflete fielmente o de produção — e como o time de homologação é interno do BNB e tem acesso ao ambiente real, eles se tornaram minha fonte mais confiável antes de prototipar qualquer tela.

Em paralelo, tenho articulado com pessoas do BNB (que possuem algum tipo de influência) a migração gradual para o design system atual. Uma conversa que ainda está em andamento — mas que já tem tração com alguns stakeholders do time técnico.

Quando a criatividade vai para onde ela pode

Não foram criadas ilustrações ou elementos visuais personalizados neste projeto. O escopo se limitou ao design de telas dentro dos componentes e estruturas já estabelecidos pela biblioteca existente.

E tá tudo bem.

Trabalhar com restrições não é uma limitação criativa — é um exercício de precisão. Toda a energia que em outros projetos iria para exploração visual foi redirecionada para arquitetura de informação, hierarquia dos elementos em tela e qualidade da escrita. São as dimensões onde eu tinha margem real de contribuição — e onde o impacto para o usuário era mais direto.

Stepper, sim. Texto simples, quase

O que não ficou — UX Writing

Em várias telas, propus substituir termos excessivamente formais por uma linguagem mais acessível. O produto é usado por um espectro amplo de pessoas — de microempreendedores do interior do Nordeste a empresários — e eu usava ferramentas de análise de complexidade textual para embasar as sugestões.

Em alguns casos a PO aprovava na validação do protótipo. Mas ao revisar a documentação antes de ir para dev, ela mudava de ideia — e eu tinha que reverter tudo, mesmo com as evidências em mãos.

Aprendi que nem toda batalha de UX Writing é uma batalha de design. Algumas são batalhas institucionais. Reconhecer essa diferença me tornou mais eficiente — e menos frustrado.

O que ficou — stepper no fluxo de autorização

No fluxo de autorização do Pix Automático, havia um conjunto extenso de campos configuráveis — que variavam de acordo com o que o recebedor havia definido na cobrança. A proposta inicial era apresentar tudo em uma única página.

Mostrei que, no mobile, aquela tela se tornaria longa demais e difícil de navegar. Propus substituir pela navegação em stepper, agrupando os campos de forma que as configurações mais flexíveis ficassem concentradas em uma mesma etapa. A PO concordou — e a solução também facilitou a vida do time de dev, que conseguiu gerenciar as condicionais de cada etapa de forma mais organizada.

Uma decisão simples, mas que melhorou a experiência para o usuário e o processo para o time.

O resultado dentro das condições reais

As telas foram prototipadas no Figma com fidelidade ao ambiente de produção do BNB, usando exclusivamente os componentes da biblioteca existente. A entrega cobriu três frentes:

• Web — fluxo completo do Pix Automático
• Mobile — mesmo fluxo adaptado para dispositivos móveis
• Backoffice — sistema de operacionalização dos serviços Pix

Por restrições de confidencialidade, as telas são exibidas de forma pontual — priorizando o fluxo de autorização com o stepper e as telas onde o UX Writing teve maior impacto na clareza da informação.

O que um sistema legado me ensinou

Esse projeto reforçou algo que eu já suspeitava, mas nunca tinha vivido com tanta clareza: colaboração em time multidisciplinar não é um valor agregado — é uma competência técnica.

Trabalhar com um sistema legado sem documentação adequada no Figma exigiu que eu construísse uma relação de confiança com o time de desenvolvimento antes de prototipar qualquer coisa. Entender as limitações reais do front-end antes de desenhar evitou ciclos inteiros de retrabalho.

A parceria com o time de homologação foi outro aprendizado que não estava no briefing: em um ambiente onde dev e produção não são iguais, quem tem acesso ao ambiente real se torna um aliado estratégico para o designer. Aprendi a cultivar essa relação ativamente — não por protocolo, mas por necessidade.

E talvez o aprendizado mais difícil: saber quando defender uma decisão com dados — e quando aceitar que o contexto organizacional tem peso igual ao da evidência. No BNB, algumas batalhas de UX Writing não eram batalhas de design. Eram batalhas institucionais. Reconhecer essa diferença me tornou um designer mais eficiente — e mais honesto sobre o que o design pode e não pode mudar sozinho.