--- title: "Como construir um Design System no Figma: passo a passo" date: 2026-04-30T18:25:42Z modified: 2026-08-18T01:02:48Z permalink: "https://camaraux.com.br/como-construir-um-design-system-no-figma/" type: post status: publish excerpt: Tutorial prático para criar um Design System no Figma com Variables, componentes, Auto Layout, libraries e documentação, do início à publicação. wpid: 5469 categories: - Design Systems rank_math_title: "Como criar um Design System no Figma: passo a passo" rank_math_description: Aprenda como construir um Design System no Figma com Variables, componentes, Auto Layout, libraries, documentação e governança passo a passo. rank_math_focus_keyword: Design System no Figma,Figma,Variables,Auto Layout featured_image: /wp-content/uploads/2026/04/Design-system-no-Figma-com-componentes-e-layout.webp featured_image_alt: Ilustração isométrica minimalista de interface modular com componentes e layout flexível em tons de roxo author: Lucas Camara timestamp: 2026-08-18T01:02:48Z tags: - Design Systems --- 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](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/post/design-systems-figma.md). Para uma visão mais ampla sobre conceito, componentes e governança, consulte também o [guia completo de Design System](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/post/design-system-guia-escalabilidade-roi.md). Tutorial oficial da Figma sobre a construção de um 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. [![Exemplo oficial da Figma mostrando um arquivo dedicado ao Design System](https://help.figma.com/hc/article_attachments/14798380498839) ](https://help.figma.com/hc/en-us/articles/14548865734679-Lesson-3-Build-your-design-system)Exemplo do curso oficial da Figma com um arquivo dedicado ao Design System. Fonte: Figma.## 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/900 ``` E uma camada semântica poderia utilizar: ``` color/background/default color/background/brand color/text/default color/text/subtle color/action/primary color/action/primary-hover ``` A 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](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/post/design-tokens-arquitetura-w3c.md). ## 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/large ``` Os nomes são apenas exemplos. A escala deve refletir as necessidades observadas no produto. [![Painel de Variables do Figma mostrando grupos e modos Light e Dark](https://help.figma.com/hc/article_attachments/26964398862615) ](https://help.figma.com/hc/en-us/articles/15145852043927-Create-and-manage-variables-and-collections)Variables podem ser organizadas em collections, grupos e modes. Fonte: Figma.### 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/0 ``` Se 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](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/post/figma-variables.md) 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/default ``` pode 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](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/post/como-criar-paleta-cores-design-system.md). ## 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. [![Painel atual de Auto Layout do Figma aplicado a uma interface mobile](https://help.figma.com/hc/article_attachments/31937315078679) ](https://help.figma.com/hc/en-us/articles/5731482952599-Toggle-on-auto-layout-in-designs)Auto Layout organiza relações de fluxo, alinhamento, gap, padding e redimensionamento. Fonte: Figma.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/12 ``` Os 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: ``` Button ``` Evite 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 Large ``` Isso 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](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/post/documentar-design-system-site-existente.md). ## 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](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/post/acessibilidade-design-systems-inclusao-wcag.md) e o guia específico sobre [acessibilidade cromática](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/post/acessibilidade-cores-design-system.md). ## 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: 1. abra a área de Assets; 2. acesse Libraries; 3. localize o arquivo atual; 4. selecione **Publish**; 5. revise quais assets serão incluídos; 6. escreva uma descrição clara sobre a publicação; 7. 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: 1. altere uma propriedade do Main Component; 2. publique a atualização; 3. abra um arquivo consumidor; 4. revise a notificação de atualização; 5. aceite a mudança; 6. 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](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/post/design-system-brasileiros-estrategia-negocio-guia.md) 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**](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/post/design-systems-figma.md). Para explorar todo o cluster, acesse também a [**biblioteca de Design Systems da CamaraUX**](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/category/design-systems.md). ## Referências - [Figma — Lesson 3: Build your design system](https://help.figma.com/hc/en-us/articles/14548865734679-Lesson-3-Build-your-design-system) - [Figma — Create and manage Variables and Collections](https://help.figma.com/hc/en-us/articles/15145852043927-Create-and-manage-variables-and-collections) - [Figma — Variables, Collections e Modes](https://help.figma.com/hc/pt-br/articles/14506821864087-Vis%C3%A3o-geral-de-vari%C3%A1veis-cole%C3%A7%C3%B5es-e-modos) - [Figma — Auto Layout](https://help.figma.com/hc/en-us/articles/5731482952599-Toggle-on-auto-layout-in-designs) - [Figma — Component Properties](https://help.figma.com/hc/en-us/articles/5579474826519-Explore-component-properties) - [Figma — Slots](https://help.figma.com/hc/en-us/articles/38231200344599-Use-slots-to-build-flexible-components-in-Figma) - [Figma — Publicar uma library](https://help.figma.com/hc/pt-br/articles/360025508373-Publicar-uma-biblioteca) - [Figma — Variables no Dev Mode](https://help.figma.com/hc/pt-br/articles/27882809912471-Vari%C3%A1veis-no-Dev-Mode) ## Topics **Categorias:** [Design Systems](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/category/design-systems.md)