Banco BTG Pactual · App de Investimentos
Como traduzi a complexidade de produtos financeiros em experiências claras para qualquer perfil de investidor, e como esse trabalho se tornou a fundação do design system do BTG.
Contexto & Desafio
Em 2021, o app de investimentos do BTG atendia desde o primeiro investidor até o operador de renda variável. O desafio era servir bem os dois, sem transformar a experiência em uma planilha para iniciantes, nem numa interface limitada para avançados.
Sobre o time inicial: O time de design do app de investimentos começou com três pessoas: uma design lead e duas senior product designers. No BTG inteiro, éramos 12 divididos por produto. O time acompanhou o crescimento dos apps até passar de 100.
Clareza na tomada de decisão. Qual produto é este? Quanto vou ganhar ou perder? Como funciona? É seguro? Cada componente foi desenhado para responder essas perguntas na ordem certa.
Eficiência na jornada. Reduzir dúvidas no suporte, aumentar taxa de conclusão de aplicações e facilitar upsell de produtos relacionados com menos fricção.
A tese
Antes de abrir o Figma, precisávamos de um ponto de vista. Não um briefing de produto: uma convicção sobre o que tornaria esse app diferente dos concorrentes e sustentável para crescer.
Clareza patrimonial como centro de gravidade
A visão consolidada do patrimônio deveria ser o ponto de partida de toda sessão no app, não uma tela enterrada em três cliques. Todas as ações e informações deveriam orbitar em torno dessa âncora. A consequência direta: usuários não precisariam saber onde procurar. O app diria o que importa.
Um ponto de entrada, não uma Tab Bar
A decisão mais arriscada do projeto. Abandonamos o padrão de Tab Bar em favor de uma navegação centralizada e contextual. O risco era real: usuários esperavam o padrão. O ganho era maior: a arquitetura poderia crescer sem colapsar. Quatro anos depois, o app incorporou dezenas de novos produtos sem precisar refatorar a navegação.
Linguagem como interface
O jargão financeiro não é um problema do usuário: é um problema do produto. "Barreira de proteção", "cupom condicional", "D+2 úteis" não deveriam chegar crus na tela. A interface traduziria, contextualizaria e só exporia o vocabulário técnico para quem quisesse ir mais fundo.
Research & Discovery
Sem time de research dedicado na época, conduzi a pesquisa das minhas verticais.
Protótipos navegáveis testados com usuários de diferentes perfis para validar fluxos críticos.
Features: Home, Boleta, Portfolio, Performance
Testes com usuários reais para validar hipóteses antes do desenvolvimento e iterar com dados concretos.
Resultados em tempo real durante o ciclo de design
Reuniões com todo o time de design onde cada decisão era questionada, refinada e enriquecida com perspectivas diversas.
Toda opinião era válida: designers de outras squads contribuíam
Mapeamento de avaliações nas lojas de apps e tickets de suporte para identificar padrões de dor recorrentes.
73% dos feedbacks negativos citavam dificuldade em encontrar informações
73%
dos feedbacks negativos citavam dificuldade em encontrar informações básicas
2.5★
avaliação média antes do redesign com reclamações sobre UX fragmentada
Top 3
dores: saldo invisível, regras confusas, medo de errar na operação
Da estrutura à interface
Antes de qualquer pixel de cor, a home foi desenhada como estrutura de informação. O wireframe não era um rascunho: era o argumento visual de quatro decisões que definiriam toda a arquitetura do app.
Antes · 2021
Tab Bar visível: navegação fixa no rodapé limitava crescimento e forçava decisões de arquitetura a cada novo produto.
Wireframe · decisões
Interface final
Navegação contextual: botão flutuante substitui a Tab Bar. Quatro anos depois, o app cresceu sem refatorar a arquitetura.
Patrimônio como âncora visual
O número total no topo não é layout, é hierarquia de informação. Toda sessão começa com a resposta para "quanto eu tenho?" antes de qualquer ação.
Ações contextuais, não menu fixo
Investir, Transferir e Resgatar aparecem como ações da home, não como destinos de navegação. A intenção do usuário dita o fluxo, não a estrutura do app.
Portfólio a um scroll de distância
A segunda informação mais consultada fica imediatamente abaixo da âncora patrimonial, sem clique adicional. Reduz o número de taps para o dado mais relevante.
Sem Tab Bar: a decisão mais arriscada
Tab Bar suporta no máximo 5 destinos. Cada novo produto forçaria uma decisão: o que cortar? O botão flutuante não tem esse limite. COE, Previdência, Câmbio e Seguros entraram no app sem tocar na estrutura de navegação.
Trade-offs & Decisões
Design sênior não é só criar soluções: é saber priorizar e defender decisões difíceis. Aqui está um exemplo de como equilibrei necessidades do negócio com a experiência do usuário.
COEs são produtos financeiros complexos com regras de cupons e cenários de retorno que variam conforme o desempenho do mercado. A pressão do time de negócios era mostrar todas as informações técnicas para "educar o investidor".
Problema real: Usuários iniciantes abandonavam a jornada ao se deparar com termos como "barreira de proteção", "cupom condicional" e "participação no índice".
✕ O que o negócio queria
✓ Minha proposta
O simulador: insira um valor e veja os possíveis cenários de retorno e datas de recebimento
"Se o mercado subir muito"
+18,5%
Você receberia R$ 11.850
"Se ficar estável"
+5,2%
Você receberia R$ 10.520
"Se o mercado cair"
0%
Você receberia R$ 10.000 (capital protegado)
Resultado: Redução de dúvidas sobre COE no suporte e aumento na taxa de conclusão de aplicações. A solução foi replicada para outros produtos estruturados.
Design System & Escalabilidade
Não desenhamos telas. Desenhamos padrões. Cada componente carrega anatomia documentada, estados mapeados e regras de uso, para que qualquer designer pudesse contribuir sem criar inconsistência.
Cada componente construído como uma unidade independente, com variações sem quebrar a consistência.
Componentes projetados para mobile e desktop, mantendo a mesma lógica de interação entre plataformas.
Cada componente documentado com casos de uso, variações e guidelines para facilitar a adoção por outras squads.
Origem dos componentes
BTG Investimentos
Escalável para RV
BTG Trader
Escalável para desktop
Versão Web
100%
Consistência visual
Mesma experiência em todos os produtos
4+
Produtos integrados
App Investimentos, Banking, Trader e portais
15+
Squads utilizando
Componentes adotados por toda a organização
100+
Pessoas no time
Crescimento de 12 para mais de 100 designers
A boleta de investimento é um dos componentes mais complexos do ecossistema financeiro. Em vez de criar uma boleta diferente para cada produto, desenvolvemos uma estrutura base que se adapta às regras específicas de cada mercado.
CDB
Estrutura base com saldo, valor e CTA fixo
COE
Linguagem adaptada: "reservar" em vez de "investir"
Tesouro Direto
Alerta de horário de liquidação integrado ao fluxo
Colaboração & Comunicação
De 2008 a 2017 trabalhei como desenvolvedora front-end. Isso não significa que codifico interfaces: significa que entendo as restrições antes de propor soluções, e que meu handoff não precisa de interpretação.
Termos como componentização, estado, propriedades de componentes e débito técnico fazem parte do meu vocabulário natural. Isso elimina ruído nas conversas de alinhamento e acelera decisões conjuntas.
Antes de apresentar uma solução, valido mentalmente se é tecnicamente factível dentro das restrições do ciclo. Menos retrabalho, menos frustração, mais fidelidade à intenção original.
Quando há restrição de tempo ou técnica, sei quais elementos visuais podem ser simplificados sem comprometer a experiência, e quais não podem ceder.
"E se produto quiser a ideia dele de qualquer jeito?"
Minha resposta padrão é trazer dados para o centro da conversa. Em vez de "acho que não funciona", proponho testar as duas abordagens. Quando você coloca o usuário como árbitro, a discussão sai de opiniões e entra em evidências. Sei escolher minhas batalhas: defendo com dados o que impacta o usuário e o negócio, mas sempre proponho uma alternativa antes de ceder.
"E se engenharia disser que não dá para fazer?"
Quando ouço "não dá", pergunto o que exatamente não dá: é tempo? Complexidade? Limitação de API? Em vez de insistir na solução original, busco entender a restrição e proponho uma versão que entregue o mesmo valor com menos custo técnico. Na maioria das vezes, a solução final era melhor que a ideia inicial.
"Como você lida com prazos apertados?"
Priorizo o essencial para o usuário e para o negócio, e proponho faseamento: primeira entrega funcional, depois melhorias baseadas em métricas e feedback real dos usuários. Comunicação transparente com o time desde o início para replanejar junto, sem surpresas.
Processo
O app começou com três pessoas: uma design lead e duas senior PDs. À medida que o design system se consolidou, o time cresceu de 12 para mais de 100 designers. Cada decisão precisava ser documentada de forma que qualquer pessoa pudesse continuar sem me perguntar nada.
Entender antes de propor
Benchmarking de concorrentes e entrevistas com investidores de diferentes perfis. O insight mais importante: usuários não queriam mais informação, queriam confiar na decisão que estavam tomando.
Priorizar é uma decisão política
Com regras de negócio complexas e múltiplos stakeholders, alinhar o que entrava no MVP exigiu mediação constante entre engenharia, produto e compliance. Definir escopo é tanto uma habilidade de design quanto de negociação.
Componentes como linguagem compartilhada
Em vez de desenhar telas, desenhamos padrões. Cada componente tinha anatomia documentada, estados mapeados e regras de uso explícitas para que novos designers contribuíssem com consistência desde o primeiro sprint.
Design não termina no handoff
Minha formação em front-end mudava a qualidade da saída do design. Sabia o que os devs precisavam para implementar sem ambiguidade: estados documentados, especificações claras, edge cases mapeados. Menos idas e vindas, mais fidelidade à intenção original.
Cada componente da boleta tem regras de exibição, estados e comportamentos documentados para que os desenvolvedores implementem sem ambiguidade.
Por que isso importa?
Esse nível de especificação, com estados, validações e edge cases mapeados, é o que diferencia um handoff que gera retrabalho de um que o desenvolvedor implementa direto. Meu background em front-end (2008-2017) me permite documentar na linguagem que desenvolvedores esperam: comportamento por estado, não descrição visual.
✎ Header
Comportamento: Botão fechar (X) encerra o fluxo e retorna à tela do produto.
✎ Bloco de informações
· Aplicação mínima: valor definido pelo produto, não editável
· Saldo disponível: atualizado em tempo real ao abrir a boleta
· Saldo + InvestFlex: só aparece se o usuário tem InvestFlex ativo
· Estoque disponível: só aparece para produtos com estoque limitado
· Preço unitário: só aparece para produtos com preço unitário (ex: CDB, LCI)
✎ Campo de valor (R$ 0,00)
Estado padrão: zerado, com cursor ativo. Teclado numérico abre automaticamente.
Validação: não permite valor abaixo da aplicação mínima nem acima do saldo disponível (ou saldo + InvestFlex).
Erro: mensagem inline abaixo do campo em vermelho.
✎ Pills de atalho
· "Saldo disponível": preenche com o valor total do saldo
· "+R$50,00", "+R$100,00": soma ao valor já digitado, não substitui
· Estado ativo: pill preenchida quando o valor no campo corresponde
✎ InvestFlex (switcher)
Estado padrão: desativado.
Ao ativar: atualiza o "saldo disponível" somando o saldo do InvestFlex.
"Saiba mais": abre bottom sheet com explicação, não sai da boleta.
Exibição: só aparece para usuários com InvestFlex disponível.
✎ CTA "Transferir da sua conta corrente"
Exibição: sempre visível no rodapé da boleta.
Ao clicar: abre bottom sheet com overlay, sem sair da boleta.
Botão circular com seta: avança para a tela de resumo (pré-confirmação).
Estado desabilitado: quando o valor é zero ou inválido.
Resultados Mensuráveis
NPS 81 coloca o BTG na zona de excelência mundial, mesma categoria de Apple e Netflix. O crescimento de 2.5 para 4.7 no Google Play não aconteceu com campanha: aconteceu com clareza de interface.
81 pts
NPS, zona de excelência
BTG atingiu 81 pontos no Net Promoter Score. Acima de 75 é considerado zona de excelência.
Fonte: Consumidor Moderno
4.8 ★
Avaliação App Store
Nota consolidada com mais de 112.000 avaliações, entre os mais bem avaliados do setor financeiro.
Fonte: App Store
4.7 ★
Google Play
Crescimento de 2.2 para 4.7 estrelas, associado ao redesign da experiência.
Fonte: Google Play
+740%
Crescimento do time
Time de design cresceu de 12 para 101 profissionais durante o período utilizando o mesmo sistema.
Design Ops
Aprendizados & Evolução
Hierarquia é mais poderosa que simplificação
Remover informação é o caminho fácil. Organizar para que a informação certa apareça no momento certo é o trabalho real. Essa distinção mudou como abordo qualquer projeto desde então.
Design system é produto, não entregável
Sistemas que funcionam não são documentos entregues. São estruturas vivas projetadas para crescer sem perder coerência. Projetar para escalabilidade desde o componente zero foi a decisão mais importante desse projeto.
Saber código muda a qualidade da entrega
Num banco do tamanho do BTG, o processo de desenvolvimento tem camadas e aprovações. Meu diferencial não era pular etapas, era entregar um handoff sem brechas: especificações que os devs não precisavam interpretar, só implementar.
Métricas como bússola, não como destino
Cada decisão de design foi ancorada em dados: feedbacks da loja, testes de usabilidade, métricas de suporte. Os resultados (NPS 81, 4.8 na App Store) não foram surpresa, foram consequência de um processo orientado por evidências do início ao fim.