Pensamentos e impressões sobre o Claude Design
(samhenri.gold)- Com o fortalecimento da sistematização do design, o Figma ampliou uma estrutura complexa centrada em suas próprias unidades, como componentes, estilos, variáveis e props, e acabou criando uma distância em relação ao meio real de implementação
- O formato proprietário do Figma foi naturalmente excluído dos dados de treinamento de LLMs e, com a ascensão das ferramentas baseadas em código na era dos agentes, a fonte da verdade (source of truth) do design voltou a se deslocar para o código
- O Claude Design, como um meio honesto que lida diretamente com HTML/JS, adota uma abordagem de trabalhar diretamente no meio real de implementação, sem passar por uma aproximação com perdas (
lossy approximation) do código, como no Figma - Por meio de sua relação de ferramenta-irmã com o Claude Code, ele tem a vantagem estrutural de poder integrar o loop de feedback entre design e implementação em uma única conversa
- À medida que o mercado de ferramentas de design se divide entre ferramentas baseadas em código e ferramentas de exploração pura, surge a possibilidade de o Figma seguir o mesmo caminho do Sketch: um
**Sketch moment**
O paradoxo da sistematização do Figma
- À medida que o tamanho das equipes de produto cresceu, o design precisou justificar sua existência dentro da organização de engenharia e, para isso, foi empurrado na direção da sistematização (systematization)
- Para isso, o Figma inventou primitivos próprios como componentes, estilos, variáveis e props, mas alguns foram emprestados da programação e outros não, resultando numa estrutura que não corresponde de forma limpa a nenhum dos dois lados
- As diretrizes continuam mudando, as migrações se acumulam e, para automatizar qualquer coisa, a situação é depender de alguns plugins de baixa qualidade
- A complexidade cresceu a ponto de surgirem funções de design especializadas apenas em administrar esse sistema
O deslocamento da Source of Truth
- Sempre existiu uma tensão entre Figma e código sobre o que deveria ser a fonte da verdade (source of truth)
- Ao vencer o Sketch, o Figma adotou a posição de que sua ferramenta se tornaria a referência canônica
- Mas essa vitória teve um custo oculto: um formato fechado (
locked-down) e em grande parte não documentado é difícil de manipular programaticamente, sendo naturalmente excluído dos dados de treinamento de LLMs - Como os LLMs foram treinados em código, e não em primitivos do Figma, os modelos não aprenderam o sistema do Figma
- Com escrever código ficando mais fácil até para designers e os agentes evoluindo, a source of truth mostra uma tendência de retornar naturalmente ao código
- Diante disso, a infraestrutura complexa que o Figma introduziu na última década inevitavelmente parece excessiva
> "Se eu quero fazer cerâmica, por que estou pintando uma aquarela de um vaso? Não seria melhor simplesmente moldar o barro?"
A complexidade do próprio sistema de design do Figma
- No trabalho real, a tarefa de levar de volta para o Figma (
back-porting) alterações de design feitas diretamente no código é extremamente penosa - O texto usa como exemplo o arquivo de sistema de design do próprio produto do Figma e mostra que, mesmo sendo o resultado da equipe de sistema de design mais competente, ele se encontra em um estado extremamente complexo
- 946 variáveis de cor organizadas em grupos aninhados como "bg/desktopBackgrounded", com valores para 8 modos diferentes em uma única variável, como Light, Dark e FigJam-Light
- O componente de rodapé de modal tem 12 variantes, com dropdowns de valores como "DS Library Swap" e "QA Plugin", além de 8 props
- O estilo de efeito do componente de slider existe como um estilo nomeado separadamente para uma única sombra projetada de 0.5px — porque essa é a única forma de documentar sua correspondência com variáveis CSS
- O componente de combo input tem 16 variantes, e nomes de camada no formato "Default, Default, Close Button=False"
- Quando uma cor aparece errada, o processo de depuração exige um rastreamento em múltiplas etapas: verificar o componente → verificar a variável → verificar outra variável com alias → verificar o modo → verificar overrides no nível da instância → verificar componentes aninhados com library swap aplicado
Figma Make vs Claude Design
- Com a source of truth migrando para o código, o Figma fica numa posição desconfortável, carregando um sistema passivo e anterior à era dos agentes (
pre-agentic) - As ferramentas de design do futuro podem se dividir em duas formas claramente distintas
- A disputa em torno da pergunta que o Figma respondeu em 2016 — "qual é a ferramenta que me permite externalizar minhas ideias mais rapidamente como designer?" — pode recomeçar
- O Figma Make é uma ferramenta para quem já está acostumado ao sistema do Figma
- Ele lê estilos do Figma, bibliotecas de componentes e props proprietárias (
Prop Props), e é a única ferramenta nesse novo ambiente que ainda assume que o arquivo de design é a referência canônica - É uma ferramenta para quem quer permanecer dentro do sistema, ou não tem escolha a não ser permanecer
- Ele lê estilos do Figma, bibliotecas de componentes e props proprietárias (
- O Claude Design é a aposta oposta
- Está alinhado ao princípio "truth to materials" do movimento Arts and Crafts — a ideia de que um objeto deve ser honesto consigo mesmo e com a forma como é feito
- O Figma, em contraste, seria uma espécie de casca livre e "vibe" aplicada sobre um esquema extremamente rígido — comparado a uma personalidade tipo A fingindo estar relaxada enquanto, por dentro, grita com frames aninhados e separação de tokens
- O Claude Design é áspero, mas pelo menos é honesto sobre o que é: HTML e JS até o fim
A vantagem estrutural do Claude Design
- A principal vantagem estrutural do Claude Design é que sua ferramenta-irmã é o Claude Code, excelente em lidar com código
- Em última instância, a estrutura permite passar diretamente do Claude Design para o Claude Code ou no sentido inverso
- No onboarding do Claude Design, já existe a funcionalidade de importar repositórios (
repo) - O loop de feedback entre design e implementação — historicamente sempre fonte de atrito — converge para uma única conversa
A possibilidade de surgirem outras ferramentas sem relação com código: ambiente de exploração pura
- No outro eixo dessa bifurcação, pode haver o surgimento de ferramentas sem qualquer expectativa em relação a código
- Um ambiente de exploração pura, onde se colocam retângulos, se empilham estilos de camada e se manipulam livremente modos de mesclagem e gradientes, sem estar preso a sistemas ou regras de prompt
- Pode assumir a forma de apps com suporte a iPad + Pencil para rascunhar retângulos rapidamente, ou ser uma área em que a 37signals faça uma tentativa interessante
- Na direção oposta, poderia ir para algo como o Photoshop, apostando tudo em composição de alta fidelidade (
high-fidelity) e liberando a imaginação das limitações dos efeitos em CSS - Parece estranho pensar que o Figma, durante 90% de sua vida útil, ofereceu em efeitos de camada apenas sombra projetada ou blur
O "Sketch moment" do Figma
- O Sketch moment do Figma — o momento em que ele é superado, assim como o Sketch foi superado pelo Figma — está se aproximando rapidamente
1 comentários
Comentários do Hacker News
Revisei hoje um sistema de design que eu tinha feito antes, adicionando logo, branding e fontes, e só consegui um resultado minimamente satisfatório depois de mexer sem parar num nível irritante
Só que, quando vi o uso, eu já tinha queimado 95% do limite semanal do Claude Design
Nesse ponto, pareceu mais um brinquedo de demonstração do que uma ferramenta de produção
Não combinava nem um pouco com o estilo que queríamos, mas havia algumas decisões de agrupamento de conteúdo e de IA que valia a pena aproveitar no meu trabalho
No geral, a impressão foi boa, mas depois achei engraçado ver no Twitter outros casos de sucesso de pessoas com mockups quase idênticos ao que eu recebi
Acho que esse problema de homogeneização vai continuar perseguindo texto, código e imagens gerados por IA
Minha cunhada toca uma pequena empresa de roupas e, embora tenha melhorado muito ao longo dos últimos 6 anos, no começo sofreu bastante para transformar ideias em resultados concretos
Para alguém assim, acho que qualquer ferramenta que reduza a barreira de entrada inicial já vale a pena tentar
Mesmo assim, ainda está em fase de research preview, então imagino que isso mude mais para frente
Com o primeiro sistema de design, criei a nova seção de rodapé da minha startup de iPaaS, e a quarta opção entre quatro ficou muito boa
Depois integrei com o Claude Code, dei uma refinada e gerei o código para publicar na sequência. Se tiver curiosidade, dá para ver a seção inferior em tediware.com, na parte "Origin story" à esquerda e no painel de cadastro à direita
A implementação não era complexa, mas as ideias geradas e o fluxo de integração foram tão fáceis que me pareceram muito promissores
O Claude Design usa o Opus 4.7, então custa mais do que os modelos anteriores
Ainda está no segundo dia desde o lançamento e não é um produto acabado, e a Anthropic costuma melhorar essas coisas muito rápido
Além disso, se você já usa o Claude há bastante tempo, ele já conhece o meu gosto e estilo, então trocar para outra ferramenta de design com IA significaria recomeçar do zero
Em compensação, dá para exportar em ZIP, então tentei colocar esse arquivo no Stitch do Google, mas a compatibilidade não foi muito boa
Não concordo muito com a ideia de que o Claude Design vai eliminar toda a complexidade do design
Se um app feito com vibe coding no Claude parece simples, normalmente é porque o escopo do produto de fato é simples
É como comparar uma bicicleta com um avião usando o mesmo critério e achar que isso prova simplicidade
Se você fizer os mesmos componentes de um sistema de design em código e no Figma, o código pode até parecer mais conciso por causa de condicionais e fluxo de controle
Mas código é menos flexível do que desenhar diretamente na tela e torna mais difícil alcançar liberdade criativa
No fim, muita da complexidade é criada pelas próprias pessoas quando colocam 8 modos e temas claro/escuro em 4 produtos
O Claude pode facilitar um pouco a manutenção, mas não acho que vá remover grande parte da complexidade em si
Por isso, acho que essa tendência pode atingir a Figma com bastante força
Acho que o software que conseguir fazer isso vai vencer
Queria perguntar se entendi direito
Eu programo desde criança, mas nunca fui confiante com CSS, e fiquei curioso se realmente há muitas organizações em que desenvolvedores — inclusive front-end — colaboram com designers que gerenciam o design do produto inteiro em algo como o Figma, e não só esboços de logo ou landing pages
E queria saber se a ideia é que esses designers, mesmo sem serem desenvolvedores, mantenham algum tipo de banco de dados de estilos para controlar a aparência sem mexer no código, ou se o mais comum é que os próprios devs front-end também usem o Figma, mas não gostem do fato de ele ficar separado do código
O cliente também vê isso diretamente ou, no mínimo, aprova slides de branding refletindo aquele resultado do Figma
Depois o front-end olha o Figma e reimplementa em CSS, mas o recurso de copiar CSS do Figma é praticamente inútil, nível inline CSS, então quase sempre tudo é refeito como a melhor aproximação possível
O sistema de unidades não bate, e não há reflexo de relações pai/filho, variáveis CSS nem hierarquias de classes
Quando vários devs front-end implementam componentes separadamente, também começa a haver drift
Então cria-se outro ponto de referência no front-end com algo como Storybook, e dali aquilo é colocado em React ou NextJS, ou refeito como componente de CMS
Aí inevitavelmente surge a pergunta sobre qual é o verdadeiro source of truth, mas na prática isso se parece mais com uma cadeia de referências ligadas por telefone sem fio
E se ainda surgirem landing pages promocionais fora do projeto principal, o mesmo design acaba sendo implementado de novo em outro sistema
No fim, a lacuna de handoff entre design e código faz a intenção do designer se perder, ou então joga nas costas do desenvolvedor problemas reais como comprimento de texto, mudanças no número de elementos, rolagem real e adaptação a diferentes tamanhos de tela
É por isso que este vídeo curto de meme é engraçado e ao mesmo tempo nada engraçado: ele acerta exatamente essa realidade
Em geral, designers não codam e desenvolvedores não fazem design, e gente realmente boa nas duas coisas é raríssima
Sinceramente, é um processo bem horrível, mas ainda assim parece melhor do que as alternativas antigas
Mesmo assim, acho inferior a ferramentas conectadas diretamente ao código e que automatizam a maior parte do trabalho tedioso de traduzir design visual em código
Ainda não usei o Claude Design, mas para mim código é muito mais confortável do que as incontáveis opções de GUI do Figma
Como minha trajetória é parecida com a do autor da pergunta, isso me provoca uma rejeição quase instintiva
Com o tempo, para garantir que todos os engenheiros façam uma implementação consistente sem divergências de estilo, algum grau de referência centralizada acaba sendo indispensável
Ultimamente estou fazendo engenharia reversa do protocolo do Figma com figma-kiwi-protocol, então me identifiquei muito com a ideia de que “o Figma se excluiu dos dados de treinamento necessários para a era dos agentes”
O formato binário do Figma parece partir da ideia de reinventar tudo; como ele precisa lidar com design para web, Android, iOS e todo o resto, acaba sendo universal, mas não tem correspondência 1:1 com a web
E, para ser útil a agentes, a intenção precisa estar clara, mas quem já implementou Figma feito por designer de UX sabe que até para humanos muitas vezes é difícil inferir a intenção de design com precisão
O que acontece com um botão quando o texto fica maior, como em alemão? O que fazer quando ao levar para CSS ele quebra em duas linhas? E em celulares que não são iPhone? O que substitui uma borda com gradiente impossível em CSS? E em telas 4K? Essas perguntas não param
Dá para responder parte disso com props e autolayout, mas o profissional real de UX nem sempre é essa figura mítica que domina perfeitamente o Figma
Por isso, espero que ferramentas cujo interior seja baseado em HTML alcancem isso logo, e seria ótimo se também fosse possível ver o prompt que o gerente de produto passou para a pessoa de UX
Gostei do texto em si, e os últimos parágrafos foram realmente muito engraçados
Gostei especialmente da parte sobre não fingir ser outra coisa, mas ser honesto com a própria identidade
Isso também me fez pensar que o PenPot talvez esteja em uma posição bem favorável nessa era dos agentes
Em vez da abordagem de canvas típica da família fig, ele foi mais para o lado de design baseado em markup, então, se essa direção importar, parece ter ainda mais potencial
Desde que o InVision fechou e mudou de rumo para a área de whiteboard digital, para mim esse mercado de ferramentas de design praticamente acabou
Acho que é um mercado difícil nesse nível
Mais fundamentalmente, manter sistemas de design de forma consistente no longo prazo é difícil demais, especialmente porque eles estão profundamente entrelaçados com código e bibliotecas de componentes, uma camada em que designers quase não mexem
Nem Claude Design, nem Figma, nem nenhuma outra ferramenta parecem capazes de resolver na raiz esse inferno de Storybook em torno de componentes e layouts reutilizáveis e bonitos
Pareceu mais um problema que precisaria mudar em uma camada mais baixa, no nível do componente
Hoje estamos presos à mentalidade de criar componentes para encaixar em cada novo design
Quando surgir um componente de que você goste, basta salvar sua definição em markdown e, no próximo design, pedir à ferramenta que leia esse markdown e use aquele componente sempre que necessário
Acho que isso geraria um fluxo bem mais flexível e interessante
Ele precisa ser programável e também permitir desenho direto; quando o design mudar, o código de front-end deve mudar imediatamente, e alterações no código devem se refletir no design no mesmo nível
No formato ideal, designers e engenheiros front-end viram coautores sem handoff
Mas também existe o argumento de que, daqui para frente, editar, extrair e reorganizar vai ficar quase gratuito, então esse tipo de estruturação em si se tornará menos importante
Ainda não tenho convicção total, mas entendo por que se fala isso
Falando como alguém que vem construindo ferramentas de design diretamente nos últimos anos, senti que este texto entende de forma bem equivocada tanto o campo do design quanto a empresa Figma
A Figma sempre foi focada em construir uma empresa bem-sucedida tanto quanto um produto bem-sucedido
No começo havia direções mais ambiciosas, e eles tinham capacidade de execução graças a gente como Evan Wallace, mas no fim viraram o negócio que são hoje porque focaram no produto concreto que dava dinheiro, em vez de demos de WebGL
Acho que a ausência de coisas como recursos 3D é consequência direta dessa escolha
Antes de ser uma ferramenta de design, a Figma era uma empresa que fazia produtos que empresas realmente usam, e no momento em que chegou ao IPO esse objetivo já estava em grande parte cumprido
Não sei como o mercado vai evoluir daqui para frente, mas quem tem caixa de guerra pode estar em posição muito melhor do que quem só tem demos tecnicamente impressionantes
E os problemas citados no artigo já são muito conhecidos pelas pessoas da Figma e, na verdade, por qualquer um que já tenha tentado criar ferramentas de design
É óbvio para todo mundo que UI/UX fica na interseção entre design, desenvolvimento e PM, e que precisa se aproximar de um source of truth como o código
O problema é que, quando você tenta implementar isso de verdade, ele explode e vai muito além da ferramenta de design, alcançando codificação, gestão de dados e ferramentas de arquitetura, virando um desafio enorme
Sobre IA, também não tenho certeza, mas os modelos SOTA recentes parecem tão genéricos que talvez a capacidade de raciocínio do modelo-base importe mais do que dados especializados
UI design tem muita informação visível externamente, então também dá para coletar bastante coisa da web
Não tenho nenhum interesse especial nessa disputa, nem sei se a análise do post original está certa
Mas, ainda assim, sempre sinto um certo schadenfreude quando ouço histórias de alguém ficando para trás por causa de formato de arquivo proprietário
Alguns pontos foram bons, mas no geral não concordo totalmente
Acho que a Sketch perdeu para a Figma por causa de ferramentas de design e da experiência multiplayer
Assim como produtos físicos continuam sendo projetados antes de serem fabricados, também não acho que a etapa de projeto vá desaparecer dos produtos digitais
Pelo contrário, acho que a Figma precisa decidir logo com mais clareza qual é exatamente a sua identidade em vez de tentar fazer tudo ao mesmo tempo
O modelo em que era preciso instalar um app de Mac e abrir um arquivo específico foi envelhecendo, e isso reduziu tanto a acessibilidade quanto a atualidade dos arquivos
Como referência relacionada, houve recentemente este tópico no HN sobre Claude Design, que teve uma reação enorme, com 732 comentários em abril de 2026