O agente do Figma só é tão bom como as regras que lhe dás.
O Figma mostrou como três equipas (Uber, Granola e Atlassian) usam o seu agente. Nenhum dos casos é sobre substituir designers: são sobre documentação, notas de reunião, arrumação e animação que ficava por publicar. O que fizeram, o padrão e o que eu experimentava primeiro.
A 6 de outubro de 2026, o Figma publicou no LinkedIn três casos de equipas que usam o agente do Figma: a Uber, a Granola e a Atlassian. Li-os à procura de uma coisa: que trabalho é que cada equipa lhe entregou. A resposta é a mesma nas três, e não é «o design».
Este artigo é a minha leitura, não uma tradução: o que as três equipas fizeram, o que têm em comum e o que tiro daqui, para quem desenha produto e para quem gere um negócio. Os números e os resultados são do Figma e das equipas, e digo sempre de quem.
O que o Figma anunciou
O agente do Figma saiu de beta e passou a estar disponível de forma geral. O Figma diz que segue melhor as instruções e aguenta tarefas mais longas, e que ganha cerca de 60% ou mais das avaliações que faz com designers profissionais, classificadas por pessoas. O número é deles.
Com isto vieram três novidades:
- Guidelines. Ficheiros markdown que o dono de uma biblioteca carrega nessa biblioteca do Figma, para dizer ao agente como se usa aquele design system.
- Conteúdo de todo o Figma. O agente encontra e insere conteúdo que está noutros sítios do Figma: stickies do FigJam, texto do Slides, frames do Design.
- Agentes à vista. Podes acompanhar o agente dos teus colegas enquanto trabalha no canvas.
Quem o pode usar: os lugares Full dos planos Professional, Organization, Enterprise e de alguns planos Education, com uso limitado no Starter. Os lugares Collab, Dev e View podem usá-lo nos rascunhos.
O padrão que o Figma descreve é este: as equipas usam o agente para automatizar trabalho repetitivo, para documentar e manter design systems e para serem mais expressivas.
O resumo, numa tabela
| Equipa | O trabalho | O que o agente faz | O que o segura |
|---|---|---|---|
| Uber | Documentar componentes que vivem em sete plataformas | Mostra a anatomia de um componente, liga as cores aos tokens e assinala valores fixos | Skills feitas por um designer da equipa |
| Granola | Feedback de reuniões, ecrãs por arrumar, variações de texto | Escreve o feedback no canvas como anotações e volta a ligar ecrãs à biblioteca | A biblioteca de componentes da app |
| Atlassian | Animação que muitas vezes não chegava ao produto | Ajuda a afinar a curva e a duração de uma animação | As variáveis do Atlassian Design System |
1. Uber: a documentação que levava meses
A equipa de design systems da Uber mantém componentes em sete plataformas. Um só componente pode ter dezenas de estados, variantes, slots, booleanos e enums, e quem lê mal o seu âmbito acaba a refazer trabalho.
Os designers Ian Guisard e Niloo B. usam o agente com um conjunto de skills que o Ian construiu, para produzir documentação pronta para os programadores. Uma skill mostra a anatomia de um componente num desenho anotado. Outra liga as cores aos design tokens e assinala os valores escritos à mão. As skills estão publicadas na Figma Community.
O resultado que a equipa conta: documentação que ocupava várias pessoas durante meses é hoje publicada por um designer numa tarde. E há um pormenor de que gosto mais do que do número: o agente apanhou uma cor fixa que o designer tinha alterado por engano.
O que tiro daqui: as skills foram feitas por quem conhece o sistema. O agente aplica as regras; não foi ele que as escreveu.
2. Granola: estar na reunião, em vez de tomar notas
A Granola é uma equipa pequena que faz uma app de notas de reunião com IA. O designer Paavan Buddhdev explora com muitas versões lado a lado no canvas.
Com o conector da Granola, o agente pega nas notas e nas transcrições das reuniões e escreve o feedback no canvas, como anotações. Assim ele pode estar presente na reunião, em vez de ficar a escrever uma lista de tarefas.
Há mais dois usos. Traz ecrãs que já existem na app para o canvas, com a extensão do Figma para o Chrome, e pede ao agente que os volte a ligar à biblioteca de componentes. E pede variações de texto: por exemplo, trinta maneiras de escrever um botão.
A ideia dele: quanto mais cedo um desenho estiver à frente de um utilizador, melhor.
O que tiro daqui: trinta variações não são uma decisão. Escolher uma continua a ser trabalho de quem conhece o produto.
3. Atlassian: animação dentro das regras
Na Atlassian, a animação faz parte da marca, mas muitas vezes não chegava ao produto. Uma equipa pequena de motion (Alexandra Pereira, Davy Fung e Maxwell Hathaway) transformou os recursos de animação em componentes reutilizáveis no Figma: um designer escolhe uma ilustração animada para o slot de um componente.
Quando é preciso algo à medida, o agente ajuda a iterar na curva (o easing) e na duração, sem sair das variáveis do Atlassian Design System. Um designer de produto sem experiência em motion animou um banner descrevendo o que queria e pedindo feedback ao agente.
O ponto da equipa: em sistemas grandes, o que importa é gerar dentro de limites. Consistência, acessibilidade e qualidade de implementação, e não só velocidade.
O que tiro daqui: leio isto assim: quem não é de motion pôde animar porque as decisões de motion já estavam no sistema, tomadas por quem sabe.
O padrão: o trabalho à volta do design
Nenhum destes casos é sobre substituir designers. São sobre o trabalho à volta do design: documentação, notas de reunião, ecrãs por arrumar, animação que ficava por publicar. Trabalho necessário, pouco vistoso, e quase sempre o primeiro a ser adiado.
E em todos há a mesma condição. Na Uber, as skills. Na Granola, a biblioteca de componentes. Na Atlassian, as variáveis. As guidelines que o Figma lançou são a mesma ideia: regras escritas por quem é dono do sistema.
Um agente só é tão bom como o sistema e as regras que lhe dás. Com um design system bem definido, trabalha dentro dele. Sem isso, é rápido a produzir coisas que alguém vai ter de corrigir.
O que muda, e o que não muda
Escrevi noutro artigo que, com IA, o método não muda: muda o tempo. Quando fazer deixa de ser a parte demorada, decidir passa a ser quase todo o trabalho. Estes três casos dizem o mesmo por outras palavras: o agente ficou com a execução, e as regras e as escolhas ficaram com pessoas.
Se geres um negócio e tens uma equipa de design, a pergunta útil não é quantos designers se poupam. É que trabalho fica hoje por fazer, e se as regras do teu produto estão escritas em algum lado onde uma ferramenta as consiga ler.
O que eu experimentava primeiro
Uso ferramentas de IA em produção todos os dias: o Claude com integrações MCP está no centro do meu processo, ligado ao Figma, à documentação e à investigação. Com o agente do Figma não tenho resultados meus para te mostrar, e por isso o que se segue é intenção, não experiência.
Hoje lidero o design de produto e o Design System multimarca do SkillUp, um LMS B2B. Começava por aqui:
- Escrever as guidelines. Antes de pedir seja o que for ao agente, pôr por escrito como se usa o design system. Num sistema para várias marcas, a IA só ajuda se as regras estiverem bem definidas.
- Documentar um componente, só um. Com anatomia e tokens, como no caso da Uber, para ver quanto do resultado tenho de corrigir à mão.
- Procurar valores fixos. Cores escritas à mão onde devia estar um token. Foi um engano destes que o agente apanhou na Uber.
A ordem é de propósito: primeiro as regras, depois o agente.
Um cuidado
Os casos foram escolhidos e publicados pelo Figma, que é quem faz o produto. Uma tarde em vez de meses é o relato de uma equipa, com as suas skills e o seu sistema: não é uma promessa para a tua. Vale como direção, e a direção parece-me certa.
Se queres preparar o teu design system para trabalhar com agentes, fala comigo.
Para ler mais
- Figma, «3 ways product designers use the Figma agent for craft, speed, and creative expression», LinkedIn, 6 de outubro de 2026: o artigo original, em inglês, com os três casos.
- UX Designer vs AI-First UX Designer: o que muda, fase a fase, quando a IA entra no processo de design.
