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 quase sempre começam organizados e terminam caóticos, pelo menos essa tem sido minha experiência trabalhando com produtos digitais ao longo do tempo. No início existe uma intenção clara de estrutura: tipografia definida, cores documentadas, espaçamentos consistentes, mas conforme o produto cresce, novas telas aparecem, componentes são duplicados, decisões rápidas são tomadas e, pouco a pouco, os valores começam a se espalhar pelo arquivo. Depois de algum tempo, começam a surgir 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 continuam lá. O problema é que o sistema não, foi exatamente essa fricção que me levou a criar o plugin Selection to Variables.

O problema

Uma coisa que aprendi trabalhando com design systems é que o desafio raramente é criar um sistema do zero. O desafio real costuma ser extrair um sistema de algo que já existe. Muitos produtos crescem antes que um sistema seja formalizado, quando chega o momento de organizar tokens, variáveis ou estilos, boa parte do trabalho consiste em investigar o arquivo para entender:

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

Esse processo normalmente é manual e bastante demorado, abrir camadas, comparar valores, procurar repetições, decidir o que merece virar variável ou estilo. Muitas vezes parece mais um trabalho de limpeza do que de design, foi nesse contexto que comecei a pensar em uma ferramenta que pudesse ajudar nesse processo.

A primeira ideia

A primeira ideia era bastante simples. Eu queria 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 coisas como:

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

Em teoria, isso já economizaria bastante tempo, mas quando comecei a testar a ideia na prática, percebi que apenas extrair valores não resolvia o problema.

O problema da extração bruta

Quando o plugin começou a listar todos os valores encontrados na interface, um novo problema apareceu.

Informação demais, nem todo valor encontrado em um arquivo merece virar token ou variável, muitos 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 aí que uma das ideias mais importantes do projeto apareceu.

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 geralmente indicam um padrão real da interface. Eles são bons candidatos a se tornarem:

  • tokens
  • variáveis
  • estilos reutilizáveis

Essa mudança transformou completamente o plugin, ele deixou de ser apenas um extrator de dados e passou a funcionar mais como um assistente de organização de design system. Agora ele podia ajudar a responder perguntas como:

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

Variáveis não eram suficientes

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

Por exemplo:

  • tipografia geralmente vira estilo de texto
  • cores muitas vezes são usadas como estilos de cor
  • sombras aparecem como effect styles

Então o plugin evoluiu para gerar também:

  • text styles
  • color styles
  • effect styles

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

UX também fazia parte do problema

Durante o desenvolvimento, houve vários momentos em que o plugin funcionava tecnicamente, mas parecia quebrado.

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

Isso me fez perceber algo óbvio, mas fácil de ignorar: ferramentas de design também precisam de uma boa experiência de uso, foi quando comecei a adicionar:

  • estados de carregamento
  • mensagens de status
  • organização clara dos resultados
  • feedback visual após criar os assets

Esses detalhes fizeram muita diferença na sensação de confiança ao usar o plugin.

O que o plugin faz hoje

Hoje o plugin consegue:

  • escanear frames, grupos e seções
  • detectar valores da 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 nunca foi automatizar completamente a criação de design systems. A ideia é algo mais simples: reduzir o trabalho manual necessário para estruturar um sistema a partir de um produto existente.

O que eu aprendi

Esse projeto acabou trazendo alguns aprendizados interessantes.

  • valores repetidos são um ótimo indicador de padrões reais
  • automação em design systems precisa sempre permitir revisão humana
  • variáveis e estilos funcionam melhor quando fazem parte do mesmo fluxo
  • 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 agora é continuar evoluindo a ferramenta com base no uso real e na colaboração da comunidade.

Se você quiser explorar o projeto ou contribuir com melhorias, será sempre bem-vindo ou bem-vinda. 😀