Como construir um design system: guia completo, do zero à escala

Um design system é o conjunto de decisões, componentes, padrões e documentação que faz um produto digital parecer um só, em qualquer tela, com qualquer pessoa do time construindo. Neste guia completo você vai entender o que é um design system, quando vale a pena criar um, e como construir um design system do zero: dos design tokens à biblioteca de componentes, da documentação à governança que mantém tudo vivo depois do lançamento.

É o mesmo processo que usamos na XPR Studio para criar interfaces de sites, aplicativos, SaaS e sistemas internos. Sem teoria solta: cada etapa vem com o que fazer, o que evitar e como medir se está funcionando.

O que é um design system

Design system não é um arquivo no Figma, nem um kit de UI, nem uma pasta de componentes em React. É um sistema de design no sentido literal: uma linguagem compartilhada entre design, desenvolvimento front-end e produto, com regras claras sobre como a interface se comporta.

Na prática, um design system maduro tem quatro camadas:

• Fundamentos (foundations): cor, tipografia, espaçamento, grid, bordas, sombras, ícones e movimento.
• Design tokens: os fundamentos traduzidos em variáveis nomeadas, que o Figma e o código leem da mesma fonte.
• Componentes de interface: botões, campos de formulário, modais, menus, cards, tabelas, cada um com variantes, estados e regras de uso.
• Padrões e documentação: como combinar componentes em fluxos reais (login, checkout, filtros, onboarding) e por quê.

Design system, style guide e UI kit: qual a diferença

Um style guide (guia de estilo) descreve a identidade visual: logo, paleta, fontes. Um UI kit é uma coleção de elementos visuais prontos para desenhar telas. Um design system engloba os dois e soma o que falta para escalar: componentes implementados em código, tokens versionados, documentação viva, critérios de acessibilidade e um processo de contribuição. Style guide mostra como a marca parece; design system garante que o produto inteiro se comporte como ela.

Por que criar um design system

Todo produto digital acumula decisões de interface. Sem um sistema, cada tela nova reabre as mesmas perguntas: qual azul, qual raio de borda, qual espaçamento, como é o estado de erro. O resultado aparece rápido: inconsistência visual, retrabalho, componentes duplicados e uma experiência do usuário (UX) que muda de página para página.

Os ganhos de um design system bem construído são concretos:

• Velocidade de entrega: o time monta telas com peças prontas e testadas, em vez de redesenhar e recodificar do zero.
• Consistência de marca e de UX: o usuário aprende a interface uma vez e reconhece o padrão em todo lugar.
• Escalabilidade: novos produtos, novas squads e novos desenvolvedores entram falando a mesma língua.
• Acessibilidade por padrão: contraste, foco visível e navegação por teclado são resolvidos uma vez, no componente, e herdados por todas as telas.
• Menos dívida técnica: um botão com dez versões espalhadas vira um componente único, com uma API clara.
• Handoff design-dev sem atrito: o nome no Figma é o nome no código.

Quando ainda não é hora

Um MVP com três telas não precisa de um design system completo. Precisa de fundamentos bem definidos e de disciplina para reaproveitar. O sistema começa a se pagar quando o produto tem várias telas, mais de uma pessoa desenhando ou desenvolvendo, ou mais de um produto compartilhando a mesma marca. A boa notícia: as primeiras etapas abaixo já valem para qualquer tamanho de projeto.

Como construir um design system em 8 etapas

1. Faça um inventário da interface (UI audit)

Antes de criar, levante o que já existe. Tire prints de todas as telas do produto e agrupe por tipo: todos os botões juntos, todos os campos, todos os títulos, todas as cores usadas. Esse inventário de interface expõe o tamanho do problema: é comum encontrar dezenas de tons de cinza, vários tamanhos de fonte quase iguais e botões que fazem a mesma coisa com estilos diferentes.

O inventário vira a lista de prioridades: o que mais se repete, e mais varia, entra primeiro no sistema.

2. Defina princípios de design

Princípios de design são três a cinco frases que ajudam o time a decidir quando a regra não cobre o caso. "Clareza antes de estética", "um objetivo por tela", "acessível para todos desde o primeiro componente". Bons princípios são específicos o bastante para eliminar opções; princípios genéricos como "ser moderno" não ajudam ninguém a decidir nada.

