SaaS B2B com legado e presença internacional, produto construído originalmente por engenheiros.
Componentes não escaláveis, sem documentação, conflito de fontes e cores inconsistentes — 90% precisava ser refeito.
Redução de 33% no tempo de sprint e aproximadamente 50% no tempo de validação técnica.
Quando cheguei à AEVO, o Design System existia no nome, mas não na prática. O produto havia sido construído por engenheiros, e os designers chegaram depois — trazendo suas próprias convenções sem um sistema unificado para sustentá-las. O resultado era um acúmulo de inconsistências que crescia a cada sprint.
Neste case, descrevo como conduzi a reestruturação do DS: desde o levantamento do que existia até a criação de tokens, documentação de componentes e um modelo de contribuição que o time de engenharia abraçou por conta própria.
A AEVO é um SaaS B2B de alta complexidade com presença internacional e uma base de clientes consolidada. O produto foi construído originalmente por engenheiros, e os designers chegaram depois. Sem um sistema de design estruturado desde o início, cada equipe foi adicionando seus próprios padrões e a distância entre o que estava no Figma e o que estava no código cresceu ao longo do tempo.
Quando assumi o Design System, essa distância já era um problema real: retrabalho constante, handoff com ruído e entregas inconsistentes entre os módulos do produto.
O que havia era um conjunto de componentes soltos, sem documentação, sem consistência e sem escalabilidade.
Cada variação de botão era um componente separado: botão primário, botão secundário, botão terciário. Três arquivos, nenhuma conexão. Não existiam variáveis. Além disso, metade dos componentes usava Inter (fonte dos designers) e a outra metade usava Roboto (deixada pelos desenvolvedores). Havia dezenas de tons de laranja ligeiramente diferentes espalhados pelo produto. Medidas e margens inconsistentes. E o Storybook da engenharia não refletia o Figma do time de design, gerando conflito constante na entrega.
Após o levantamento inicial: cerca de 90% dos componentes precisavam ser refeitos.
1. Mapeamento completo
Comecei fazendo uma planilha com cada componente existente, classificando o que podia ser reaproveitado e o que precisava ser refeito. Esse levantamento serviu para priorizar o trabalho e alinhar expectativas com o time antes de qualquer alteração.
2. Cores
Entrei em contato com o marketing para garantir que a escala de cores da marca fosse a referência correta. Construí a escala completa, cores da marca, neutros e cores de apoio já em uso. Nada foi removido sem critério, porque o produto já tinha muitos clientes ativos.
3. Tipografia
Preparei a documentação para mudança futura. A engenharia tinha resistência porque as fontes estavam amarradas a tokens no código. A decisão foi deixar preparado e não forçar uma ruptura desnecessária.
4. Componentes
Comecei pelos botões pois são os mais usados e os mais inconsistentes. A partir daí, cada componente que entrava na esteira de redesign já saía com os novos tokens e documentação estruturada.
Workshop de tokens com design e engenharia
Antes de trabalhar nos tokens, organizei um workshop formal com os dois times. O objetivo era simples: explicar o que eram tokens e como funcionariam na prática. Não fazia sentido construir uma estrutura que só o design entendesse.
A nomenclatura foi alinhada com a engenharia: camelCase e t-shirt sizes, porque era o que o time de desenvolvimento já usava. Adaptei em vez de impor.
Critério de entrada no DS: Atomic Design
Para decidir o que entrava no sistema, usei Atomic Design como critério: átomos e moléculas como regra, organismos como exceção quando estruturas eram estáveis o suficiente para justificar. A curadoria era feita junto com o dev responsável pelo design, não era decisão unilateral.
Cada componente passava por uma sessão de revisão antes de entrar, com validação de acessibilidade incluída.
Documentação estruturada por componente
Cada componente ganhou documentação própria: apresentação, quando usar, variações, tamanhos, exemplos de aplicação e diretrizes de writing quando aplicável. Diferente do que havia antes: mostrava o componente dentro de uma tela, mas não documentava o componente em si.
Canal de versionamento no Teams
Para comunicar mudanças, criamos um canal dedicado com formato padronizado: versão do componente, o que mudou, onde encontrar no Figma, onde encontrar no código e o que mudou em nível de design e de código.
O sinal mais claro de que estava funcionando veio dos próprios desenvolvedores. Eles passaram a consultar o time de design por conta própria, perguntando se determinado componente já estava no DS para trocar em outros lugares também. Ninguém pediu isso a eles. Eles entenderam que usar o DS era mais fácil do que fazer na mão.
O principal aprendizado foi que a adoção de um Design System não depende só de qualidade técnica. Depende de fazer o time entender por que aquilo facilita o trabalho deles, não só o do design.
O workshop de tokens, o alinhamento de nomenclatura com a engenharia e o canal de versionamento não eram etapas “bonitas” do processo. Eram as etapas que fizeram o sistema funcionar de fato.
Outro ponto: começar pelas cores e pela tipografia, antes de tocar nos componentes, foi a decisão certa. Sem essa base, qualquer componente construído em cima continuaria inconsistente.
Vamos conversar sobre seu projeto ou oportunidade.
Estou disponível para novos desafios e colaborações.
Baixar Curriculo
