Nomear é o argumento: tokens crescem e equipes travam na escolha de nomes

Dois problemas, uma mesma crença

O texto parte de uma observação prática sobre sistemas de design: as equipes costumam travar em decisões de nomenclatura, de dois modos opostos. Algumas adiam a escolha de nomes porque sentem que ela é definitiva e pesada. Outras criam tokens sem critério até chegar a centenas de variáveis, como o caso de um time que foi de 20 para 487 tokens em uma tarde. O autor, Joey Banks, sugere que os dois comportamentos têm a mesma base: a crença de que, uma vez atribuído, um nome não pode mais mudar. Segundo ele, pode mudar.

Por que o nome importa mais com IA

O autor argumenta que, mesmo com ferramentas capazes de gerar telas em segundos, a nomenclatura continua relevante. Quando uma IA lê um arquivo, os nomes carregam grande parte do contexto que ela usa. Um token chamado Toast/Background/Default informa a função da cor, enquanto Neutral/400 diz quase nada. Assim, nomes que antes serviam apenas para a equipe passam a funcionar também como instruções para qualquer ferramenta que acesse o arquivo.

Recomendações práticas

O texto propõe pequenas ações, cada uma voltada a um dos dois problemas.

Para a equipe paralisada, a sugestão é nomear o que é necessário nesta semana, e não o que pode ser necessário no futuro. O mais importante no início é definir um padrão de criação de nomes. Por exemplo, combinar que valores primitivos guardam valores e que camadas semânticas guardam significado. Esse padrão pode ser definido em uma tarde e serve de base para os nomes seguintes, que tendem a melhorar com o uso.

Para quem cria tokens em excesso, o autor propõe que um novo token precise justificar sua existência. Antes de criá-lo, a equipe deve verificar se algum token existente já atende ao caso ou pode ser ampliado para cobrir a função antiga e a nova. Uma regra citada é que um valor que aparece em vários lugares merece um nome, e um valor usado uma única vez pode esperar. Segundo o autor, esse hábito explica grande parte da diferença entre 20 e 487 tokens.

O texto também indica que renomear custa menos do que parece. Variáveis com alias propagam atualizações pelo sistema, e a renomeação em massa resolve camadas rapidamente. Para o autor, renomear é manutenção, não quebra do sistema.

Por fim, ele recomenda registrar o porquê de cada nome em uma frase, na descrição da variável ou do componente, no caso do Figma. Essas descrições aparecem na busca e ajudam quem chega depois. Para sistemas com muitos tokens já sem documentação, o autor menciona que uma ferramenta como o Figma Console MCP pode ajudar: o usuário pede ao Claude uma planilha com descrições sugeridas para cada nome. As sugestões podem estar erradas, mas, segundo o autor, corrigir um rascunho é mais fácil do que preencher centenas de células vazias. Para ele, as correções são onde o raciocínio de fato se registra.

Uma nota fora do tema central

A última parte do texto é uma resposta a uma designer recém-contratada, que se sente atrasada diante do ritmo de novas ferramentas e modelos. O autor sugere escolher um projeto que tenha sentido pessoal para aprender, como o exemplo dele de um aplicativo para macOS que mostra a glicemia na barra de menus, criado com ajuda do Claude Code sem que ele conheça a f

programação. Ele também defende seguir os próprios interesses em vez da relevância momentânea, e diz que o excesso de conteúdo sobre supostas transformações com IA pode fazer pequenos ganhos parecerem insuficientes.

Conclusão

Para o autor, a saída para as duas situações é a mesma: definir um padrão, nomear o que está diante da equipe e registrar o porquê junto do nome. O restante surge conforme o trabalho avança.