De biblioteca desacreditada a infraestrutura estratégica de produto.

Quando entrei no projeto, ele estava quase morto. Existia um Design System, mas fechado, com pouca chance de escalar e quase nenhuma ligação com o negócio. Na prática, era uma biblioteca, não um produto.

Ele era 100% pensado para o app logado: atendia o que já existia, não o que poderia existir, e por isso não tinha espaço para outros produtos ou plataformas. Cerca de quatro equipes usavam os componentes antigos, e o sinal mais claro do problema era o volume de detachments, em torno de 900 por mês. Detachment é quando o designer quebra o componente no Figma, desvinculando-o da biblioteca, para editar por conta própria. Cada quebra é um voto de desconfiança no sistema.

O projeto também enfrentou ceticismo interno. O que o sustentou foi a confiança do time de design e do time de acessibilidade no potencial dele.

Fui para dar continuidade, mas o potencial era grande demais para continuar como estava. Escolhi refazer e mudar a forma de encarar o projeto. Três decisões pesaram mais:

1. Trocar praticamente todo o time de desenvolvimento. Sem o time certo, nenhuma estratégia sairia do papel.
2. Reconstruir todos os componentes como uma única fonte da verdade. O Figma é essa fonte: ele não olha para app ou web separadamente, os dois convivem no mesmo lugar, do mesmo jeito.
3. Tratar o Design System como produto, com dono, roadmap, estratégia e governança, em vez de projeto com data para acabar.

No diagnóstico, cruzamos pesquisas, benchmarks e entrevistas com os designers que usavam a biblioteca.

1. Figma, a fonte da verdade
2. Web e app, ao mesmo tempo

Foram cerca de nove meses de design, quase 100% focados na reconstrução. Partimos do visual que já existia e aproveitamos para ajustar a estética e trazer boas práticas de mercado. O lançamento oficial foi em janeiro de 2026, com os 25 componentes mais importantes, catalogados a partir do legado e das telas da época.

Hoje são cerca de 65 componentes e cerca de 600 tokens, primitivos e semânticos, organizados com Variables e Style Tokens no Figma. Usamos atomic design, dos átomos aos organismos.

Uma das mudanças que mais sentimos foi o espaço em branco: antes usávamos muitos dividers para separar seções, e hoje deixamos o espaço respirar, o que ajuda visualmente. Quase tudo é flexível. Só deixei rígidos os componentes que se fixam no scroll, porque eles precisam de tamanhos e espaços mais reduzidos para sobrar área de conteúdo em telas pequenas.

1. Átomos
2. Moléculas
3. Organismos

O Pitaya é entregue em React no web e Flutter no app, com Storybook, Code Connect e Code Syntax. Na prática, o dev copia o link do frame em que o protótipo foi feito, joga numa IDE com IA e recebe a tela quase pronta em código. Também temos alguns MCPs que conectam design e código, e o próprio sistema serve de base de conhecimento para um chatbot. Estamos nos moldando conforme a necessidade dos times, sejam de produto, design ou tecnologia.

1. Tokens
2. Componentes
3. Documentação
4. Engenharia

Acessibilidade entrou na base, não no fim. Trabalhamos com WCAG 2.2 AA, normas ABNT e testes com tecnologia assistiva. O time contou com o Alvaro Zermiani, um colega cego que testava com tecnologia assistiva do desenho dos componentes e templates até o código, e ajudava os times de design a escolher a ordem de leitura das páginas.

Antes, os testes aconteciam só no código, o que era trabalhoso. Colocamos acessibilidade no UI kit, com um playground que facilitou muito esses testes. Esse trabalho nos levou ao TDC, The Developers Conference, em setembro de 2025, onde eu e o Alvaro apresentamos como o Design System e a tecnologia assistiva devem andar juntas: se a base está bem resolvida e as pessoas a usam, a qualidade do projeto sobe.

Hoje eu audito tudo. O modelo de contribuição é específico, porque o sistema já cobre quase tudo o que as pessoas precisam, então a maioria das contribuições é evolução, não criação. A documentação vive em um portal próprio, com releases, guias, novidades e informações sobre o time e o produto.

• ~900 → ~25detachments por mês, mesmo com a base passando de cerca de quatro para cerca de vinte equipes.
• ~40%menos tempo na esteira de desenvolvimento front-end.
• ~30%mais itens adicionados às sprints. As duas medidas são estimativas acompanhadas por especialistas em agilidade da empresa.
• ~18 de ~20produtos da unidade usando o sistema, com cerca de 70 designers, 500 desenvolvedores, 800 pessoas no ecossistema ampliado e cerca de seis marcas e plataformas atendidas.

Mais confiança do time nas entregas, na esteira de produto e na qualidade das telas, mesmo com o time crescendo. O atual VP de ECS agradeceu diretamente: ele via o potencial do produto, mas não sabia como conduzi-lo, e reconheceu a condução do time.

Eu teria jogado fora os tokens base do projeto. Já havia muita gente usando esses tokens, sem componentes ligados a eles, e eu não tinha tempo nem gente para mexer nisso. Até hoje me dá dor de cabeça: a semântica é ruim, os valores de cor são ruins e a paleta é fraca, o que dificulta mexer em qualquer coisa. É a dívida que mais quero pagar.