Ferramentas de Design que Ignoram a Camada de Restrição

Uma designer sênior abriu o Figma AI, pediu “um painel de configurações dentro do nosso produto” e recebeu de volta algo que parecia exatamente certo. Paleta dentro da marca. Espaçamento familiar. Botões que não envergonhariam ninguém em uma revisão de design. Era inutilizável. Nenhum dos componentes existia no design system. As sombras eram avulsas. O raio do botão estava três pixels maior. O “card” era um retângulo com borda, não o componente Card real do time, que carrega tokens de elevação, estados de foco e rótulos de acessibilidade que o retângulo da IA não carregava.

A limpeza levou mais tempo do que teria levado construir do zero. A designer ainda está se desculpando.

Esse é o modo de falha que Andrew Martin, CEO da UXPin, nomeou no fim de abril: “A violação de design system mais perigosa não é a que parece errada. É a que parece certa, mas não foi construída com os seus componentes.” Sam Henri Gold, em Thoughts and Feelings Around Claude Design, nomeia a razão estrutural: ferramentas de IA para design foram treinadas em código, não em primitivas do Figma. Elas alcançam o meio que de fato conhecem.

Os dois textos foram escritos de forma independente. Chegam na mesma conclusão. Design systems funcionam porque criam restrições, e ferramentas de IA — Claude Design, Figma AI, os geradores recentes do Sketch, Lovable, Bolt, v0 — operam fora dessas restrições por padrão. A pergunta não é mais se designers vão adotar essas ferramentas. Já adotaram. A pergunta é qual superfície de governança captura o output antes que ele entre em um pull request.

Três Falhas de Governança em Uma Única Chamada da Ferramenta

Martin cataloga os modos de falha sem rodeios. Leia-os como um único evento encadeado, não como três riscos independentes.

O output ignora a revisão. A designer faz o prompt; a IA produz uma tela. A tela não foi revisada contra as diretrizes do time porque a IA não sabe que as diretrizes existem. Não foi revisada contra requisitos de acessibilidade porque a IA não sabe quais padrões de aria-label o time usa. Não foi revisada contra a biblioteca de componentes porque a IA não consultou a biblioteca de componentes. O primeiro revisor é a designer olhando para o resultado e decidindo se vai mandar para produção. Isso não é processo de revisão. É gosto.

O output parece em conformidade. O artefato perigoso é o que parece profissional, soa dentro da marca e se lê como se tivesse vindo de dentro do sistema. Usa as cores da marca — perto o suficiente para que uma varredura rápida não acuse. Usa o espaçamento — perto o suficiente para que uma designer que não decorou a grade de oito pixels não note. Usa a escala tipográfica — perto o suficiente. O output não está agressivamente errado. Está plausivelmente certo. Plausivelmente certo é o modo de falha que sobrevive à revisão.

As restrições desaparecem. O propósito de um design system é tornar algumas escolhas impossíveis. Designers não conseguem usar um botão com um formato que não existe. Designers não conseguem usar uma sombra que o sistema não definiu. O sistema é uma camada de restrição, e a restrição é o que torna o sistema útil. Geradores de IA se sentam em cima dessa camada e produzem output em formato livre. A restrição vira opcional. Quando a restrição vira opcional, o sistema vira decoração.

Martin relata uma designer que “passou mais tempo corrigindo a interpretação que a IA fez do design system dela do que teria levado para construir do zero”. A frase que segue é a que precisa ser internalizada: “A IA foi rápida. A limpeza é lenta.”

A Razão pela Qual o Figma Saiu da Base de Treinamento

O ensaio de Sam Henri Gold nomeia um fato estrutural que a maioria das lideranças de design não absorveu. O formato de arquivo do Figma é “fechado, em larga medida não documentado, doloroso de trabalhar programaticamente”. Isso não é uma reclamação sobre ergonomia de API. É a razão pela qual o Figma não foi parte significativa das bases de treinamento de LLMs.

LLMs foram treinados em código. Repositórios públicos. Stack Overflow. Bibliotecas de componentes open source. Viram bilhões de declarações como <button className="primary">. Viram definições de componente, interfaces de props, arquivos de design tokens em JSON. Não viram frames do Figma. Não viram configurações de auto-layout. Não viram as centenas de horas de documentação de design system que vivem dentro de bibliotecas do Figma às quais o público não tem acesso. O corpus de treinamento tem um buraco exatamente onde as primitivas do design system deveriam estar.

Isso explica os sintomas. Ferramentas de IA para design produzem output que parece o instinto de uma designer porque o modelo subjacente está alcançando padrões de código vestidos de artefato visual. O Claude Design produz componentes escrevendo JSX ou HTML e renderizando. O Figma AI produz frames inferindo formas a partir de prompts que o modelo interpreta como se fossem código de UI. O meio de geração é código. O output é uma renderização desse código. O design system — que vive no Figma, no Storybook, no Notion interno do time, na cabeça de três designers sêniores — não faz parte do raciocínio do modelo.

Henri Gold estende o argumento. A fonte da verdade está migrando de volta para o código. Alguns times já trabalham diretamente em JSX com Tailwind porque a ferramenta de IA raciocina melhor ali. Algumas implantações de Figma hoje têm 946 variáveis de cor com aliasing aninhado — a complexidade virou a própria vulnerabilidade de governança, porque nenhuma ferramenta de IA consegue manter esse modelo mental preciso e raramente humanos conseguem. As ferramentas que produzem o output mais limpo são as que trabalham sobre as superfícies de restrição mais simples e nativas a código.

