
Como tornar um design system pronto para agentes de IA
Design systems podem ganhar importância à medida que agentes de IA passam a gerar interfaces e código funcional. Para que essas ferramentas produzam resultados coerentes com a identidade de um produto, não basta oferecer um arquivo visual ou uma lista de tokens: é preciso tornar explícitas as regras de estrutura, comportamento, composição e acessibilidade.
O problema do “quase certo”
Uma equipe de design que trabalha em vários produtos corporativos usa um design system compartilhado e experimenta acelerar a passagem do design para o software. Com Figma MCP, foi possível passar de um design a um frontend funcional em minutos. Porém, ao analisar os resultados, a equipe encontrou estados de hover incorretos, cores aplicadas a finalidades semânticas erradas, espaçamentos fora das diretrizes e hierarquia inconsistente entre ações primárias e secundárias. As interfaces não eram necessariamente ruins, mas não refletiam as convenções próprias do produto.
A equipe também não usa ferramentas como Figma Make para criar especificações visuais precisas de entrega. Elas são consideradas úteis para exploração e prototipagem de interações complexas, mas o handoff exige que estados, espaçamentos e comportamentos sejam intencionais. O problema central, portanto, não é fazer o agente gerar uma interface, e sim fornecer contexto suficiente para que ele a construa conforme o design system.
Do arquivo visual ao conhecimento estruturado
Um design system já reúne linguagem visual, componentes, padrões, comportamentos, critérios de acessibilidade e convenções. O obstáculo é que essa informação costuma ser organizada para consulta humana, em bibliotecas do Figma, Storybook ou sites de documentação. O acesso ao Figma ajuda a comunicar componentes, variantes, variáveis, espaçamentos, cores e composição, mas não descreve tudo o que o agente precisa saber sobre o que construir e como a interface deve funcionar.
O mesmo vale para tokens.json: ele fornece cores, tipografia, espaçamento, raios e outras propriedades visuais, mas não explica a finalidade de cada elemento nem as regras de interação. Um token não informa, por exemplo, que um Wizard é composto por barra superior, indicador de etapas, cabeçalho, área de conteúdo e barra inferior de ações; tampouco define onde ficam as ações, como ocorre a navegação ou quando o usuário pode avançar.
Authoring, especificação e entrega
A estrutura proposta separa o sistema em três camadas: Authoring, Specification e Delivery. O Figma permanece como espaço de criação e manutenção visual, organizado em fundamentos, componentes, padrões e templates. Em paralelo, uma camada de especificação estruturada em Markdown descreve as regras que agentes conseguem interpretar.
Nessa camada, tokens.json contém os fundamentos visuais; design.md, as regras globais e convenções; e components.md, patterns.md e templates.md funcionam como registros do que existe e de onde estão suas especificações. Arquivos individuais detalham cada componente, padrão ou template. Um arquivo de template para Wizard pode referenciar barra superior, cabeçalho, barra de ações, indicador de etapas e botões, além de registrar propósito, dependências, comportamento, ações e requisitos de acessibilidade. A divisão em arquivos permite que o agente recupere apenas o contexto relevante para cada tarefa, facilitando a manutenção e evitando o carregamento desnecessário de todo o sistema.
Na entrega, pacotes versionados de tokens, ícones, fontes, componentes e padrões continuam sendo consumidos pelas equipes de engenharia. Com acesso às especificações e ao código do produto, um agente poderia identificar desvios, sugerir componentes existentes e propor migrações. A mudança não seria enviada cegamente à produção: a proposta é que o agente abra uma pull request, enquanto engenheiros revisam, testam e aprovam a implementação. Permanece em aberto como manter as especificações sincronizadas com o Figma; a automação por IA é apontada como uma possibilidade futura.
Preservar o que torna o produto próprio
Se a IA tornar acessível a geração de interfaces razoavelmente boas, o design system poderá funcionar como um mecanismo para preservar aquilo que torna um produto reconhecível. Para isso, suas regras precisam deixar de ser apenas material de consulta humana e passar a ser conhecimento estruturado que agentes consigam entender e aplicar.