Variants e propriedades de componentes são recursos do Figma que permitem concentrar, em um único “componente mestre”, múltiplos estados e opções de um mesmo elemento de UI. Em vez de duplicar componentes para cada variação (ex.: botão primário, secundário, com ícone, sem ícone, desabilitado, carregando), você organiza tudo em um conjunto de variantes e expõe controles claros para quem vai usar. O resultado é menos duplicação, menos inconsistência e um handoff mais previsível, porque as opções ficam explícitas e limitadas ao que o Design System realmente suporta.
O que são Variants e por que elas reduzem duplicação
No Figma, um componente pode ter “variantes” agrupadas em um Component Set. Cada variante representa uma combinação de propriedades (por exemplo: Type=Primary, State=Default). Quando você cria instâncias desse componente em telas, pode alternar as propriedades no painel direito, sem trocar manualmente o componente por outro nome parecido ou procurar versões duplicadas na biblioteca.
Sem variants, é comum cair em padrões problemáticos: criar um componente por estado (Button/Primary, Button/Primary/Hover, Button/Primary/Disabled), depois outro por tamanho, depois outro por presença de ícone. Isso explode em dezenas de componentes quase idênticos, aumenta o custo de manutenção (qualquer ajuste precisa ser replicado) e gera “drift” visual (pequenas diferenças não intencionais).
Com variants, você mantém uma base única e define propriedades que descrevem as diferenças permitidas. A duplicação cai porque a estrutura é compartilhada. A clareza aumenta porque o usuário do componente escolhe opções por propriedades, em vez de “caçar” o componente certo.
O que são propriedades de componentes (Component Properties)
Propriedades de componentes são controles que você expõe para quem usa uma instância. Elas podem representar: alternância de visibilidade, troca de ícones, troca de texto, seleção de instâncias internas, ou até valores (em alguns casos). Na prática, elas transformam o componente em um “formulário” de configuração: o designer escolhe o que precisa sem quebrar a estrutura.
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
As propriedades mais comuns para reduzir duplicação e aumentar clareza são:
- Variant properties: as propriedades que definem as variantes (ex.: Size, Type, State).
- Boolean properties: liga/desliga (ex.: Has icon, Show badge).
- Instance swap properties: permite trocar um ícone ou subcomponente por outro (ex.: escolher qual ícone aparece).
- Text properties: expõe o texto de um label sem precisar entrar no componente.
O ponto central: variants organizam “famílias” de estados/opções; propriedades expõem controles para customização segura. Juntas, elas evitam que cada pequena variação vire um novo componente independente.
Modelando variações: como decidir o que vira Variant e o que vira Property
Uma decisão que impacta diretamente a clareza é separar o que é “variação estrutural” do que é “configuração pontual”. Use este guia prático:
- Vira Variant quando altera layout, espaçamentos, estilos principais ou comportamento esperado do componente (ex.: tamanho do botão, tipo/ênuance, estado de interação).
- Vira Property quando é uma opção que não muda a identidade do componente, apenas ativa/desativa partes ou troca conteúdos (ex.: mostrar ícone, escolher ícone, texto do label).
- Evite Variant para conteúdo livre (ex.: texto do botão). Para isso, use Text property.
- Evite Property para estados que precisam ser consistentes e rastreáveis (ex.: Disabled). Estados geralmente devem ser Variant para não permitir combinações inválidas.
Um exemplo típico: “Botão com ícone” pode ser tratado como Variant (Icon=On/Off) ou como Boolean property. Em geral, se a presença do ícone muda o padding e o alinhamento, ainda assim pode ser Boolean, desde que o componente esteja preparado para isso com Auto Layout. Porém, se o design exige regras muito diferentes (ex.: botão só-ícone, botão com ícone à direita, botão com dois ícones), pode ser melhor modelar como Variant para evitar combinações confusas.
Passo a passo prático: construindo um Button com Variants e propriedades
O objetivo deste passo a passo é criar um botão que cubra variações comuns sem multiplicar componentes. Vamos considerar: tipos (Primary, Secondary), tamanhos (S, M, L), estados (Default, Hover, Pressed, Disabled, Loading) e opções (ícone opcional, ícone à esquerda/direita, texto editável).
1) Defina o “contrato” do componente (o que ele permite)
Antes de montar variantes, liste as propriedades que serão expostas e as combinações válidas. Exemplo de contrato:
- Type: Primary | Secondary
- Size: S | M | L
- State: Default | Hover | Pressed | Disabled | Loading
- Icon: None | Left | Right
- Label: texto livre
- Leading icon: swap de ícone (quando Icon=Left)
- Trailing icon: swap de ícone (quando Icon=Right)
Esse contrato ajuda a evitar o erro comum de criar propriedades demais sem necessidade. Também força você a pensar em combinações inválidas, como “Loading + Icon=Right” (você pode decidir se permite ou se Loading sempre substitui o ícone).
2) Crie a estrutura base do botão (uma variante inicial)
Crie um frame do botão com Auto Layout horizontal, contendo: ícone (opcional), label e ícone (opcional). Mesmo que comece com ícone desligado, deixe os “slots” preparados para serem ativados. Estruture assim:
- Container (Auto Layout horizontal, alinhamento vertical central, spacing entre itens)
- IconLeft (frame/ícone)
- Label (texto)
- IconRight (frame/ícone)
Configure o container para ter padding consistente e altura controlada por Size. O label deve ter comportamento previsível (por exemplo, não quebrar linha). Se o botão puder crescer, defina o container com “Hug contents” ou “Fill container” conforme o padrão do seu sistema.
3) Transforme em componente e crie o Component Set
Selecione o botão e crie um componente. Em seguida, crie variantes duplicando esse componente para representar as combinações essenciais. No Figma, ao selecionar múltiplos componentes e escolher “Combine as variants”, você cria um Component Set com propriedades.
Uma abordagem prática é começar com poucas dimensões e expandir:
- Primeiro: Type (Primary/Secondary) + State (Default/Disabled)
- Depois: adicionar Size
- Por fim: adicionar Loading e variações de ícone
Isso evita criar 2 x 3 x 5 x 3 = 90 variantes de uma vez sem validar se o modelo está bom.
4) Crie propriedades de Variant: Type, Size e State
Ao combinar variantes, o Figma cria propriedades automaticamente com base nos nomes. Ajuste para que fiquem claras e consistentes:
- Type: Primary, Secondary
- Size: S, M, L
- State: Default, Hover, Pressed, Disabled, Loading
Garanta que cada variante realmente reflita o estado. Exemplo: Disabled deve ajustar opacidade/cores e também desabilitar affordances visuais (como sombra ou destaque). Loading deve prever o conteúdo: você pode substituir o label por “Loading…” ou manter o label e mostrar um spinner, mas isso precisa ser consistente.
5) Exponha o texto como Text property
Selecione o texto do label dentro do componente e crie uma propriedade de texto. Assim, em instâncias, o designer altera o texto sem entrar no componente. Isso reduz duplicação porque evita criar “Button/Primary/Save”, “Button/Primary/Continue” etc.
Boas práticas:
- Nomeie a propriedade como “Label” (simples e direto).
- Defina um valor padrão curto (ex.: “Button”).
- Se o botão não deve aceitar múltiplas linhas, configure o texto para não quebrar e ajuste o comportamento de resizing.
6) Modele ícones como propriedades (Boolean + Instance swap)
Há duas formas comuns:
- Opção A (recomendada para clareza): criar uma Variant property “Icon” com valores None/Left/Right. Isso evita combinações inválidas (ex.: dois ícones ao mesmo tempo, se não suportado).
- Opção B: usar duas Boolean properties (Show left icon / Show right icon). É mais flexível, mas pode permitir combinações que o sistema não quer.
Para reduzir ambiguidade, use a Opção A quando o Design System tem regras rígidas. Depois, para escolher qual ícone aparece, use Instance swap property no layer do ícone. Assim, o usuário troca o ícone sem desanexar ou colar SVG manualmente.
Passos:
- Crie a propriedade Variant “Icon” com None/Left/Right.
- Na variante Icon=None, deixe IconLeft e IconRight ocultos.
- Na variante Icon=Left, mostre IconLeft e oculte IconRight.
- Na variante Icon=Right, mostre IconRight e oculte IconLeft.
- Selecione o layer do ícone (por exemplo, IconLeft) e crie uma Instance swap property “Leading icon”. Repita para IconRight com “Trailing icon”.
Isso aumenta clareza no uso: o designer escolhe “Icon=Left” e então escolhe o ícone no campo “Leading icon”.
7) Trate Loading sem criar componentes paralelos
Loading costuma gerar duplicação porque muitos times criam um “Button/Loading” separado. Com variants, Loading vira apenas um valor de State. O segredo é definir o que acontece com o conteúdo:
- Se Loading substitui o label: na variante State=Loading, esconda o Label e mostre um Spinner centralizado.
- Se Loading mantém o label: mostre Spinner + Label, e defina regra de espaçamento.
Para manter clareza, evite permitir que o usuário “monte” um loading improvisado. Se Loading é um estado oficial, ele deve ser uma variante oficial. Se o spinner for um subcomponente, use-o dentro do botão e controle sua visibilidade por variante.
8) Evite explosão de variantes com composição inteligente
Mesmo com um bom contrato, a combinação de Type x Size x State x Icon pode crescer rápido. Algumas estratégias para reduzir o número de variantes sem perder clareza:
- Use propriedades para o que é opcional (texto, ícone, badge), e variantes para o que é essencial (tipo, tamanho, estado).
- Evite criar variantes para conteúdo (ex.: “With long label”). Em vez disso, defina regras de truncamento, min/max width e comportamento de resizing.
- Separe componentes quando o comportamento muda de categoria: por exemplo, “Icon button” (botão só-ícone) pode ser um componente diferente de “Button” com label, porque muda semântica e layout.
Passo a passo prático: usando propriedades para reduzir duplicação em um Input
Inputs frequentemente viram um cemitério de duplicatas: com label, sem label, com helper text, com erro, com ícone, com prefixo, com sufixo. Variants e propriedades ajudam a organizar isso.
1) Defina dimensões essenciais como Variant
Para um input, dimensões essenciais geralmente são:
- State: Default | Focus | Error | Disabled
- Size: S | M | L (se aplicável)
Esses estados mudam borda, cor, e às vezes a presença de mensagens. Como são estados oficiais, mantenha como Variant para evitar que alguém “simule” erro mudando cor manualmente.
2) Exponha partes opcionais como Boolean properties
Partes opcionais típicas:
- Show label
- Show helper text
- Show leading icon
- Show trailing icon
Quando essas partes são opcionais e não alteram a categoria do componente, Boolean properties funcionam bem. Elas reduzem duplicação porque você não precisa de “Input/With label”, “Input/No label”, etc.
3) Use Text properties para Label, Value, Helper e Error message
Exponha textos para edição rápida:
- Label
- Placeholder
- Helper text
- Error message
Uma regra útil: se o texto pode mudar de tela para tela, ele deve ser propriedade, não variante.
4) Use Instance swap para ícones e elementos de sufixo/prefixo
Leading/trailing icon podem ser instance swap. Para prefixo/sufixo (ex.: “R$”, “kg”, “.com”), você pode usar texto exposto como propriedade ou um slot com instance swap para um pequeno componente (por exemplo, um chip/label). Isso mantém o input flexível sem criar dezenas de versões.
Clareza para quem usa: como desenhar propriedades “à prova de erro”
Reduzir duplicação não pode vir às custas de confusão. Um componente com 15 propriedades mal pensadas vira um painel de controle caótico. Algumas práticas para aumentar clareza:
Prefira propriedades com nomes orientados ao uso
Em vez de “Variant 1” ou “Style”, use nomes que descrevem decisão de design:
- Type (Primary/Secondary)
- State (Default/Disabled/Loading)
- Icon (None/Left/Right)
- Label (texto)
Evite nomes que misturam conceitos, como “PrimaryDisabledSmall”. Isso volta a ser duplicação disfarçada.
Limite combinações inválidas
Se uma combinação não deve existir no produto, não exponha como opção fácil. Exemplos:
- Se Loading sempre remove ícones, modele isso no próprio estado Loading (ocultando ícones).
- Se Disabled não deve ter Hover/Pressed, mantenha State como uma única propriedade (não crie booleans separadas para cada estado).
O objetivo é que o usuário não consiga “montar” algo que o sistema não suporta.
Use valores discretos em vez de múltiplos toggles
Quando há exclusividade (um ou outro), prefira uma propriedade com valores (None/Left/Right) em vez de dois toggles independentes. Isso aumenta clareza e reduz bugs de design.
Documente o comportamento no próprio componente (sem virar texto longo)
Sem criar uma seção de documentação extensa aqui, você pode embutir pistas de uso por meio de:
- Valores padrão sensatos (ex.: Type=Primary, State=Default).
- Propriedades agrupadas logicamente (primeiro Type/Size/State, depois conteúdo como Label e ícones).
- Componentes internos consistentes (ex.: spinner sempre com o mesmo tamanho relativo ao botão).
Padrões comuns de duplicação e como substituir por Variants/Properties
Duplicação por estado (hover/pressed/disabled)
Sintoma: vários componentes com o mesmo layout, mudando apenas cor/estilo. Solução: State como Variant property. Isso centraliza ajustes e garante que todos usem os mesmos estados.
Duplicação por conteúdo (textos diferentes)
Sintoma: “Button/Save”, “Button/Cancel”, “Button/Next”. Solução: Text property para o label. Se houver necessidade de textos longos, defina regras de truncamento e largura, em vez de criar variantes.
Duplicação por ícone (mesmo botão com ícones diferentes)
Sintoma: “Button/Search”, “Button/Download”, “Button/Edit”. Solução: Instance swap property para o ícone e uma propriedade (Variant ou Boolean) para presença/posição do ícone.
Duplicação por “versões” quase iguais
Sintoma: “Button v2”, “Button new”, “Button updated”. Solução: consolidar em um Component Set com propriedades claras e migrar instâncias para ele. Se mudanças forem incompatíveis, crie um componente novo com nome distinto e um plano de migração, mas evite manter múltiplas versões sem necessidade.
Checklist de qualidade: seu Component Set está claro e escalável?
- As propriedades descrevem decisões de design (Type, Size, State) e não detalhes internos?
- Textos variáveis estão como Text properties, não como variantes?
- Ícones são trocáveis via Instance swap, sem desanexar instâncias?
- Combinações inválidas foram evitadas (por modelagem de variantes ou por regras internas de visibilidade)?
- O número de variantes é o mínimo necessário para cobrir estados oficiais?
- Ao atualizar o componente mestre, todas as variações se mantêm consistentes?
Exemplo prático de matriz de variantes (para planejar antes de criar)
Planejar a matriz evita criar variantes demais ou esquecer estados importantes. Um exemplo de matriz para Button:
Properties (variants): Type, Size, State, IconPosition (se necessário) Text/Swap: Label, LeadingIcon, TrailingIcon Type: Primary | Secondary Size: S | M | L State: Default | Hover | Pressed | Disabled | Loading IconPosition: None | Left | Right Total teórico: 2 x 3 x 5 x 3 = 90 Otimização: IconPosition como property (None/Left/Right) pode continuar como variant, mas você pode reduzir criando apenas combinações necessárias e usando propriedades para conteúdo. Outra opção é separar “Button” e “IconButton” para reduzir a matriz.O ponto não é sempre chegar ao menor número possível, e sim chegar a um conjunto que seja fácil de usar e difícil de usar errado. Variants e propriedades existem para transformar o Design System em escolhas guiadas, reduzindo duplicação e aumentando clareza no dia a dia de design.
