Por que construí meu próprio Design System

Nos últimos anos, trabalhei em times de Design System em mais de uma empresa — criando componentes, definindo tokens, documentando padrões e ajudando outros times a usar tudo isso no dia a dia. Cada projeto ensinou algo diferente sobre o que funciona (e o que não funciona) quando várias pessoas dependem da mesma base de componentes.

Trabalhar em um Design System corporativo tem um limite natural: as decisões de arquitetura, a stack e até o escopo do que pode ser experimentado são definidos pelo contexto da empresa, não por mim. Isso é ótimo para entregar valor rápido, mas deixa pouco espaço para testar ideias fora do que já está validado.

Foi aí que comecei o tf.ds — um Design System pessoal, sem prazo, sem stakeholder para agradar além de mim mesmo. Um lugar para experimentar tokens, testar abordagens de composição de componentes e decidir, com calma, o que realmente vale a pena documentar.

Documentar decisões é tão importante quanto escrever o componente. Um botão com quatro variantes é fácil de construir; explicar por que essas quatro variantes existem — e não cinco — é o que realmente ajuda quem vai usar o sistema depois.

Também aprendi a valorizar mais a consistência entre plataformas. Ter tokens que funcionam tanto em React quanto em React Native me obrigou a pensar em abstrações mais simples e menos amarradas a uma única tecnologia.

O tf.ds ainda está em construção — esse próprio portfolio é meu principal campo de testes para ele. A ideia é continuar publicando aqui o que for aprendendo pelo caminho, com menos teoria e mais decisões reais de projeto.