← Todos os trabalhos
01/2021 · 07/2026Banco do Brasil · IBM Consulting

BB Digital PF:do desenvolvedorao cliente final

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
Menu do canal legado com dezenas de opções em colunas
Dezenas de opções no mesmo nível.
bb.com.br
Tela do legado com mensagem de erro genérica
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.

Persona Álvaro Lisboa, aposentado
Persona Bianca Ramirez, servidora pública
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
  1. Discovery e benchmarking
  2. Proposta de escopo
  3. Proposta de convivência entre versões
  4. Checklist de acessibilidade da home
  5. Arquitetura de informação: navegação, menu e busca
Testes com usuários
  1. Usabilidade da home
  2. Extrato e pagamentos
  3. Navegação entre versões e onboarding
  4. Card sorting da arquitetura
  5. Menu e arquitetura de informação
  6. 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.

Resultado de teste de usabilidade com mapa de calor na tarefa de pagar boleto
Comparativo das opções mais utilizadas no canal
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
Extrato no canal legado
Depois
Novo extrato com filtros, saldos e mais opções

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.
Tela de criação de aplicação APF-X com escolha entre Central, Funcionalidade e Widget
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
Documentação de UX do BB Digital PF no portal de desenvolvedores
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.

  1. EnvioA squad cola o link do protótipo no Figma.
  2. LeituraO validador se conecta ao Figma e lê as telas.
  3. AnáliseUm agente compara com BBDS, templates e UX writing.
  4. DiagnósticoPontuação, problemas por severidade, impacto e recomendação.
  5. 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 Webworks, desfocado
Painel de métricas que desenhei para a plataforma. Imagem desfocada por confidencialidade.
Painel de métricas com CSAT e CES, desfocado
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.