Voltar
300 telas e um Design System
para unificar o app da Trigg entre Android e iOS
Redesign de um app de cartão de crédito que cresceu na mão de vários times. O ciclo foi interrompido antes de qualquer métrica de negócio, mas a base unificada permaneceu.
Configuração do projeto
Papel: Product Designer
Time: 9 pessoas: 3 devs back-end, 2 front-end, UX researcher, PM, PO e design
Ferramentas: Figma, Photoshop e Protopie
Categoria: Design System, Governança, Documentação
Conteúdo confidencial. Telas e dados foram omitidos ou adaptados por acordo com a empresa. Fluxos completos disponíveis sob solicitação em contexto profissional.
Se você ler só uma parte
O app da Trigg tinha evoluído nas mãos de vários times, com telas inconsistentes e comportamento diferente entre Android e iOS.
As entrevistas com usuários mostraram que o problema ia além do visual, e o escopo passou de atualização para unificação de produto, design e desenvolvimento sob uma mesma base.
Foram 300 telas redesenhadas e um Design System consolidado, com o app em operação. O ciclo foi interrompido antes de qualquer métrica de negócio, e a base unificada permaneceu.
O problema
Telas inconsistentes entre si.
Comportamento diferente entre Android e iOS.
Decisões sem visibilidade cruzada entre as áreas.
Código fragmentado.
Para quem usava, o app mudava conforme o sistema, num produto em que saldo, cobrança e condições do cartão precisam inspirar confiança. Para o time, cada funcionalidade nascia sobre inconsistência acumulada, e a entrega ficava mais lenta.
O que precisava acontecer
01. Uma base única entre Android e iOS
Produto, design e desenvolvimento sobre o mesmo código.
02. Um Design System consolidado e documentado
Com foco nos componentes críticos.
03. Menos atrito nos fluxos prioritários
Contestar compra, acionar serviços e entender os seguros.
O que foi feito
As entrevistas mudaram o escopo: de atualização visual para unificação
As entrevistas com usuários, conduzidas junto ao time de produto, apontaram atrito em processos com passos desnecessários, como contestar uma compra e acionar serviços, e em informações que deveriam estar evidentes, como condições e coberturas dos seguros. A leitura defendida pelo design foi que, com cada área decidindo isoladamente, o problema voltaria a se acumular.
A base única foi decisão do time técnico, e o design estruturou o sistema sobre ela
A migração para React Native partiu do time técnico. Ao design coube estruturar o Design System e os fluxos sobre essa base. Em troca, as decisões de interface passaram a depender do Design System central, o que é mais lento no curto prazo e evita o acúmulo de inconsistência no longo. Tudo isso aconteceu com o app em operação, sem quebrar o que já existia.
As entregas se dividiram em três frentes
Governança de design: Design System atualizado e consolidado, componentes críticos documentados e novos componentes onde havia lacuna.
Fluxos: menos passos na contestação de compra e no acionamento de serviços, com condições e coberturas de seguros mais visíveis.
Handoff: ponte entre a experiência e a viabilidade técnica, com acompanhamento do front-end na componentização e nos testes automatizados.
Também entraram o destaque para os cartões físicos da parceria com a Warner, mais visibilidade de feedback e saúde de crédito e a reformulação do programa de indicação e de cashback.
300 telas redesenhadas
Padronização de ponta a ponta, com fluxos revisados e integrados.
o que ficou
Com a incorporação da carteira por outra empresa do grupo, as prioridades mudaram antes do fim do ciclo, e o projeto não gerou métrica de negócio.
Os fluxos mais usados já tinham sido revisados quando o projeto parou.
Em retrospecto
Não houve tempo para validar em produção o ganho de consistência. Uma governança formalizada desde o início daria mais fôlego ao sistema diante de mudanças de prioridade.
