Como modernizamos o autoatendimento web do Banco do Brasil, usado por 2,07 milhões de pessoas, e por que isso exigiu redesenhar também a jornada de quem constrói a plataforma.
Papel
Product Designer Sênior e Tech Lead de UX
Time
Squad Web PF, linhas de negócio, BBDS e 40 designers
Escopo
Pesquisa, arquitetura, UI, design system, DevEx e IA
Plataforma
Web responsivo, Angular DLS
bb.com.br/apf
Nova página inicial: atalhos para as tarefas mais frequentes, widgets de saldo, cartões e atendimento, e o menu contextual.
O problema
Um canal legado com débito técnico, fora do design system do banco (BBDS) e com um menu em que 70% das pessoas não encontravam funções.
O que eu fiz
Conduzi a pesquisa, desenhei a nova arquitetura com centrais e widgets e o modelo de convivência de versões. Do lado de dentro, redesenhei a jornada de quem constrói no canal, com UX desde o início e verificação por IA.
Antes → depois
Antes: 70% não encontravam funções no menu.Depois: nos testes, as pessoas concluíam a tarefa sem travar, e os times passaram a criar 133% mais aplicações por semestre.
01 · Contexto
Um canal para 2,07 milhões de pessoas que não acompanhava o banco
O BB Digital PF é o autoatendimento web das pessoas físicas do Banco do Brasil. O canal tinha débito técnico, estava desalinhado dos outros canais, não usava o BBDS e cada funcionalidade funcionava de um jeito.
Para quem usava, isso aparecia como dificuldade de localizar informações, visual datado, fluxos longos sem autopreenchimento, erros sem orientação e nenhuma personalização.
bb.com.br
Dezenas de opções no mesmo nível.
bb.com.br
Erro sem explicação nem caminho.
Para quem estávamos desenhando
A maior parte do público é adulta madura, entre 41 e 60 anos, com presença relevante acima dos 60, perfil financeiro conservador e vínculo institucional forte: servidores públicos, aposentados, pensionistas e empregados formais. Duas personas guiaram as decisões.
02 · Processo de pesquisa
Transformei um briefing vago numa pergunta mensurável
O pedido era "modernizar o canal". Reescrevi como algo testável: a pessoa consegue encontrar e concluir a tarefa que veio fazer? A partir daí, a pesquisa andou em duas trilhas paralelas.
Estudos
Discovery e benchmarking
Proposta de escopo
Proposta de convivência entre versões
Checklist de acessibilidade da home
Arquitetura de informação: navegação, menu e busca
Testes com usuários
Usabilidade da home
Extrato e pagamentos
Navegação entre versões e onboarding
Card sorting da arquitetura
Menu e arquitetura de informação
Personalização do acesso rápido e da home
11entrevistas em profundidade
8testes de usabilidade
1card sorting
23estudos de referência
O dado que mudou o projeto: 70% das pessoas não encontravam funções no menu legado. O mapa de calor concentrou a atenção em extrato detalhado e novo pagamento. No benchmarking com Nubank, Inter, Mercado Pago, PagBank, Bradesco e Caixa, menus compactos e atalhos para ações frequentes venciam menus cheios.
03 · Arquitetura de informação
Uma vitrine cheia demais confunde. Vazia demais, não informa.
Apresentei cada central como a vitrine de uma loja: o essencial fica exposto e convida a entrar. Com essa imagem, alinhei as áreas de negócio em torno de três ideias:
Centrais: agrupam serviços de um mesmo assunto, como Pagamentos ou Cartões.
Widgets: blocos com funcionalidade e fluxo integrados, a um clique.
Contexto: a função aparece para quem faz sentido. Cashback só para quem tem lançamento elegível, extrato de previdência para quem tem plano, tipo de transferência escolhido dentro do próprio fluxo.
Antes
Depois
Extrato antes e depois: filtros por período no topo, saldos ao lado e as ações relacionadas, como informe de rendimentos e segunda via, no contexto.
04 · Decisões
Quatro decisões que definiram o produto
Decisão 1
Centrais e widgets no lugar do menu hierárquico
Evidência
70% não achavam funções; mapa de calor concentrado em extrato e pagamento; menus compactos funcionando melhor no benchmarking.
O que descartei
Apenas reorganizar o menu legado. Manteria a hierarquia que causava o problema.
Trade-off
Exige governança para cada linha de negócio colocar sua funcionalidade na central certa.
Decisão 2
Widgets predefinidos, que a pessoa reordena e oculta
Evidência
A engenharia, que participou desde o esboço, trouxe um risco real de performance e manutenção no sistema legado.
O que descartei
Widgets totalmente configuráveis.
Trade-off
Menos liberdade de personalização, em troca de algo viável, mais simples de entender e de manter.
Decisão 3
Página inicial decidida por evidência, não por hierarquia
Evidência
Cartões, pagamentos, consórcio, seguros e empréstimo queriam a primeira dobra. Levei os stakeholders para assistir aos testes de usabilidade comigo.
O que descartei
Dividir o espaço pelo peso de cada área na mesa.
Trade-off
Nenhuma área tem destaque garantido. Quem decide o que vem primeiro é a pessoa, pela personalização.
Decisão 4
Convivência de versões em vez de virada única
Evidência
Uma plataforma crítica, usada todos os dias por milhões de pessoas, não podia parar para trocar de navegação.
O que descartei
Lançar tudo de uma vez (big bang).
Trade-off
Manter duas versões por um período, com "Conheça a nova versão" e "Ir para versão anterior" sempre à vista.
05 · Do lado de dentro
A experiência do cliente começa na jornada de quem constrói
Se a jornada de desenvolvimento é fragmentada, a experiência do cliente inevitavelmente vira fragmentada também.
O canal novo seria construído por várias squads descentralizadas. Como Tech Lead de UX, desenhei também a experiência de quem desenvolve: a plataforma Webworks e a jornada de criação de aplicações no portal de desenvolvedores do banco.
Como era
Muitos times só acionavam UX na validação pré-produção, o que gerava retrabalho.
Cadastro de regras confuso e documentação pouco esclarecedora.
Era preciso abrir uma issue para criar a aplicação, publicar o menu e validar UX.
Como ficou
Autoatendimento: o time cria a aplicação sozinho, escolhendo o modelo certo.
Documentação única e atualizada, num só lugar.
UX entra mais cedo, com validação preventiva em vez de corretiva.
Menos dependência de issues e 7 passos a menos do início ao deploy.
Criação de aplicação: o time escolhe se está construindo uma Central, uma Funcionalidade ou um Widget, e o portal já entrega a estrutura certa do design system.
Governança sem gargalo
Com os líderes de UX de cada squad, criei uma camada de padrões sobre o BBDS: templates de UX, guidelines, tokens e variáveis no Figma, e a documentação de acessibilidade já resolvida, tudo publicado no portal de desenvolvedores.
Portal de desenvolvedores · Documentação de UX
06 · IA na verificação de UX
Um validador que revisa o protótipo antes de ele virar código
Mesmo com padrões claros, a revisão de UX era um funil: cada tela passava por uma pessoa do time de governança. Concebi um validador de UX com IA, que lê o protótipo direto do Figma e compara com o BBDS, os templates e as regras de UX writing.
EnvioA squad cola o link do protótipo no Figma.
LeituraO validador se conecta ao Figma e lê as telas.
AnáliseUm agente compara com BBDS, templates e UX writing.
DiagnósticoPontuação, problemas por severidade, impacto e recomendação.
EsteiraAcima de 80% de aderência, o protótipo entra na produção.
Demonstração com um protótipo de teste: pontuação 68/100, três problemas encontrados (um crítico) e uma recomendação para cada um.07 · Resultados e KRs
O que mudou, para quem usa e para quem constrói
Antes
70% das pessoas não encontravam as funções no menu legado.
→
Depois
Nos testes da nova navegação, as pessoas concluíam a tarefa sem travar.
Indicador principal: taxa de sucesso na tarefa. A nova navegação foi para produção como MVP, com o legado funcionando atrás, e cada linha de negócio passou a construir sobre ela.
2,07 mipessoas no canal redesenhado
+133%aplicações criadas pela nova jornada (27 → 63 por semestre)
7passos a menos do início ao deploy
4.063usuários únicos na plataforma dos times (nov/2025)
4,5/5satisfação dos times (CSAT, 96 avaliações)
5,4/7esforço para criar uma aplicação (CES, 327 respostas)
R$ 547 milde economia acumulada com a plataforma
80%de aderência mínima ao padrão para entrar na esteira
Painel de métricas que desenhei para a plataforma. Imagem desfocada por confidencialidade.
08 · Aprendizados
O que eu levo
Escala exige governança interna. Num produto que impacta 2 milhões de pessoas, cada squad que constrói sem padrão vira atrito para o cliente. A experiência começa dentro de casa.
Navegação é tarefa, não árvore de menu. As pessoas procuram o que vieram fazer, não onde a função mora.
Alinhamento se ganha mostrando o usuário. A disputa pela home acabou quando as áreas viram uma pessoa real procurando a própria função.
O que eu faria diferente: ligaria a leitura de métricas em produção desde o primeiro rollout.