Nesta página: Como nasceu o plugin Selection to Variables

Se você quiser ler mais sobre o plugin, acesse a página do projeto.

Arquivos de design costumam começar organizados e terminar caóticos. No início de um projeto, é comum existir uma intenção clara de estrutura: tipografia definida, cores documentadas, espaçamentos consistentes. Mas à medida que o produto evolui, novas telas surgem, componentes são duplicados, decisões rápidas são tomadas e valores começam a se espalhar pelo arquivo.

Com o tempo, aparecem padrões como:

  • cores iguais aplicadas manualmente em várias camadas
  • tipografia repetida sem uso de estilos
  • espaçamentos definidos diretamente nos elementos
  • variações pequenas do mesmo valor espalhadas pelo arquivo

Os valores estão ali, mas o sistema não, foi a partir dessa fricção que nasceu o plugin Selection to Variables.

O problema

Um dos desafios mais comuns ao trabalhar com design systems não é criar um sistema do zero. O verdadeiro desafio costuma ser extrair um sistema de algo que já existe. Em muitos produtos, a interface evolui antes que um sistema seja formalizado. Quando chega o momento de estruturar tokens, variáveis ou estilos, grande parte do trabalho consiste em investigar o arquivo para descobrir:

  • quais valores realmente são recorrentes
  • quais são exceções
  • quais deveriam virar assets reutilizáveis

Esse processo é manual e lento. Abrir camadas, comparar valores, procurar repetições e decidir o que merece virar variável ou estilo acaba se tornando um trabalho de limpeza de interface. Foi nesse contexto que comecei a pensar em uma ferramenta que pudesse ajudar nesse processo.

A primeira ideia

A ideia inicial era simples. Criar um plugin que pudesse:

  • ler os elementos selecionados no arquivo
  • extrair valores da interface
  • transformar esses valores em variáveis

Se um designer selecionasse um frame ou um grupo de elementos, o plugin poderia identificar:

  • cores
  • textos
  • font size
  • line height
  • largura e altura
  • border radius
  • espaçamentos

A partir desses dados, seria possível gerar variáveis automaticamente. Essa primeira versão já ajudava a economizar tempo, mas rapidamente ficou claro que extrair valores não era suficiente.

O problema da extração bruta

Quando o plugin começou a listar todos os valores encontrados na interface, surgiu um novo problema. Havia informação demais. Nem todo valor encontrado no arquivo merece virar token ou variável. Muitos valores aparecem apenas uma vez, outros são resultado de decisões pontuais.

A pergunta deixou de ser apenas: quais valores existem aqui?

E passou a ser: quais valores realmente indicam padrões da interface?

Foi nesse momento que surgiu uma das decisões mais importantes do projeto.

Repetição como sinal de padrão

Em vez de tratar todos os valores da mesma forma, o plugin passou a identificar valores repetidos. Valores que aparecem várias vezes em um arquivo normalmente indicam um padrão real da interface. Eles são fortes candidatos a se tornarem:

  • tokens
  • variáveis
  • estilos reutilizáveis

Com essa mudança, o plugin deixou de ser apenas um extrator de dados e passou a atuar como um assistente de organização de design system. Agora ele podia responder perguntas como:

  • quais cores aparecem com mais frequência
  • quais tamanhos de texto são realmente usados
  • quais espaçamentos se repetem na interface

Essa simples mudança melhorou muito a qualidade das sugestões geradas.

Variáveis não eram suficientes

Inicialmente o plugin gerava apenas variáveis, mas rapidamente ficou claro que variáveis resolvem apenas parte do problema. Variáveis representam valores reutilizáveis, mas muitos padrões de interface são melhor representados como estilos completos.

Por exemplo:

  • tipografia costuma ser definida como estilo de texto
  • cores muitas vezes são aplicadas como estilos de cor
  • sombras e efeitos aparecem como effect styles

Com isso, o plugin evoluiu para gerar também:

  • text styles
  • color styles
  • effect styles

Isso permitiu transformar padrões visuais completos em assets reutilizáveis.

Conectando variáveis e estilos

Outra melhoria importante surgiu depois. No Figma, variáveis e estilos são sistemas diferentes. Muitas vezes eles acabam sendo usados de forma separada, mas existe um benefício claro em conectá-los. Sempre que possível, o plugin passou a permitir que estilos reutilizassem variáveis compatíveis. Isso significa que um estilo pode usar valores que já existem como variáveis. Esse pequeno detalhe ajuda a criar uma estrutura mais coerente dentro do arquivo.

UX também era parte do problema

Em vários momentos durante o desenvolvimento, o plugin funcionava tecnicamente, mas parecia quebrado.

  • botões não davam feedback imediato
  • processos aconteciam sem indicação visual
  • resultados eram gerados, mas não ficavam claros na interface

Isso levou a várias melhorias na experiência de uso do plugin:

  • estados de carregamento
  • mensagens de status
  • organização dos resultados por tipo
  • feedback visual após criação de assets

Essas mudanças reforçaram uma lição importante: ferramentas de design também precisam de uma boa experiência de uso. Não basta que a lógica funcione.

O que o plugin faz hoje

Hoje o plugin permite:

  • escanear frames, grupos e seções
  • detectar valores de interface automaticamente
  • identificar valores recorrentes
  • sugerir agrupamentos semânticos
  • criar variáveis reutilizáveis
  • criar text styles
  • criar color styles
  • criar effect styles
  • aplicar esses assets à interface
  • exportar tokens em JSON

O objetivo não é automatizar completamente a criação de design systems, mas reduzir o trabalho manual necessário para estruturar um sistema a partir de um produto existente.

O que eu aprendi

Esse projeto trouxe alguns aprendizados importantes.

  • valores repetidos são melhores indicadores de padrão do que simples extração de dados;
  • automação em design systems precisa sempre permitir revisão humana;
  • variáveis e estilos se tornam mais úteis quando fazem parte do mesmo fluxo de criação;
  • construir ferramentas também exige pensar na experiência de uso;

O que vem depois

O plugin já foi publicado como repositório open source e submetido à comunidade do Figma. A ideia é continuar evoluindo a ferramenta com base no uso real e na colaboração da comunidade. Possíveis próximos passos incluem melhorias na identificação semântica de tokens, evolução da exportação de dados e refinamentos na experiência de uso.