Governança de design tokens funciona melhor dividida por tipo de mudança

O conflito de propriedade dos design tokens

Em um design system, uma mudança de cor gera disputa: designers argumentam que tokens são decisões de design e devem poder alterá-los sem mexer em código; engenheiros argumentam que tokens entram no produto, logo são código e devem passar por review como código. O resultado comum é que designers param de tocar os arquivos de token, porque toda mudança exige aprovação de alguém sem contexto sobre a decisão visual. Figma e repositório passam a descrever sistemas ligeiramente diferentes, e ninguém sabe qual dos dois está errado.

Dividir a propriedade por tipo de mudança

A proposta é separar dois tipos de mudança que convivem no mesmo arquivo de definição de tokens, geralmente um JSON:

• Mudar o valor bruto (por exemplo, color.blue.600) tem justificativa de design e revisão visual; engenharia não tem nada relevante a acrescentar. Esse nível pertence ao time de design.
• Renomear ou remover um token semântico (como action.primary.background) afeta o uso em componentes, tem consumidores e custo de migração - coisas que não são visíveis no Figma. A camada semântica, os nomes que as pessoas realmente digitam, funciona como uma API pública e deve pertencer a um pequeno time de design systems com pelo menos um designer e um engenheiro. O output de build fica com a engenharia.

Isso se materializa em regras de CODEOWNERS por pasta: valores brutos para o time de design, camada semântica para o time de design systems (com assentos mistos), transforms e saída de plataforma para o frontend. O time da camada semântica é intencional: quando uma regra lista vários times, qualquer um pode aprovar, então o arquivo indica quem é acionado, não quem tem veto.

A regra de governança também pode ficar embutida no próprio token, via $extensions, usando chave em formato reverse-domain para evitar colisões, com campos como valueOwner: design e nameOwner: design-systems.

Automatizar a verificação crítica

Regras que dependem de memorização duram poucas semanas, argumenta o autor. A verificação essencial a automatizar é: um token semântico existia ontem e sumiu hoje. Um job no pipeline de pull request compara os nomes antes e depois da mudança e, se algum desapareceu, o build para com uma mensagem legível por designers, sem glosário: "Blocked: 2 semantic tokens were removed", listando os tokens e instruindo a manter os nomes antigos como aliases marcados como deprecated, ou pedir aprovação ao time de design systems.

Assim, mudança de valor passa direto, enquanto renomeação fica bloqueada até que alguém preserve o nome antigo. Quem cuida do pipeline consegue implementar isso em uma tarde.

Conclusão

Ninguém precisa vencer o debate sobre quem é dono dos tokens. Basta saber, por nome, quem decide quando um token desaparece - e, se isso não estiver definido antes do próximo release, é por ali que se deve começar.