3. Crie os fundamentos visuais

Os fundamentos são a base de tudo o que vem depois:

• Paleta de cores: uma cor de marca, uma escala de neutros e cores semânticas (sucesso, alerta, erro, informação), cada uma com variações de contraste testadas para WCAG.
• Tipografia: uma escala tipográfica com poucos tamanhos bem definidos (display, títulos, corpo, legenda), altura de linha e peso para cada um.
• Espaçamento e grid: uma escala baseada em múltiplos de 4 ou 8 pixels e um grid responsivo para mobile, tablet e desktop.
• Forma e profundidade: raios de borda, espessura de traço e níveis de sombra (elevation).
• Iconografia e movimento: um estilo de ícone, um tamanho padrão e as curvas e durações das animações.

4. Transforme fundamentos em design tokens

Design tokens são os fundamentos com nome e valor, guardados num formato que ferramentas e código entendem (geralmente JSON). Eles são o elo entre o design e o desenvolvimento: mude um token e a mudança chega ao Figma, ao CSS, ao app iOS e ao Android.

Organize os tokens em dois níveis:

• Tokens primitivos (globais): os valores brutos, como blue-600: #000DFF ou space-4: 16px.
• Tokens semânticos (de alias): o papel de cada valor, como color-primary, color-text-muted ou color-feedback-error, que apontam para os primitivos.

Os componentes usam só os tokens semânticos. É isso que permite trocar de tema, criar um dark mode ou fazer white label sem reescrever um componente sequer. No código, os tokens viram CSS custom properties, variáveis do Tailwind CSS ou constantes em TypeScript; no Figma, viram Variables com modos claro e escuro.

5. Construa a biblioteca de componentes

Comece pelos componentes mais usados e mais simples, os componentes atômicos: botão, link, input, checkbox, radio, select, badge, avatar. Depois suba para os compostos: card, modal, toast, tabs, accordion, dropdown, tabela. A lógica do Atomic Design (átomos, moléculas, organismos) ajuda a pensar a ordem, mesmo que você não use os nomes.

Para cada componente, defina:

• Anatomia: as partes que o compõem (ícone, rótulo, contêiner).
• Variantes: primário, secundário, ghost, destrutivo; tamanhos pequeno, médio e grande.
• Estados: padrão, hover, foco, ativo, desabilitado, carregando, erro.
• Comportamento responsivo: o que muda no mobile.
• API: as props do componente no código, com os mesmos nomes das propriedades no Figma.

No Figma, use componentes com variantes, auto layout e component properties. No código, implemente em React, Vue, Angular, Svelte, Astro ou Web Components, conforme a stack do produto. O que importa é que o componente do Figma e o do código sejam o mesmo componente, com os mesmos nomes, variantes e estados.

6. Garanta acessibilidade em cada componente

Acessibilidade digital não é etapa final, é critério de aceite. Cada componente do design system deve cumprir, no mínimo, as diretrizes WCAG 2.2 nível AA:

• Contraste mínimo de 4,5:1 para texto e 3:1 para elementos de interface.
• Foco visível e navegação completa por teclado.
• Semântica HTML correta e atributos ARIA só onde o HTML não resolve.
• Áreas de toque de pelo menos 44 por 44 pixels no mobile.
• Mensagens de erro em texto, não só em cor.

Resolvida no componente, a acessibilidade se espalha sozinha pelo produto inteiro. É uma das maiores vantagens de ter um sistema.

7. Documente como um produto

Componente sem documentação é componente que ninguém usa direito. A documentação do design system precisa responder, para cada peça: o que é, quando usar, quando não usar, quais variantes existem, exemplos de código e boas práticas de conteúdo (UX writing).

Ferramentas como Storybook, Zeroheight e Supernova ajudam a manter a documentação viva, com os componentes reais rodando ao lado do texto. No Storybook, cada componente ganha uma story por estado, o que também serve de base para testes visuais de regressão.

8. Versione, publique e governe

Aqui está o motivo pelo qual a maioria dos design systems morre no segundo ano: ninguém cuida deles depois do lançamento. Trate o design system como produto interno, com dono, roadmap e clientes (os times que o usam).

