Quando duas telas têm cinzas quase iguais e estados de loading completamente diferentes, é comum chamar isso de “ajuste de design”. Só que muitas dessas diferenças nascem no código: valores mágicos, componentes duplicados, CSS global e ausência de teste para estados menos fotogênicos.
O Figma expressa a intenção. A engenharia precisa fazê-la sobreviver a dados reais, telas pequenas, zoom, teclado e traduções maiores que o mock.
A variação começa pequena
Um padding de 18px resolve uma tela. Outro de 20px resolve a próxima. Meses depois, ninguém sabe qual escala existe. Tokens e primitivas de layout restringem escolhas comuns sem impedir exceções justificadas.
Também evito estilos que dependem silenciosamente da posição na árvore DOM. Variante explícita é mais fácil de entender que um seletor global alterando o componente à distância.
Estado também é interface
Loading, vazio e erro não são acidentes entre duas telas prontas. Eles fazem parte do produto e precisam de uma linguagem coerente.
- Loading: informa progresso sem desmontar o contexto.
- Vazio: explica a ausência e sugere uma ação útil.
- Erro: mostra impacto e possibilidade de recuperação.
- Foco: permanece visível para quem navega por teclado.
Responsividade não é encolher
No mobile, conteúdo muda de prioridade, ações se reorganizam e algumas composições deixam de funcionar. Containers, grids e breakpoints compartilhados dão uma gramática para essas decisões.
Uso dados extremos durante o desenvolvimento: título longo, lista vazia, número inesperado. Mock perfeito demais esconde boa parte dos bugs visuais.
Transformando intenção em regra
Na OdiNetwork, o trabalho com design systems e Figma-to-code reforçou uma coisa: copiar medidas entrega uma captura fiel, não necessariamente um produto consistente. Variantes alinhadas entre Figma, React e Tailwind reduzem interpretação.
Tailwind funciona muito bem quando a configuração e os componentes expressam limites. Sem isso, ele apenas torna mais rápido escrever combinações diferentes.
“Pixel perfect” vale pouco se a interface só fica correta no estado usado para tirar a captura.
Automação encontra o repetível
Lint pode bloquear cores fora da escala; testes de componente cobrem variantes e acessibilidade; comparação visual detecta regressões em cenários estáveis. E2E fica para jornadas em que layout e interação precisam conversar.
Revisão humana continua essencial. Automação protege regras conhecidas; pessoas avaliam hierarquia, clareza e situações que o sistema ainda não aprendeu.
Conclusão
Consistência visual é uma propriedade construída. Tokens, estados modelados, regras responsivas e testes fazem a intenção resistir ao crescimento do produto. Isso não tira espaço do design — libera o olhar humano para problemas que realmente pedem uma decisão nova.