Construir um Design System no Figma não significa começar criando dezenas de componentes. O trabalho começa antes: entender o que já existe no produto, identificar decisões que se repetem e definir quais delas precisam se transformar em uma base reutilizável para o time.
Neste tutorial, vamos montar essa estrutura passo a passo: auditoria, organização do arquivo, foundations, Variables, modos, Auto Layout, componentes, propriedades, documentação e publicação da library. O objetivo é chegar a um sistema pequeno, funcional e preparado para crescer — não a uma biblioteca enorme que ninguém consegue manter.
Se você ainda está tentando entender a arquitetura por trás desses recursos, leia primeiro o guia sobre Design System no Figma. Para uma visão mais ampla sobre conceito, componentes e governança, consulte também o guia completo de Design System.
Antes de abrir o Figma: defina o que o sistema precisa resolver
Um dos erros mais comuns é começar o Design System pela ferramenta. O time abre um novo arquivo, cria uma página chamada “Components” e começa a reconstruir botões sem saber se aqueles são realmente os maiores problemas do produto.
Comece fazendo uma pequena auditoria das interfaces que já existem. Observe os principais fluxos do produto e procure decisões que aparecem repetidamente:
- quantas cores diferentes estão sendo utilizadas para a mesma função;
- quantos estilos de texto cumprem funções equivalentes;
- quantos botões visualmente semelhantes existem;
- quais espaçamentos aparecem com frequência;
- quais componentes foram recriados em diferentes arquivos;
- quais diferenças são intencionais e quais são apenas inconsistências;
- quais problemas de acessibilidade se repetem.
O resultado da auditoria não precisa ser uma documentação enorme. Uma planilha, um board no FigJam ou uma página dentro do próprio arquivo pode ser suficiente para registrar padrões, inconsistências e decisões que precisam ser tomadas.
Passo 1: crie e organize o arquivo do Design System
Crie um arquivo dedicado ao sistema e dê a ele um nome que faça sentido para quem precisará encontrá-lo no futuro. Evite nomes genéricos como “Components final 2”. Algo como Nome do Produto — Design System já comunica melhor sua função.
Uma estrutura inicial possível é:
- 00 — Welcome: objetivo, responsáveis, documentação e orientações gerais;
- 01 — Foundations: cores, tipografia, espaçamento, radius, elevação e outras decisões básicas;
- 02 — Components: componentes reutilizáveis;
- 03 — Patterns: combinações e soluções recorrentes;
- 04 — Playground / QA: área para testar componentes e combinações antes da publicação.
Isso não é uma estrutura obrigatória. A própria Figma destaca que uma equipe pode manter tudo em um único arquivo ou dividir foundations, ícones, componentes e plataformas em libraries diferentes conforme o sistema amadurece.
Passo 2: defina uma convenção de nomes antes de criar componentes
A nomenclatura é uma das decisões mais simples de ignorar no início e mais caras de corrigir depois. Componentes, Variables e propriedades precisam seguir uma lógica previsível.
Não existe uma sintaxe universal. Você pode trabalhar com barras, pontos, hífens ou outra estrutura. O que importa é que os nomes expressem uma lógica compreensível e sejam utilizados de maneira consistente.
Um exemplo para cores primitivas:
color/blue/100
color/blue/500
color/blue/700
color/neutral/0
color/neutral/900E uma camada semântica poderia utilizar:
color/background/default
color/background/brand
color/text/default
color/text/subtle
color/action/primary
color/action/primary-hoverA diferença é importante: blue/500 descreve um valor; action/primary comunica uma função. Essa separação ajuda a mudar a aparência sem precisar alterar a intenção consumida pelos componentes.
Para aprofundar arquitetura e nomenclatura, consulte o guia sobre Design Tokens.
Passo 3: crie as primeiras Variables
No Figma atual, as Variables são gerenciadas pela área Variables disponível na navegação do arquivo. É nela que você cria collections, Variables, modes e grupos.
Uma boa forma de começar é não transformar todo valor existente em Variable de uma vez. Crie primeiro aquilo que será realmente compartilhado por diferentes componentes.
Crie uma collection de valores básicos
Você pode começar com uma collection para valores de referência, por exemplo:
Primitive
color/neutral/0
color/neutral/100
color/neutral/900
color/blue/500
color/red/500
spacing/4
spacing/8
spacing/12
spacing/16
spacing/24
radius/small
radius/medium
radius/largeOs nomes são apenas exemplos. A escala deve refletir as necessidades observadas no produto.
Crie Variables semânticas com aliases
Depois dos valores básicos, crie uma camada que represente a intenção das decisões. No Figma, uma Variable pode utilizar outra Variable compatível como alias.
Por exemplo:
color/action/primary
→ alias de color/blue/500
color/text/default
→ alias de color/neutral/900
color/background/default
→ alias de color/neutral/0Se o valor da cor principal mudar posteriormente, os componentes continuam consumindo color/action/primary. A intenção permanece enquanto a implementação visual pode evoluir.
O artigo sobre Figma Variables aprofunda aliases, collections, modes e estratégias de tokens semânticos.
Passo 4: configure Light Mode, Dark Mode e outros contextos quando fizer sentido
Modes permitem que uma mesma Variable tenha valores diferentes dependendo do contexto. Um caso comum é alternar entre temas claro e escuro.
A Variable:
color/background/defaultpode apontar para um valor claro no modo Light e para outro valor no modo Dark. O componente continua consumindo a mesma decisão sem precisar possuir uma variante específica apenas para trocar todas as suas cores.
| Variable | Light | Dark |
|---|---|---|
color/background/default | neutral/0 | neutral/900 |
color/text/default | neutral/900 | neutral/0 |
color/border/default | neutral/200 | neutral/700 |
Não crie modos apenas porque o recurso existe. Eles fazem sentido quando o mesmo conjunto de decisões precisa assumir valores diferentes por tema, marca, plataforma, viewport ou outro contexto real do produto.
A quantidade de modes disponível por collection depende do plano utilizado no Figma, então vale conferir os limites atuais antes de definir uma arquitetura baseada em muitos contextos.
Passo 5: aplique escopo e Code Syntax às Variables importantes
Uma Variable também pode indicar onde deve aparecer como opção. O recurso de scope reduz a chance de alguém utilizar uma decisão no lugar errado.
Uma Variable destinada a radius, por exemplo, pode ser limitada a propriedades de canto; uma Variable de cor para texto pode receber um escopo relacionado a text fill.
Para equipes que conectam design e desenvolvimento, o Figma permite ainda cadastrar Code Syntax. Assim, uma Variable pode ter uma representação própria para Web, Android ou iOS que aparece durante a inspeção no Dev Mode.
Design:
color/action/primary
Web:
var(--color-action-primary)Essa correspondência não transforma automaticamente o Design System em código, mas reduz ambiguidade entre a decisão utilizada no design e a nomenclatura esperada na implementação.
Passo 6: construa as foundations antes dos componentes complexos
Com as principais Variables organizadas, defina as foundations que serão consumidas pelos componentes. Dependendo do produto, isso pode incluir:
- cores;
- tipografia;
- spacing;
- radius;
- elevação;
- iconografia;
- layout e grids.
Não é necessário transformar todas as foundations no mesmo tipo de recurso. Variables são ótimas para valores reutilizáveis e contextuais, enquanto Styles ainda podem fazer sentido quando é necessário representar um conjunto de propriedades.
Se a base de cores ainda não estiver definida, consulte também o tutorial sobre como criar uma paleta de cores para Design System.
Passo 7: construa seu primeiro componente com Auto Layout
Agora vamos transformar as foundations em um componente real. Um botão é um bom exercício porque reúne conteúdo, espaçamento, cor, radius, diferentes estados e comportamento responsivo.
1. Crie o conteúdo do botão
Adicione uma camada de texto com um rótulo como Continuar.
2. Aplique Auto Layout
Selecione o texto e utilize Shift + A. O Figma cria um frame com Auto Layout ao redor do conteúdo.
Defina:
- padding horizontal;
- padding vertical;
- alinhamento;
- gap, caso existam outros elementos;
- comportamento de largura e altura.
Os valores devem vir do seu sistema de spacing, e não de números escolhidos isoladamente para o componente.
O Auto Layout atual suporta fluxos horizontal, vertical e grid. Para um botão simples, o fluxo horizontal costuma ser suficiente; estruturas mais complexas podem combinar diferentes níveis de Auto Layout.
3. Aplique as Variables
Em vez de utilizar valores locais diretamente, vincule o componente às decisões que já definimos.
Fill → color/action/primary
Text → color/text/on-primary
Radius → radius/medium
Horizontal padding → spacing/16
Vertical padding → spacing/12Os nomes e valores acima são apenas um exemplo. A lógica é mais importante que a escala específica.
4. Transforme o frame em componente
Depois que o comportamento básico estiver correto, transforme o frame em um Main Component. A partir dele, novas instâncias passam a herdar as mudanças feitas na origem.
Dê ao componente um nome funcional e simples, como:
ButtonEvite incluir detalhes que já serão controlados por propriedades, como Button/Blue/Large/Hover.
Passo 8: crie Variants apenas para diferenças que realmente representam estados ou tipos
Variants organizam versões relacionadas de um componente em um component set. Para nosso botão, poderíamos começar com propriedades como:
Type:
Primary
Secondary
State:
Default
Hover
Pressed
Disabled
Size:
Small
Medium
LargeIsso não significa que toda combinação possível precise existir. Antes de criar uma nova variant, pergunte se a diferença realmente representa um estado estrutural ou se pode ser controlada de outra forma.
Passo 9: use Component Properties para evitar explosão de Variants
Component Properties expõem controles específicos diretamente para quem utiliza a instância. Atualmente, o Figma trabalha com diferentes tipos de propriedades que podem ajudar a manter os componentes mais flexíveis.
| Property | Quando usar |
|---|---|
| Text | Permitir edição do conteúdo textual |
| Boolean | Mostrar ou esconder uma camada opcional |
| Instance swap | Trocar uma instância interna, como um ícone |
| Variant | Alternar estados ou versões estruturadas |
| Slot | Permitir conteúdo flexível dentro de uma área controlada |
No nosso botão, por exemplo, o texto não precisa gerar uma nova variant. Crie uma Text Property para o label.
Se o ícone for opcional, uma Boolean Property pode controlar sua visibilidade. Se diferentes ícones puderem ser usados, uma Instance Swap Property pode indicar quais componentes são alternativas adequadas.
Passo 10: use Slots quando o componente precisar aceitar conteúdo mais flexível
Nem todo componente se encaixa bem em uma lista fechada de Variants. Cards, modais, listas e outras estruturas podem precisar aceitar diferentes quantidades e tipos de conteúdo.
Os Slots são um tipo de Component Property que cria uma área flexível dentro da instância. Nessa área é possível inserir, reorganizar ou redimensionar conteúdo sem precisar detachar o componente principal.
Isso pode reduzir componentes com dezenas de combinações artificiais. Ainda assim, flexibilidade precisa ter limites: se qualquer conteúdo puder entrar em qualquer lugar, o componente deixa de comunicar um padrão útil.
Passo 11: teste o componente em situações reais
Não publique o componente assim que ele parecer correto na página de documentação. Coloque instâncias em situações próximas das interfaces reais.
Teste pelo menos:
- textos curtos e longos;
- conteúdo em outro idioma quando internacionalização for relevante;
- larguras diferentes;
- todos os estados;
- combinações com outros componentes;
- Light e Dark Mode, quando existirem;
- uso sem e com ícone;
- conteúdo de tamanho extremo.
Se o time precisa detachar a instância para executar um cenário normal, isso é um sinal de que a arquitetura do componente merece revisão.
Passo 12: documente o componente antes de publicá-lo
Uma biblioteca não deveria exigir que a pessoa responsável pelo Design System esteja disponível para explicar cada componente.
Registre pelo menos:
- qual problema o componente resolve;
- quando utilizá-lo;
- quando não utilizá-lo;
- quais propriedades podem ser alteradas;
- quais estados existem;
- regras de conteúdo;
- considerações de responsividade;
- requisitos de acessibilidade;
- correspondência com código, quando existir.
O Figma permite adicionar descrição e link para documentação aos componentes. Para sistemas maiores, a documentação pode continuar em uma plataforma externa ou próxima do código.
Se você estiver transformando um produto existente em sistema, veja também o guia sobre como documentar um Design System sem começar do zero.
Passo 13: valide acessibilidade antes de transformar o componente em padrão
Quando um componente entra em uma library, seus acertos e erros passam a ser multiplicados. Por isso, acessibilidade precisa ser considerada antes da distribuição.
No caso do botão, observe:
- contraste entre texto e fundo;
- estados de foco previstos;
- tamanho e legibilidade do texto;
- uso correto de cor como sinal complementar, não exclusivo;
- estado disabled compreensível;
- implementação semântica esperada no código;
- área de interação adequada ao contexto.
A camada do Figma não consegue validar sozinha toda a acessibilidade da implementação, mas o Design System pode impedir que problemas conhecidos sejam repetidos desde a origem.
Para aprofundar essa etapa, consulte acessibilidade em Design Systems e WCAG e o guia específico sobre acessibilidade cromática.
Passo 14: publique a library
Enquanto components, styles e Variables permanecem locais, eles só estão disponíveis naquele arquivo. Para distribuí-los para outros arquivos, o Design System pode ser publicado como uma library.
Segundo a documentação atual da Figma, publicação de libraries está disponível em planos pagos. Components, styles e Variables podem ser criados localmente mesmo sem uma library publicada.
Quando o sistema estiver pronto para a primeira distribuição:
- abra a área de Assets;
- acesse Libraries;
- localize o arquivo atual;
- selecione Publish;
- revise quais assets serão incluídos;
- escreva uma descrição clara sobre a publicação;
- publique.
Não trate a descrição como burocracia. Ela é uma forma de explicar para quem utiliza a library quais decisões estão chegando ao produto.
Passo 15: teste a library em outro arquivo
A melhor forma de descobrir se a biblioteca está realmente utilizável é sair do arquivo onde ela foi construída.
Crie ou abra outro arquivo de produto, habilite a library e tente trabalhar como uma pessoa que não participou da construção.
Observe:
- se os componentes são fáceis de encontrar;
- se os nomes fazem sentido fora do contexto da equipe responsável;
- se as propriedades importantes estão expostas;
- se existem opções demais;
- se as Variables corretas aparecem nos contextos esperados;
- se a documentação responde às dúvidas mais comuns;
- se existe necessidade frequente de overrides ou detach.
Esse teste costuma revelar problemas de arquitetura que não são perceptíveis quando todo o conhecimento está concentrado em quem criou o sistema.
Passo 16: teste o fluxo de atualização antes de escalar
Uma library não existe apenas para distribuir a primeira versão dos componentes. Ela também precisa conseguir evoluir.
Faça um teste simples:
- altere uma propriedade do Main Component;
- publique a atualização;
- abra um arquivo consumidor;
- revise a notificação de atualização;
- aceite a mudança;
- confirme se as instâncias continuam funcionando como esperado.
Esse fluxo ajuda a entender o efeito de uma mudança antes que o sistema tenha dezenas de consumidores.
Passo 17: aproxime Design System e desenvolvimento
Um Design System no Figma não substitui a implementação em código. Quanto maior a maturidade do sistema, mais importante fica deixar claras as correspondências entre as duas camadas.
Algumas práticas que ajudam:
- usar nomes compreensíveis entre design e desenvolvimento;
- adicionar Code Syntax às Variables quando relevante;
- documentar o componente equivalente em código;
- alinhar propriedades e estados;
- registrar diferenças intencionais entre plataformas;
- utilizar Dev Mode durante o handoff.
No Dev Mode, Variables utilizadas no design podem exibir nome, collection, mode, valor e cadeia de aliases, além de sintaxe cadastrada para a plataforma. Isso ajuda desenvolvimento a entender a decisão utilizada sem depender apenas do valor visual final.
Uma estrutura mínima para o primeiro Design System
Se você estiver começando, não precisa sair deste tutorial com uma library de 100 componentes. Um primeiro sistema funcional poderia conter:
| Área | Primeira versão |
|---|---|
| Cor | Primitivas + principais tokens semânticos |
| Spacing | Escala utilizada nos componentes principais |
| Radius | Valores realmente utilizados pelo produto |
| Tipografia | Estilos ou Variables necessários aos principais contextos |
| Components | Button, input e alguns elementos recorrentes |
| Documentation | Uso, estados, propriedades e acessibilidade |
| Library | Primeira versão publicada e testada em outro arquivo |
Depois disso, deixe as necessidades do produto indicarem o que deve entrar no roadmap do sistema.
Erros comuns ao construir um Design System no Figma
Criar todos os componentes antes de testar qualquer um
Isso aumenta o custo de corrigir decisões ruins. Construa, teste em uma interface real e só então amplie o padrão.
Criar Variables para qualquer número existente
Um sistema não fica melhor apenas porque possui milhares de tokens. Transforme em decisão compartilhada aquilo que realmente precisa de controle e reutilização.
Criar uma Variant para cada combinação possível
Use Component Properties, Instance Swap, Boolean Properties e Slots quando forem formas mais adequadas de representar flexibilidade.
Construir tudo com dimensões fixas
Componentes precisam responder a mudanças de conteúdo. Auto Layout deve representar relações entre os elementos, não apenas reproduzir uma tela específica.
Publicar sem documentação
Um componente pode ser reutilizável tecnicamente e ainda ser difícil de usar corretamente. Documentação faz parte do sistema.
Usar detach como solução normal
Detach é útil em exceções, mas frequência elevada costuma indicar que os componentes não estão cobrindo necessidades reais ou estão rígidos demais.
Checklist antes de publicar a primeira versão
- ☐ O objetivo da library está documentado.
- ☐ Os nomes seguem uma convenção consistente.
- ☐ Variables importantes possuem descrição e função clara.
- ☐ Aliases representam corretamente a camada semântica.
- ☐ Modes foram criados apenas quando existe necessidade real.
- ☐ Os componentes usam Auto Layout de forma adequada.
- ☐ Estados e variantes necessários foram testados.
- ☐ Component Properties reduzem overrides desnecessários.
- ☐ Componentes foram testados com textos e tamanhos diferentes.
- ☐ Acessibilidade foi considerada.
- ☐ A documentação explica quando usar e quando evitar.
- ☐ A library foi testada em outro arquivo.
- ☐ O fluxo de atualização foi validado.
- ☐ Design e desenvolvimento compartilham uma nomenclatura compreensível.
O que fazer depois da primeira versão?
Depois de publicar, não volte imediatamente para o arquivo para criar mais vinte componentes. Observe como as pessoas utilizam o que já existe.
Novos componentes deveriam surgir de problemas recorrentes. Quando uma necessidade aparece uma única vez, talvez seja uma exceção do produto. Quando diferentes equipes começam a resolver repetidamente o mesmo problema, existe um candidato muito mais forte para o Design System.
Com o crescimento do sistema, você pode aprofundar arquitetura de libraries, governança, documentação, acessibilidade e relação com engenharia. O conteúdo sobre estratégia e desafios de Design Systems discute justamente essa evolução organizacional.
Por onde começar um Design System no Figma?
Comece auditando o produto e identificando decisões recorrentes. Depois organize foundations e Variables, construa poucos componentes importantes, teste-os em interfaces reais e só então publique uma library.
Preciso usar Variables para criar um Design System no Figma?
Variables são muito úteis para representar valores reutilizáveis, tokens e contextos como temas, mas um Design System não é definido apenas por Variables. Componentes, documentação, governança e processos também fazem parte do sistema.
Todo componente deve usar Auto Layout?
Auto Layout é especialmente útil quando o componente precisa responder a mudanças de conteúdo, espaçamento ou tamanho. A arquitetura deve representar o comportamento real do componente, e não aplicar Auto Layout apenas por regra.
Quando devo publicar o Design System como library?
Publique quando uma primeira parte do sistema estiver suficientemente estável, documentada e testada em situações reais. Não é necessário esperar que todos os componentes possíveis estejam prontos.
Variants ou Component Properties: qual usar?
Variants funcionam bem para estados e versões estruturadas de um componente. Component Properties são úteis para expor controles como texto, visibilidade, troca de instância e áreas flexíveis. Na prática, componentes podem combinar essas abordagens.
Conclusão
Construir um Design System no Figma é menos sobre produzir uma grande biblioteca e mais sobre transformar decisões recorrentes em uma estrutura reutilizável e compreensível.
Comece pelo produto que você já possui. Audite inconsistências, organize foundations, transforme decisões compartilhadas em Variables, crie componentes que respondam ao conteúdo com Auto Layout e use Variants e Component Properties para representar apenas a flexibilidade necessária.
Depois, teste essas decisões fora do arquivo de origem, documente seu uso e publique uma primeira versão da library. A partir daí, o sistema deve crescer em resposta a problemas reais de design e desenvolvimento — não apenas porque é possível adicionar mais componentes.
Para entender em mais profundidade como libraries, components e Variables se relacionam dentro da ferramenta, continue no guia sobre Design System no Figma. Para explorar todo o cluster, acesse também a biblioteca de Design Systems da CamaraUX.
