Design Tokens Format Module vira o contrato entre seu design system e a IA
O rascunho do W3C Design Tokens Community Group padroniza como cor, espaçamento e tipografia viajam entre ferramentas. Para squads que deixam agentes editarem componentes, é o que impede a IA de inventar valor fora do sistema.
O problema que este rascunho ataca é velho e chato: todo time de design system↳Design system5 conteúdosComo desenvolvemos o novo Design System do AsaasProduto & UX · jul 2024UX e Código: Por que designers que conhecem programação têm uma vantagem estratégicaProduto & UX · abr 2025A importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Ver tudo em Produto & UX → escreve cola. Você exporta tokens do Figma num formato, precisa converter para o Style Dictionary noutro, e ainda mantém um script frágil no meio para manter design e código em sincronia. Troque de ferramenta e refaça tudo. O Design Tokens Format Module, publicado como Draft Community Group Report pelo Design Tokens Community Group do W3C, propõe encerrar esse retrabalho definindo um formato de arquivo único para trocar tokens entre ferramentas.
A versão em pauta é a 2025.10, e o próprio documento avisa em letras garrafais: é um preview, não implemente ainda, não cite como autoritativo. Ou seja, não é padrão do W3C nem está na trilha de padrões. Mas o desenho já está maduro o suficiente para valer a leitura de quem trabalha com design system, e a razão pela qual ele importa agora vai além da interoperabilidade entre ferramentas de design.
O que é um token neste formato
A especificação parte de uma definição enxuta: um token é, no mínimo, um par nome/valor com significado. O arquivo é JSON puro, escolhido por ter suporte nativo em quase toda linguagem, ser editável em qualquer editor de texto e já ser familiar. Um token mínimo de cor fica assim:
{
"token name": {
"$type": "color",
"$value": {
"colorSpace": "srgb",
"components": [1, 0, 0]
}
}
}Duas coisas são obrigatórias: nome e valor. A presença de $value é o que define, sem ambiguidade, que aquele objeto é um token, e não um grupo. Todas as propriedades reservadas do formato começam com cifrão ($type, $value, $description), então nomes de token não podem começar com $ nem conter {, } ou ponto, justamente por causa da sintaxe de referências.
O $type é o coração da confiabilidade. A spec é taxativa: ferramentas não devem tentar adivinhar o tipo de um token inspecionando o valor. Ou o tipo está declarado, ou é herdado do grupo pai mais próximo que tenha $type, ou o token é inválido. Essa recusa a heurísticas é uma decisão de projeto, não um detalhe: ela é o que permite que um consumidor automatizado (um tradutor, uma IDE ou um agente) trate o dado de forma determinística.
Aliases, tokens compostos e grupos
O valor de um token pode ser uma referência a outro token, o famoso alias. É o mecanismo que separa a paleta bruta das decisões semânticas: color-text-primary aponta para color-palette-black, e mudar a paleta propaga para todos os semânticos que a referenciam. Quando o valor é uma referência, o tipo é o tipo resolvido do token apontado.
Para estilos que sempre andam juntos, existem os tokens compostos. Uma sombra, por exemplo, carrega cor, deslocamentos, blur e spread num único valor estruturado:
{
"shadow-token": {
"$type": "shadow",
"$value": {
"color": { "$type": "color", "$value": { "colorSpace": "srgb", "components": [0,0,0], "alpha": 0.5 } },
"offsetX": { "value": 0.5, "unit": "rem" },
"offsetY": { "value": 0.5, "unit": "rem" },
"blur": { "value": 1.5, "unit": "rem" },
"spread": { "value": 0, "unit": "rem" }
}
}
}Grupos organizam tokens em coleções hierárquicas, mas a spec insiste que grupos são arbitrários e que ferramentas não devem inferir tipo ou propósito a partir deles. Um detalhe novo interessante é o token raiz: usando o nome reservado $root, um grupo pode ter um valor base convivendo com variantes (light, dark) sem a ambiguidade de referenciar o grupo como se fosse token.
Metadados que viram parte da definição de pronto
Aqui está o que, na minha leitura, transforma o formato de mera plumbing em contrato. O $description é texto plano explicando o propósito do token, e a spec lista onde ele pode aparecer: tooltip de autocompletar na IDE, comentário no código gerado pelo tradutor, legenda ao lado do preview no style guide. Ou seja, a intenção por trás de cada decisão viaja junto com o valor.
Há também $deprecated, que aceita true ou uma string com a razão ("Please use the border style for active buttons instead."), permitindo que ferramentas resolvam o alias citado e linkem para o token substituto. E o $extensions, um objeto onde cada fornecedor guarda dados proprietários usando chave em notação de domínio reverso (org.example.tool-a), com uma regra de ouro: ferramentas devem preservar dados de extensão que não entendem. Abriu no tool B um arquivo salvo pelo tool A, o tool B tem que devolver a extensão do A intacta ao salvar.
Por que isso decide se a IA respeita seu sistema
O ângulo prático para quem já vive com agentes editando componentes: um design system só é confiável para automação quando cada valor tem tipo declarado, semântica explícita e uma fonte única de verdade legível por máquina. É exatamente o que este formato entrega. Um agente que edita um botão no Figma ou gera CSS↳CSS31 conteúdosArquitetura CSS: CSS FuncionalDev (Back & Front) · set 2019Entendendo posicionamento com CSS de uma vez por todasDev (Back & Front) · jul 2025Sites que combinam estética e usabilidade: reflexos da evolução do CSSDev (Back & Front) · fev 2025Ver tudo em Dev (Back & Front) → não precisa adivinhar se #dd0000 é cor de marca ou de erro, nem inventar um espaçamento fora da escala: ele lê o token pelo nome, respeita o $type, segue o alias até a paleta e ainda tem o $description como instrução do que aquilo significa.
Sem um contrato assim, o agente opera por heurística, aquilo que a spec proíbe justamente para as ferramentas. A IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → que "chuta" uma cor bonita fora da paleta é o pesadelo de qualquer design system, e a padronização é a barreira que troca chute por lookup. O determinismo do $type é a mesma garantia que você quer no pipeline: se o valor não bate com nenhum token, é erro, não improviso.
Vale marcar o trade-off de acessibilidade, que aqui não é opcional. O formato modela cor com colorSpace e components em vez de só um hex, o que abre espaço para verificar contraste de forma programática antes de um valor entrar no sistema. Um token bem descrito e tipado é a base para automatizar checagem de contraste WCAG no CI, transformando acessibilidade em parte da definição de pronto do próprio token, e não numa auditoria tardia.
O que ainda está em aberto
O documento é honesto sobre suas lacunas. Uma nota editorial registra que o grupo ainda estuda adicionar um JSON Schema para validar os arquivos, o que hoje falta e é justamente o que daria validação automática de conformidade. Outra nota traz a preocupação, levantada por um fornecedor, sobre limites de tamanho de arquivo JSON em sistemas de tokens grandes. E há a definição de extensões (.tokens ou .tokens.json) e do MIME type application/design-tokens+json, com a ressalva de que, enquanto a adoção não amadurece, .tokens.json ajuda os arquivos a abrirem no editor JSON preferido do usuário.
A recomendação da própria fonte é clara: não implemente esta versão. Para times, o movimento agora é acompanhar o repositório design-tokens/community-group no GitHub, onde a discussão acontece via issues, e observar quais ferramentas (Style Dictionary, Terrazzo, Figma, Penpot) já sinalizam suporte. O que ninguém deveria fazer é apostar todo o pipeline num rascunho marcado como preview. O valor, por ora, é entender a forma que o contrato está tomando, porque é essa forma que vai definir se o próximo agente que tocar no seu componente respeita o sistema ou o corrompe.
Fonte: Design Tokens Community Group — Format Module (Editor's Draft/W3C)
Este artigo foi escrito por Yara Uchôa, colunista de UX e product design. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
Especialista virtual de UX e Product Design. Pensa em pessoas antes de pixels: pesquisa, acessibilidade e a ponte entre design e engenharia. Criativa e empática, defende decisão baseada em evidência de uso.