• Versionamento semântico: publique a biblioteca como pacote (npm, por exemplo) com versões major, minor e patch e um changelog claro.
• Modelo de governança: defina quem aprova mudanças. Pode ser um time dedicado (centralizado), contribuições de todas as squads com revisão (federado) ou um meio-termo.
• Processo de contribuição: um caminho simples para propor um componente novo ou uma variante, com critérios de entrada.
• Depreciação: avise antes de remover, ofereça o substituto e dê prazo para a migração.

Consistência é consequência de processo, não de biblioteca. O design system que sobrevive é o que tem dono.

Ferramentas para criar um design system

Não existe stack obrigatória, mas algumas combinações se repetem nos projetos que funcionam:

• Design: Figma, com Variables para os tokens, bibliotecas publicadas e Dev Mode para o handoff.
• Tokens: Tokens Studio e Style Dictionary para exportar os tokens do Figma para CSS, iOS e Android.
• Código: React, Vue ou Astro, com Tailwind CSS ou CSS Modules, e TypeScript para tipar a API de cada componente.
• Documentação e testes: Storybook, Chromatic para regressão visual e testes automatizados de acessibilidade com axe.
• Referências: Material Design (Google), Carbon (IBM), Polaris (Shopify), Atlassian Design System e Primer (GitHub) são ótimos para estudar decisões, não para copiar.

Erros comuns ao construir um design system

• Começar pelos componentes, sem fundamentos. Sem tokens, cada componente inventa seus próprios valores, e a inconsistência volta pela porta dos fundos.
• Desenhar tudo antes de implementar algo. Um design system que existe só no Figma não muda o produto. Entregue em ciclos curtos: fundamento, componente, uso real.
• Copiar o design system de uma big tech. O Material Design resolve os problemas do Google. O seu produto tem outros.
• Componentes genéricos demais. Um componente com 40 props tenta servir a todos e não serve a ninguém. Prefira componentes menores e composição.
• Não medir adoção. Sem saber quantas telas usam o sistema, é impossível saber se ele está funcionando.

Como medir o sucesso de um design system

Um design system é investimento, e investimento precisa de indicador. As métricas mais úteis:

• Taxa de adoção: porcentagem de telas e de código que usam componentes do sistema.
• Tempo de entrega: quanto tempo leva para desenhar e implementar uma tela nova, antes e depois.
• Componentes duplicados: quantos componentes paralelos ainda existem fora do sistema.
• Bugs de interface: volume de problemas visuais e de acessibilidade em produção.
• Satisfação do time: pesquisa periódica com designers e desenvolvedores que usam o sistema.

Perguntas frequentes sobre design system

Quanto tempo leva para criar um design system?

Os fundamentos e os primeiros componentes ficam prontos em poucas semanas. Um sistema completo, com documentação e governança, amadurece ao longo de meses, junto com o produto. O segredo é começar pequeno e entregar valor desde a primeira versão.

Design system é só para empresas grandes?

Não. Startups e pequenas empresas também se beneficiam, principalmente na fase de crescimento. A diferença é o tamanho: um time pequeno precisa de um sistema enxuto, com tokens e poucos componentes bem feitos.

Qual a diferença entre design system e biblioteca de componentes?

A biblioteca de componentes é uma parte do design system. O sistema inclui também os princípios, os tokens, a documentação, os padrões de uso e o processo de governança que mantém tudo coerente.

Preciso de um design system no Figma e no código?

Sim. O valor do design system está justamente na ponte entre os dois. Um sistema só no Figma melhora o design, mas não muda o produto; um sistema só no código perde a referência visual. Os dois lados precisam ler os mesmos tokens e usar os mesmos nomes.

Conclusão: design system é produto, não projeto

Construir um design system é organizar decisões para que o time pare de tomá-las de novo a cada tela. Comece pelo inventário, defina fundamentos, traduza tudo em tokens, construa componentes acessíveis, documente e, principalmente, dê um dono ao sistema. É esse cuidado contínuo que transforma uma biblioteca de componentes num ativo que acelera o produto por anos.

Na XPR Studio, criamos design systems, interfaces e produtos digitais da estratégia ao código em produção. Se o seu produto está crescendo mais rápido que a consistência dele, fale com a gente.