Design system: biblioteca no Figma e componentes em código

Quando uma equipe precisa de um design system?#

Uma equipe precisa de um design system quando pessoas diferentes tomam sempre as mesmas decisões de interface e os resultados deixam de combinar. Sinais típicos: um segundo produto ou site que compartilha a marca, vários designers ou desenvolvedores front-end trabalhando a partir de uma mesma biblioteca do Figma, um rebranding que precisa chegar a todas as telas e tickets de QA sobre botões e formulários que mudam de uma página para outra.

Já vimos isso no nosso próprio site. Um inventário das nossas folhas de estilo, feito em setembro de 2026, encontrou 185 cores hexadecimais diferentes escritas à mão e 144 declarações de tamanho de fonte diferentes em 28 arquivos CSS. Parte pertence a ilustrações e protótipos; o restante está sendo separado em tokens, exceções com nome e código morto.

Um único site institucional com um só designer raramente precisa de um sistema: os componentes reutilizáveis que acompanham o web design personalizado são suficientes. Se o produto ainda está descobrindo seu fluxo principal, comece pelo design de produto e transforme em sistema, mais adiante, os padrões que sobreviverem.

O que um projeto de design system inclui#

Um projeto de design system entrega as mesmas decisões no Figma e no código, além da documentação e do processo que as mantêm alinhadas. A proposta informa quais desses itens entram no escopo e como cada um é aprovado. Para começar, precisamos de acesso de visualização aos seus arquivos do Figma e aos repositórios de código, e de uma pessoa do seu lado que aprove as decisões.

• Uma auditoria das telas e do código existentes: cores, tipografia, espaçamento e componentes
• Design tokens de cor, tipografia, espaçamento, raio e movimento, gerados para Figma e CSS
• Uma biblioteca do Figma publicada, com variantes, propriedades e todos os estados interativos
• Componentes em código com React ou Astro, cujas props correspondem às propriedades do Figma
• Documentação com regras de uso e notas de acessibilidade para cada componente
• Um processo de contribuição e de lançamento de versões, com versionamento e changelog
• Uma linha de base de adoção medida no Figma e no código

Kit inicial ou sistema completo: qual deve ser o tamanho?#

Comece pelos componentes que sua equipe constrói toda semana, não por um catálogo completo. Um kit inicial cobre as fundações e os componentes presentes na maioria das telas; um sistema completo acrescenta temas, plataformas, componentes complexos e governança. Entregamos o kit como primeira versão e o expandimos a partir de pedidos reais.

Tokens e variáveis do Figma: uma única fonte para design e código#

Design tokens são decisões com nome, como action-primary ou space-4, guardadas uma só vez e usadas tanto pelo Figma quanto pelo código. Organizamos os tokens em camadas: primeiro os valores brutos e depois nomes semânticos que dizem para que serve cada valor, de modo que mudar a cor de uma marca significa editar um valor em vez de procurá-lo em vários arquivos.

No Figma, os tokens viram variáveis. Em outubro de 2026, o Figma oferece seis tipos de variável (cor, número, texto, booleano, tempo e curva de animação), até 5.000 variáveis por coleção e modos para alternativas como claro e escuro ou uma segunda marca: até 10 modos por coleção no Professional, 20 no Organization e sem limite no Enterprise por meio de coleções estendidas.

No código, a fonte é um JSON no seu repositório, que gera propriedades personalizadas de CSS. O Design Tokens Community Group publicou a primeira versão estável do seu formato de arquivo, 2025.10, em 28 de outubro de 2025; é um relatório de um grupo comunitário, não um padrão do W3C, e o seguimos sempre que suas ferramentas conseguem lê-lo. No dardo.studio, as cores da marca e as receitas tipográficas são arquivos JSON que geram as variáveis CSS do site, e os arquivos gerados nunca são editados à mão.

Componentes em código que correspondem à biblioteca do Figma#

Um componente só é compartilhado quando suas versões no Figma e no código têm o mesmo nome, as mesmas propriedades e os mesmos estados. Projetamos e construímos cada um em conjunto, então uma variante no Figma é uma prop no código. React combina com produtos que exigem login, como os que construímos em desenvolvimento de aplicativos web; Astro combina com os sites de conteúdo e de marketing que construímos no nosso serviço de desenvolvimento web.

