Todo desenvolvedor frontend já passou por isso: você recebe um protótipo novo no Figma, abre a biblioteca de componentes do projeto e percebe que... nada encaixa. As cores são levemente diferentes, os espaçamentos não batem e aquele botão que deveria ser "padrão" precisa de 15 linhas de CSS extra para ficar igual ao design.
No último ano, vivi exatamente esse cenário. O que começou como uma biblioteca React robusta, com o tempo, tornou-se um gargalo de produtividade e um museu de decisões técnicas obsoletas.
Neste primeiro post, quero compartilhar como identificamos que nosso Design System (DS) estava falhando e por que decidimos reconstruí-lo como um ecossistema multiplataforma.
O diagnóstico: A "Deriva" entre Design e Código
O primeiro sinal de alerta foi a inconsistência. O time de Design evoluía rápido, testando novas abordagens e padrões de UX. Enquanto isso, nossa biblioteca em React estava estagnada.
Essa desconexão cria um fenômeno perigoso: o Shadow CSS. Desenvolvedores, para entregarem suas tarefas no prazo, param de usar os componentes do sistema e começam a criar "versões locais" ou a sobrescrever estilos globalmente.
Resultado? Um bundle cada vez maior, manutenção impossível e uma interface que parece uma colcha de retalhos.
Quando a tecnologia se torna o problema
No nosso caso, tínhamos um complicador técnico: a biblioteca era inteiramente baseada em styled-components em versões que já estavam se tornando depreciadas.
Embora o CSS-in-JS tenha tido seu auge, percebemos que a forma como ele estava implementado no projeto inteiro gerava:
- Dificuldade de manutenção: Alterar um comportamento básico exigia navegar por árvores complexas de componentes estilizados.
- Barreira de entrada: Novas stacks (como Mobile) não podiam aproveitar nada do que já tínhamos feito para Web.
Percebemos que não bastava atualizar as versões das libs. Precisávamos de um Design System System (sim, um sistema para gerir o sistema).
A Virada de Chave: Do React para o Multiplataforma
A grande decisão foi: parar de construir apenas para Web e começar a construir para a marca.
Nossa empresa não vive só de React. Temos Android nativo, iOS, Flutter e Web. Se continuássemos focados apenas em uma biblioteca React, o problema da inconsistência se repetiria em todas as outras frentes.
A estratégia do Monorepo
Decidimos migrar para uma estrutura de Monorepo. A ideia era centralizar a inteligência do Design System em um único lugar, mas distribuir para todas as plataformas:
- Design Tokens: A fonte única de verdade (Single Source of Truth).
- Core Logic: Regras de negócio de componentes que poderiam ser compartilhadas.
- Implementações específicas: Pacotes dedicados para React, Flutter e Mobile Nativo.
Isso mudou o jogo. O Design System deixou de ser "aquele repositório de botões em React" para se tornar a linguagem universal da engenharia na empresa.
Por que você deveria se importar com isso?
Se você é um Senior Software Developer, sabe que nosso trabalho não é apenas escrever código, mas garantir a manutenibilidade e a escalabilidade da solução. Manter a conexão viva entre design e código traz benefícios claros:
- Reduz o Time-to-Market: Menos discussões sobre pixels, mais foco em funcionalidades.
- Elimina o Débito Técnico: Atualizações de marca são propagadas automaticamente através de tokens.
- Unifica a experiência: O usuário sente que está usando o mesmo produto, seja no site ou no app.
E você?
Já sentiu que seu Design System está mais atrapalhando do que ajudando?
Top comments (0)