Design Tokens: a ponte que fecha o ciclo entre o Figma e o código
Nos últimos conteúdos, percorremos o caminho completo de um projeto de UX/UI: onde pesquisar antes de desenhar, como estruturar um briefing que realmente gera resultado, e como montar um layout responsivo que se adapta sem perder experiência. Falta fechar esse ciclo no ponto onde a maioria dos projetos perde consistência: a passagem do design pro código. É exatamente aí que entram os design tokens, e depois de estruturar Design System em mais de um projeto, posso dizer que essa é a peça que decide se um rebrand leva uma tarde ou uma sprint inteira. Um design token não é uma cor. É uma decisão sobre uma cor, guardada em um único lugar e reaproveitada em todo canto. Em vez de escrever o mesmo valor hexadecimal em cinquenta componentes diferentes, você escreve esse valor uma única vez, dá um nome a ele, e referencia esse nome sempre que precisar da mesma decisão visual. A vantagem não é só organização: é que alterar um token em um só lugar propaga a mudança para toda a interface, sem precisar caçar cada ocorrência manualmente. A estrutura que funciona na prática segue dois níveis. No primeiro nível ficam os tokens primitivos: os valores brutos, sem nenhum contexto de uso, como toda a rampa de cor da marca ou cada passo da escala de espaçamento. No segundo nível ficam os tokens semânticos, que carregam significado e referenciam os primitivos por trás em vez de atribuir um valor de cor direto a um token chamado texto-secundário, você faz esse token apontar pra um primitivo já existente na biblioteca. Essa referência entre camadas, chamada de aliasing dentro do Figma, é o que permite trocar um tema inteiro sem reescrever cada componente: muda o primitivo, e todo semântico que aponta pra ele muda junto. A nomenclatura também importa mais do que parece. Um padrão que funciona bem segue a lógica categoria/papel/variante um token de cor para ação principal vira algo como cor/ação/primária, e um rótulo de botão desabilitado vira cor/texto/desabilitado. Qualquer pessoa do time, olhando só pro nome, precisa entender o que aquele token faz e onde ele se encaixa, sem precisar abrir o arquivo pra descobrir. No Figma, essa estrutura toda vive dentro do sistema de variáveis, organizadas em coleções uma coleção para os primitivos, outra para os semânticos com modos que resolvem tema claro e escuro sem duplicar componente nenhum: o mesmo componente troca de paleta inteira só pela troca do modo ativo. Foi um problema chato de resolver antes das variáveis existirem, e hoje é basicamente automático. A parte que realmente fecha o ciclo, porém, é a sincronização com o código. Os tokens definidos como variáveis no Figma podem ser exportados como JSON, como propriedades customizadas de CSS, ou por meio de pipelines mais robustos de Style Dictionary, seguindo inclusive o formato padronizado pelo W3C pra tokens de design. Sem esse pipeline de exportação formalizado, design e engenharia acabam mantendo dois sistemas paralelos que divergem a cada mudança um problema que fica invisível por meses e só aparece de forma grave quando um rebrand exige atualizar valor em dois lugares que nunca estiveram formalmente conectados. Com o pipeline certo, o processo se inverte: uma mudança de token no Figma se propaga direto até a produção, sem precisar de uma conversa de handoff pra cada ajuste. É esse fechamento que dá sentido a tudo que vimos até aqui. A pesquisa garante que você está resolvendo o problema certo. O briefing garante que a decisão de design está amarrada a um objetivo real. O layout responsivo garante que a experiência se adapta a qualquer tela. E o design token garante que, depois de tudo isso definido, a consistência sobrevive ao tempo porque o valor certo está guardado num único lugar, não espalhado em memória de quem lembrou de replicar manualmente. É esse o tipo de estrutura técnica que separa um Design System que escala de um que só existe bonito no primeiro release.