Inconsistência visual raramente acontece porque alguém decidiu fazer um botão “errado”. Ela aparece quando cada tela precisa redescobrir espaçamento, cor, estado e interação. Sem uma base comum, até pessoas cuidadosas chegam a respostas diferentes.
É por isso que trato Design System como infraestrutura de produto, não como uma vitrine de componentes. A parte bonita importa, claro. Mas o valor está em transformar decisões recorrentes em opções reutilizáveis e seguras.
Antes do Button, vêm as decisões
Começo olhando para interfaces reais. Quais padrões se repetem? Onde a variação é intencional? Tokens entram depois desse inventário. Um nome semântico como color-danger-background diz mais que red-500 e sobrevive melhor a um novo tema.
Primitivos, tokens semânticos e componentes formam camadas. Essa cadeia precisa ser rastreável; abstração visual que ninguém consegue depurar não ajuda muito.
Componente é comportamento
Um modal não é só borda e sombra. Ele precisa cuidar de foco, teclado, fechamento, loading e conteúdo longo. APIs com variantes válidas deixam esse contrato claro.
- Token: registra uma decisão visual reutilizável.
- Primitivo: resolve acessibilidade e mecânica básica.
- Componente: oferece variantes intencionais ao produto.
- Padrão: combina peças para uma tarefa recorrente.
Acessibilidade escala junto
Quando cada equipe recria select, tooltip ou modal, também recria os mesmos riscos de foco e ARIA. Uma base testada distribui uma solução melhor. Ainda assim, ela não protege de rótulo ruim ou ordem confusa; o uso continua exigindo julgamento.
Contraste, zoom, teclado e leitores de tela fazem parte do componente desde o início. Não são uma auditoria decorativa no fim da sprint.
Entre Figma e código
Na OdiNetwork, trabalhando com Figma-to-code, React, Next.js e Tailwind, ficou evidente que fidelidade depende de vocabulário compartilhado. Variante no Figma e variante no código deveriam representar a mesma decisão.
Tailwind acelera bastante, mas uma coleção de classes copiadas não vira sistema por proximidade. Uso utilitários para construir o contrato, não para recriá-lo em cada página.
O Design System está funcionando quando seguir o padrão exige menos esforço do que improvisar.
Governança sem fila de espera
Nem toda solução local precisa entrar na biblioteca. Procuro repetição, necessidade compartilhada, acessibilidade e uma API que consiga amadurecer. Componentes experimentais podem conviver com os estáveis sem fingir o mesmo nível de confiança.
Adoção, defeitos de UI e tempo de entrega dizem mais que a quantidade de componentes publicados. E deprecar faz parte: um sistema que nunca remove nada acaba preservando todos os erros.
Conclusão
Design Systems reduzem inconsistência ao guardar conhecimento, não ao proibir diferenças. Tokens, componentes acessíveis e critérios de contribuição diminuem decisões repetidas. Assim, design e engenharia ganham tempo para discutir o que realmente é novo naquele produto.