O primeiro design system sério que montei tinha uma component layer completa, tokens escopados por componente, e foi construído em cima de um produto que ainda estava em produção. Parecia maturidade. Era retrabalho.
O sistema que era retrabalho
Cada mudança no produto, e produto vivo muda toda semana, quebrava alguma coisa três camadas abaixo. Eu passava mais tempo mantendo o sistema coerente do que desenhando.
O problema nunca foi técnico. Eu sabia montar as camadas. O problema era de julgamento: eu não tinha perguntado se aquele produto, naquele momento, precisava de tudo aquilo. Precisava não.
As cinco camadas, e o que cada uma guarda
A arquitetura que eu uso tem cinco níveis. Ela existe inteira. Ter ela inteira num projeto nunca foi o objetivo.
| Camada | O que guarda |
|---|---|
| Core | Os valores brutos. |
| Palette | As rampas de cor montadas sobre o Core. |
| Brand | O que cada cliente puxa de Palette e Core. |
| Semantic | O propósito de cada token. |
| Component | Tokens escopados por peça. Normalmente é uma camada a mais. |
A versão de quatro camadas disso é o que foi entregue no design system da Vellumwire. Ele para no Semantic.
O que o sistema precisa fazer é impedir erro de consistência sem gerar manutenção que ninguém pediu. Toda camada além disso é custo.
A component layer é o primeiro lugar onde dá pra exagerar
Ela faz sentido em produto grande, com muitos times mexendo nos mesmos componentes, onde você precisa blindar cada peça individualmente.
Num produto pequeno, ou num que ainda está mudando de forma toda semana, ela vira peso morto. Você cria um contrato rígido pra uma coisa que ainda não decidiu o que quer ser. Pra empresa pequena, o teto certo é o Semantic, e parar ali é dimensionar o sistema pro produto que ele serve de verdade.
Fine: a válvula de escape na escala de espaçamento
Onde a linha fica exatamente é a parte que ninguém documenta. Duas decisões minhas resumem bem. A primeira é o que eu chamo de Fine.
O Core de espaçamento é construído em múltiplos de 4 e 8, valores consolidados que evitam que cada tela invente seu próprio ritmo. Mas restrição cega gera componente feio. Às vezes você precisa de 6, de 10, de 2, e negar isso só porque não é múltiplo de 8 produz um resultado pior.
Então o Semantic tem uma faixa Fine pra esses casos. O sistema continua restritivo o suficiente pra impedir bagunça, e maleável o suficiente pra não te obrigar a entregar algo torto em nome da regra.
A segunda decisão: quando não criar token
Token cobre uns 90% das decisões. Os outros 10% não valem a estrutura.
Um avatar sem foto, por exemplo, pode ter 25 cores diferentes dependendo das iniciais da pessoa. Tokenizar isso é criar 25 tokens que ninguém vai reusar, pra resolver um caso que uma função resolve melhor. Cobrir tudo só deixa o sistema mais pesado sem deixar mais forte. O que precisa de token é o que se repete.
Os poucos obrigatórios, e documentar o resto
O mesmo cuidado vale na hora de escalar. No começo eu criava token demais, e sistema inchado é tão ruim quanto sistema frouxo, porque ninguém consegue lembrar o que existe.
Os obrigatórios são poucos e puxam direto do Core: font size, icon size, line height, padding. Documentar bem o Semantic é o que impede o resto de virar bagunça, porque é a documentação que evita token usado onde não devia. Padding e margin são o exemplo clássico de onde isso desanda quando a regra não está clara.
Nada disso importa se os valores nunca chegam na tela como token. Essa falha tem artigo próprio: tokens de design vs. valores hardcoded.
Onde a linha fica de verdade
Comecei a montar essa lógica em freelances, testando em projetos pequenos onde o erro era barato. Foi na Instivo que tive um produto com escala de verdade pra estressar tudo isso e ver o que aguentava. O resto veio com tempo e bastante tapa na cara.
A maturidade de um design system não se mede pela quantidade de camadas. Se mede por saber qual a menor arquitetura que resolve o problema daquele produto, naquele momento.
Mais camada é fácil. Parar na hora certa é o que separa sistema de enfeite.