Os desenvolvedores inspecionam os designs no Dev Mode do Figma, que exige um assento Full ou Dev em um plano Professional ou superior; com o Code Connect configurado, o Dev Mode mostra o código real dos seus componentes em vez de trechos gerados. Os componentes em React ganham stories do Storybook para cada estado; os componentes em Astro ganham uma página de amostra dentro do projeto, como o nosso próprio sistema é documentado.

Acessibilidade embutida em cada componente#

A acessibilidade corrigida em um componente fica corrigida em todas as telas que o usam. Vários critérios de sucesso da WCAG 2.2 são decididos no nível do componente:

• Contraste de texto de pelo menos 4,5:1 (3:1 para texto grande) e 3:1 para as partes visuais dos controles (1.4.3, 1.4.11)
• Um indicador de foco visível que cabeçalhos fixos e sobreposições não cubram por completo (2.4.7, 2.4.11)
• Áreas de clique de pelo menos 24 por 24 pixels CSS, ou espaço suficiente ao redor (2.5.8)
• Campos de formulário cujos rótulos, instruções e erros cheguem aos leitores de tela

Verificamos o contraste nos pares de tokens antes que cheguem a um componente e testamos cada componente com teclado e com leitor de tela. O complemento de acessibilidade do Storybook executa o axe-core em cada story, e a documentação do Storybook diz que ele detecta até 57% dos problemas de WCAG; portanto, a automação é uma primeira triagem, não o veredicto.

O nosso próprio sistema exige que todo padrão interativo defina os estados hover, foco, ativo e desabilitado, áreas de toque de 44 pixels quando o design permite, movimento reduzido e texto em inglês e espanhol. Para descobrir primeiro onde a sua interface atual falha, comece por uma auditoria de acessibilidade, a partir de USD 690.

Governança e adoção: como um sistema continua em uso#

Um design system só continua útil se alguém for responsável por ele e houver uma forma clara de alterá-lo. Antes da entrega, combinamos quem será o responsável do seu lado, como as equipes pedem um componente ou uma variante, quem o revisa em design, código e acessibilidade e como as versões são numeradas. As exceções têm nome: um valor pontual para uma campanha fica junto desse trabalho e não vira padrão sem ninguém perceber.

A adoção é medida no Figma e no código. As análises de biblioteca do Figma, nos planos Organization e Enterprise, contam inserções, desvinculações e instâncias de cada componente, estilo e variável, com até um ano de histórico. Um componente muito desvinculado ainda não atende a uma necessidade real e sobe na lista de mudanças. No código, contamos as importações de componentes do sistema em comparação com cópias locais e valores escritos à mão.

Depois de uma atualização de marca, os tokens levam a maior parte da implantação: os novos valores chegam a todos os componentes que os usam, e as mesmas contagens mostram quais telas ainda precisam de trabalho manual.

O que faz o custo variar e de quem é o sistema#

O preço acompanha o número de componentes e variantes, as plataformas para as quais são entregues, o número de marcas ou temas e quanta interface existente precisa migrar para o sistema. Nosso formulário de contato pergunta uma faixa de orçamento, de menos de USD 5.000 a mais de USD 60.000, e a proposta ajusta o escopo a ela; os preços iniciais dos outros serviços estão na nossa página de preços.

O resultado é seu: a biblioteca do Figma fica no workspace da sua organização, os tokens e componentes no seu repositório, e qualquer pacote é publicado em seu nome, com a nossa equipe como membros convidados. As licenças das fontes devem cobrir uso web e em apps antes de uma tipografia entrar no sistema. A Dardo é uma equipe de três pessoas, liderada pelo fundador, em Bogotá, em UTC−5 o ano todo. Se você precisa de uma equipe que opere um sistema em dezenas de produtos por anos, uma equipe interna é a melhor responsável a longo prazo; nós podemos construir as fundações que ela vai assumir.

Dúvidas antes de escolher#