A Restrição É o Que Sobrevive

Os dois ensaios convergem para o mesmo princípio de governança. Disciplina de designer não sobrevive a tooling de IA. A camada de restrição sobrevive, mas só se a restrição for estrutural em vez de aspiracional.

Restrições aspiracionais são documentação. “Use o componente Card para conteúdo agrupado.” “Mantenha-se na grade de oito pixels.” “Use tokens da escala tipográfica, nunca tamanhos de fonte crus.” Funcionam enquanto o humano no teclado é quem está fazendo a escolha. Geradores de IA não estão lendo a documentação. Não estão consultando a página do design system no Notion. Estão gerando a partir de um modelo de código e vão produzir o que o prompt sugerir.

Restrições estruturais são diferentes. Tornam a violação impossível, não desencorajada. Um design system que expõe uma paleta de componentes obrigatória para a ferramenta de IA, em que o modelo só consegue posicionar componentes que existem na biblioteca, produz um output que está, por construção, dentro do sistema. Uma ferramenta de design que se recusa a renderizar um token indefinido devolve um retângulo em branco até que um token real seja fornecido. A designer não consegue mandar um componente fora do sistema porque a ferramenta não consegue gerar um.

Esse é o mesmo princípio de governança sobre o qual já escrevemos em imposição de design system e em design systems como infraestrutura de governança. O formato do princípio não muda entre política e tooling: a restrição, não a política, é o que segura. Argumentamos o caso mais amplo no ensaio sobre governança de design na era dos agentes. Os lançamentos de abril vindos da UXPin e as notas de prática de Henri Gold são a instância específica de ferramentas da mesma conclusão.

Como isso fica operacionalmente?

Geração restrita. A ferramenta de IA recebe acesso à biblioteca de componentes como o único conjunto legal de output. Cada geração é um posicionamento de um componente existente, com tokens existentes, em um layout que o sistema já suporta. O modelo pode se recusar a gerar; não consegue gerar algo que o sistema não permite.

Output ciente de tokens. A ferramenta ingere o JSON de design tokens e produz output ancorado nesses tokens, não em valores crus. Uma cor no output é color.background.primary, não #0F1B2D. Se o token não existe, a ferramenta expõe a lacuna para a designer em vez de inventar o valor.

Prompt centrado na biblioteca. O template de prompt inclui a biblioteca de componentes como contexto. “Construa um painel de configurações” vira “Construa um painel de configurações usando {Card, Section, Field, Toggle, Button} da biblioteca”. O modelo raciocina sobre composição, não sobre primitivas visuais.

Ganchos de revisão estrutural. O output, antes de chegar à revisão de uma designer, passa por um parser que confirma que todo componente usado está no sistema, todo token está no registro, todo atributo de acessibilidade está preenchido. A checagem é automatizada. Roda em toda geração. Falhas bloqueiam o artefato de sair da ferramenta.

Isso não é aspiracional. É arquitetural. Os times que entregam isso passam a ter ferramentas de IA que fortalecem o design system. Os times que não entregam acumulam, devagar, artefatos plausivelmente certos que nenhum revisor sinalizou porque cada um, isolado, parecia bem.

A Pergunta para Quem Lidera Design

Se você lidera uma organização de design, a pergunta não é se o seu time vai usar essas ferramentas. Vai. Já está usando. A pergunta é se a camada de restrição entre a ferramenta de IA e o design em produção é estrutural ou aspiracional.

Caminhe pelo trajeto que uma designer sênior faz hoje. Ela abre o Figma AI ou o Claude Design. Faz o prompt. Recebe um artefato. O que checa o artefato antes de ele entrar em uma revisão de design? Se a resposta for “o olho da designer”, a restrição é aspiracional. Se a resposta for “um parser automatizado que valida componentes, tokens e acessibilidade”, a restrição é estrutural.

Output plausivelmente certo é o modo de falha que o olho não pega. A frase de Andrew Martin é a frase para escrever na parede: a violação perigosa é a que parece certa, mas não foi construída com os seus componentes. A razão estrutural de Sam Henri Gold explica por que isso acontece por padrão e não por acidente. A correção é a camada de restrição que a ferramenta de IA não consegue ignorar, porque a ferramenta está fazendo posicionamentos dentro dela em vez de produzir output em formato livre que precisa ser retroajustado.

Design systems funcionam porque criam restrições. Ferramentas de IA para design funcionam apesar dos design systems, a menos que o sistema tenha ensinado à ferramenta o que é e o que não é permitido. Os times que vencerão o próximo ano de tooling de design são os que já moveram a conversa de “deveríamos ter diretrizes” para “temos um parser que roda em toda geração”.

A limpeza é lenta. Construa a restrição.

Fontes

AI Design Tools That Ignore Your Design System Create More Problems Than They Solve — Andrew Martin, UXPin, abril de 2026.
Thoughts and Feelings Around Claude Design — Sam Henri Gold, abril de 2026.

A Victorino ajuda lideranças de design e plataforma a adotar tooling de IA baseado em restrição que protege design systems em vez de erodi-los: contato@victorino.com.br | www.victorino.com.br