Agora eu desenho mais com Claude do que com Figma
(blog.janestreet.com)- O workflow de design está migrando de um processo que passava por documentos de especificação e mockups no Figma para revisão da implementação para um fluxo de criação de funcionalidades protótipo funcionando dentro da base de código real
- Copilot, Cursor e Gemini ficaram aquém do esperado em tarefas como modificar um jogo já conhecido, escrever briefs de produto e fazer wireframes, mas em um ambiente novo com OCaml e Bonsai o suporte de IA se tornou essencial
- O processo passou a ser centrado na implementação real: enviar problemas e propostas em prompts, implementar a funcionalidade básica, iterar várias vezes, publicar no ambiente de desenvolvimento, verificar a opinião dos usuários e submeter a feature
- Um protótipo que adicionou prompting com LLM à entrada do JSQL levou a vários refinamentos em botão, atalhos, textos, prompts e mensagens de confirmação, concentrando o esforço no resultado real em vez de componentes no Figma ou formatação de documentos
- Os designers agora conseguem transformar ideias diretamente em algo utilizável, mas protótipos que parecem funcionalidades prontas também trazem novos desafios para a forma de revisar e para a exploração criativa
De ceticismo com LLM a ferramenta de suporte essencial
- Por muito tempo, sempre que usava LLMs eu me decepcionava com os resultados e, ao aplicá-los a tarefas em que eu já era bom, a experiência era de qualidade inferior ao que eu faria sozinho
- Tentei usar Copilot e Cursor para modificar um jogo que fiz no ano passado, mas nenhum dos dois conseguiu produzir mudanças funcionais; no emprego anterior, também tentei usar Gemini para criar esboços de briefs de produto e wireframes, mas tudo foi descartado
- Depois de entrar na Jane Street no verão passado, havia muito a aprender, e tecnologias ainda pouco familiares como OCaml e Bonsai fizeram do suporte de IA um elemento indispensável
- A grande mudança foi que a IA acabou transformando até mesmo o workflow de design em que eu mais confiava
Protótipos na base de código real em vez de Figma e documentos
- Em vez de escrever um documento de especificação, fazer mockups no Figma, redigir uma proposta e revisar a implementação com desenvolvedores, passei a criar uma funcionalidade protótipo que executa exatamente a ideia que está na minha cabeça
- Na prática, o fluxo consiste em escrever frases explicando o problema e a proposta, executar build, servidor e Claude no editor, e usar essa descrição como prompt
- Primeiro faço a funcionalidade básica funcionar para confirmar a viabilidade e depois repito ajustes quantas vezes quiser
- Em seguida publico as mudanças no ambiente de desenvolvimento, peço feedback aos usuários e, quando chega ao formato e comportamento desejados, submeto a feature
- Na Jane Street, feature é o processo equivalente a um pull request
- Uma funcionalidade protótipo dentro da base de código real oferece uma experiência melhor que mockups e documentos em quase todos os aspectos
- Um protótipo recente que adicionou prompting com LLM à entrada do JSQL realmente funcionou, e eu o usei e testei pessoalmente por vários dias
- JSQL é um dialeto interno de SQL usado em várias ferramentas voltadas a usuários
- Claude oferece iteração livre e praticamente ilimitada, sem se incomodar nem com a 50ª mudança de ideia nem com pedidos de ajustes mínimos
- Houve melhorias no botão de Submit, nos atalhos de teclado, nos textos, nos prompts e até nas mensagens de confirmação geradas
- No emprego anterior, isso exigiria vários dias ou semanas de vai-e-volta entre engenharia e design, ou, com probabilidade ainda maior, simplesmente nunca aconteceria
- O esforço investido nessa funcionalidade foi concentrado em melhorar o resultado real, e não em entregáveis intermediários como criar componentes no Figma ou ajustar formatação de documentos
Expansão do escopo nos últimos dois meses
- Levei tempo para chegar a esse fluxo, e no início, depois de entrar na empresa, eu usava IA apenas para tarefas pequenas, como corrigir pequenos incômodos de UX
- Para ideias maiores, eu ainda usava Figma e documentos, e as tentativas de construir isso com Claude fracassavam
- Nos últimos dois meses, as ocasiões em que abro o Figma caíram drasticamente, resultado da combinação de modelos melhores, mais habilidade com as ferramentas e escolhas de escopo mais adequadas
- A IA funcionou não apenas para prompts de JSQL, mas também em cerca de seis protótipos que criavam mudanças voltadas ao usuário, no modelo de dados e em bibliotecas
- Alguns protótipos tiveram diffs com mais de 2000 linhas
- Também foi usada para implementar o protótipo interativo de um novo app que havia sido projetado no Figma
- Em alguns novos apps, o Figma foi pulado e a iteração de design visual aconteceu com Claude desde o início
Mais autonomia para designers e redefinição da forma de revisão
- Quando têm uma ideia, engenheiros podem criar uma prova de conceito funcional, mas designers normalmente precisam convencer outra pessoa a construir isso por eles
- Ideias como “prompting com LLM diretamente na entrada do JSQL” não têm viabilidade clara no início, então pedir a outra pessoa para prototipá-las pode acabar desperdiçando tempo
- Algumas propostas podem não atender claramente às necessidades do usuário, e transformar a ideia em algo real com Claude deixa mais fácil para outras pessoas usarem e avaliarem diretamente
- A desvantagem é que o revisor recebe algo com aparência de funcionalidade pronta, o que torna incerto se ele deve revisar apenas o código sem ter participado da discussão sobre a funcionalidade
- Em termos de design, isso se parece com um PM entregar wireframes detalhados e pedir apenas para deixá-los bonitos — não é um tipo agradável de revisão
- A proposta precisa ser clara e completa, mas colegas de engenharia precisam tratá-la como algo para iterar junto no espaço de design, como fariam com um mockup no Figma
- A solução atual é incluir um aviso curto na descrição da feature
- O protótipo é um documento de proposta vivo
- O código pode ser descartado
- O papel do revisor é dar feedback de design e experiência do usuário
- No fim, o revisor pode assumir a ideia e implementá-la em uma feature separada, usando o protótipo como referência, enquanto o código de produção fica sob responsabilidade dele
- No trabalho real, ainda estamos entendendo continuamente o que faz sentido e o que parece adequado nesse novo workflow
Limites da iteração e a sensação de voltar ao meio real
- Existe a preocupação de que projetar com Claude afaste do pensamento mais fluido e criativo, prendendo a iteração ao conjunto de resultados que você acha que Claude consegue produzir
- Isso funciona bem quando as mudanças são iterativas, como em ferramentas maduras, mas ao criar algo novo existe o risco de deixar ideias passarem
- Quando comecei minha carreira profissional, em 2011, havia muita discussão sobre designers should code, e os críticos argumentavam que, ao começar a programar, ficava mais difícil fazer mudanças grandes nas ideias
- Como eu gostava de criar sites e programar, continuei escrevendo código e, depois que frameworks de frontend como React se popularizaram e o desenvolvimento frontend ficou mais complexo, acabei optando pela especialização
- Projetos pessoais em React ajudavam na interação com desenvolvedores, mas no trabalho eu passava quase todo o tempo no Figma e em documentos
- Se eu tivesse entrado na Jane Street antes da era dos LLMs, provavelmente teria me fixado ainda mais no Figma e, diferentemente de JavaScript, OCaml e Bonsai eram totalmente novos, o que faria a contribuição técnica parecer algo fora do meu alcance
- Agora voltei a criar resultados reais, trabalhando dentro desse meio e com uma sensação maior de liberdade para experimentar qualquer coisa
1 comentários
Comentários do Hacker News
A área de negócios já costuma trazer requisitos na forma da solução que eles mesmos imaginaram, e geralmente é algo tipo uma máquina de Rube Goldberg, então é preciso fazer engenharia reversa na conversa para chegar ao requisito real
Daqui para frente, parece que vão trazer soluções já “prontas” e “funcionando”, e estarão menos abertos à ideia de olhar o design e a arquitetura de forma ampla
Vai virar algo como: “é só fazer assim, ué. Já está quase pronto, por que precisamos de X semanas de trabalho?”
A desvantagem é que a área de negócios não entende por que não dá para simplesmente colocar aquele app em produção do jeito que está
A pressão de “dá para ir mais rápido com IA” aumenta, e no fim isso provavelmente vai depender da dinâmica saudável da organização
A vantagem é que a ideia já foi validada de forma muito mais completa do que num rabisco de guardanapo
O Claude provavelmente já perguntou sobre casos de borda e decisões de design, e em algum momento devem até ter dito explicitamente algo como “não se preocupe com isso, só assuma” ou “usei algumas vezes e essa interação não ficou boa, faz de outro jeito”
Agora a pressão de “qual é o problema? é só colocar em produção” é forte, burra e desmoralizante, então é quase uma perda líquida, mas quando isso estabilizar pode acabar sendo um ganho líquido para projetos futuros
E esses ajustes pequenos são coisas como o layout quebrar se o navegador não tiver exatamente 1920 px de largura, filtros e ordenação falharem de vez em quando, ou novos valores não serem atualizados corretamente no app depois de certas ações
Independentemente do problema, a área de negócios acha que já fez 95% do trabalho e presume de antemão que “um desenvolvedor experiente resolve isso rapidinho”
As pessoas se acostumam com o resultado que já têm e passam a aceitar com mais dificuldade as mudanças feitas numa nova mixagem profissional
Existem PMs, CSMs e TAMs que têm faro para traduzir o problema do cliente em funcionalidades de produto com boa usabilidade, mas quando se pula a definição do problema e se faz outra área funcional construir a solução, isso geralmente vira uma catástrofe que desperdiça muita engenharia e outros recursos
Quando alguém chega com uma solução pronta, há um grande risco de só descobrir, depois de meses construindo software operável, que o cliente odeia aquilo, que não resolve o problema ou que criou problemas novos
Não onde trabalho hoje, mas em um lugar onde trabalhei antes, e foi para produção mesmo com perda de dados e problemas de segurança
Pelo que sei, a Jane Street é investidora da Anthropic, então é bom levar isso em conta
Também tem o fato de que, em julho de 2025, a SEBI, reguladora do mercado de capitais da Índia, alegou que a Jane Street fez manipulação de mercado usando várias entidades e a proibiu de acessar o mercado
Cofres enormes devem precisar de muitos dashboards
Aqui, o designer parece estar seguindo uma abordagem errada e caindo numa espécie de admiração por engenharia, querendo tornar o protótipo o mais profundo e realista possível
Mas essa não é a parte mais importante do trabalho de design
O mais importante é garantir que a coisa certa esteja sendo construída
Perguntas como “por que precisamos de uma caixa de entrada JSQL? o que a pessoa realmente quer? que outras formas existem?” muitas vezes são resolvidas melhor com esboços em papel e caneta, reuniões, observação e discussão
Isso é melhor do que afunilar cedo demais para um design específico e entrar em discussões do tipo se o botão fica à esquerda ou à direita, ou como exatamente o LLM deve se comportar
Embora, claro, talvez seja exatamente isso que eles queiram que você pense
Às vezes dá para ver isso
No estado atual, os LLMs não conseguem enxergar além da repetição, então eu é que preciso pensar fora da caixa e dizer “e se olhássemos por este ângulo?”, e só então de repente aparece uma nova forma de design
Às vezes é preciso fazer um fluxograma para tentar fazer o LLM enxergar além da etapa em que ele está
Quando dizem que “o Claude me deu iteração grátis e ilimitada, sem se importar se eu mudasse de ideia pela 50ª vez ou pedisse pequenos ajustes”, isso quer dizer que a pessoa não paga pelo Claude?
Estúdios pequenos de design também funcionam de forma parecida, e muitas vezes não cobram por hora como desenvolvedores
Respondi honestamente que sou realmente ruim em design e também tenho dificuldade para extrapolar sistemas de design
É muito difícil chegar a um ponto que pareça aceitável e, no processo, quase sempre acabo piorando tudo
A designer da entrevista levou isso para o lado pessoal e começou a me pressionar
Já aconteceu algo parecido antes
Designers odiavam as perguntas constantes sobre como as coisas deveriam parecer e queriam uma entrega única, como se depois da passagem de bastão o assunto estivesse encerrado
Em agências de marketing e publicidade eu também tinha que brigar repetidamente para conseguir exemplos de como coisas não cobertas na especificação de design deveriam parecer
Não estou dizendo que eu estava certo, mas isso é um grande calcanhar de Aquiles para mim
Então, quando ouço “grátis, iteração ilimitada, sem se importar”, penso antes em tempo e paciência do que em dinheiro
O Bolt que eu uso para prototipagem não fica irritado
Talvez ele não produza o melhor design possível, mas é muito melhor do que eu conseguiria fazer, e no fim dá para passar para um designer de verdade deixar melhor
Até lá, não preciso me preocupar em irritar ninguém
Tenho usado o Claude Design no front-end
O visual e a sensação do resultado são bons o bastante, mas os designs frequentemente parecem parecidos entre si e, em geral, seguem padrões batidos da web moderna
Fico curioso se alguém já tentou fazer experiências criativas fora do convencional com isso
Já investi cerca de 3 semanas até agora e ainda não está concluído, mas dá para pegar a ideia
Assim como existia boilerplate de SaaS na última década, também existe boilerplate de LLM treinado na internet
Mesmo assim, se você meter a mão o suficiente, ainda dá para fazer qualquer coisa
É interessante como ele acerta quando você dá requisitos, e faz escolhas seguras quando você não dá direção
Se você vai avaliar a estética da saída e a experiência do usuário/conteúdo, mas quase não dá prompts voltados à estética, vai acabar recebendo só os padrões seguros
Ele faz bem designs com cara de cópia de bootstrap/tailwind, mas é preciso empurrar conscientemente para além disso
Em páginas web simples, comecei a colocar o estilo visual como único foco das iterações iniciais
Basta instruir de forma específica para que não pareça algo padronizado e dar exemplos do estilo de site que você quer
Se você insistir um pouco, ele parece um pouco mais criativo, mas isso exige trabalho de prompt
Ele me foi recomendado por designers muito respeitados e experientes, e eles agora fazem protótipos quase inteiramente no Claude e, se gostarem, refinam no Figma
Pedir uma UI genérica sem um prompt de estilo detalhado e receber um design genérico é algo totalmente esperado
A vantagem aqui é o designer aprender a programar
Sempre achei estranho que designers moldassem software sem saber como software é feito
Para constar, eu também sou designer
Só que projetar em código é uma abordagem technology-first
Se o objetivo do design é moldar o resultado para os propósitos humanos, também dá para argumentar que é melhor não começar pelas regras rígidas do código
Não por causa de resultados bonitos, mas para empurrar o pensamento adiante ainda é difícil superar caneta e papel
Agora que dá para programar praticamente por voz, estou voltando para vibe coding e para criar produtos, e está sendo ótimo
Meu chefe ainda está entendendo essa nova situação, mas a antiga separação de papéis parece estar começando a morrer
Acho que estar na interseção é a melhor posição agora
Sinto que minha vida inteira me preparou para este momento
Para designers, deve ser parecido com um Figma em que você olha o resultado e faz ajustes por linguagem em vez de um editor visual
Minha esposa trabalha como gerente de produto em uma FAANG, e a equipe dela depende fortemente de vibe coding com IA para criar pedaços de software que antes fariam em Word ou Excel
Eles não estão aprendendo a programar e não olham para o código nem por um segundo
A abordagem de que “o protótipo é um documento vivo de proposta, o código pode ser descartado, e o trabalho do revisor é dar feedback sobre o design e a experiência do usuário
No fim, o revisor assume a ideia e a implementa como uma funcionalidade separada, usando o protótipo como referência, mas sendo dono do código de produção” resolve um problema que eu tinha em todos os POCs
É uma forma muito boa de trabalhar
Ao lidar com uma questão específica de um produto específico, é fácil chamar isso de “documento de proposta”
Mas ainda existem muitos designers usando Figma para definir e manter design systems em produtos e plataformas inteiras, e, nesse caso, o Figma é a fonte da verdade
Nossa equipe também trabalha assim, e eu sou engenheiro de front-end; sinceramente, sinto muita falta do jeito antigo
Como especificações escritas foram substituídas por protótipos funcionais, agora existe uma carga cognitiva extra de ter que ler o código e decidir quais mudanças eram intencionais e quais ruídos devem ser descartados
Tenho que receber um PR gerado e decidir se faço as alterações necessárias ou se reconstruo tudo do zero, e há atrito em qualquer um dos caminhos
Já aconteceu de serem geradas várias mudanças não intencionais, e depois que eu perdi tempo reimplementando e migrando tudo, mais tarde veio um “ah, desculpa, isso não era para mudar”
Entendo o ponto de dar autonomia, mas isso tirou parte da diversão que eu sentia no trabalho antigo e transformou em dor de cabeça
O pessoal de design e produto faz vibe design/coding de recursos ou experiências com Claude e cria protótipos rapidamente, levando isso para clientes com o mínimo de tempo de engenharia para obter feedback
Isso é excelente
Mas talvez surpreenda que, no geral, isso não tenha ajudado muito a lançar mais rápido
Acho que o motivo é que perdemos pensamento no processo
Uma parte nada pequena do raciocínio agora foi terceirizada para o modelo de linguagem
Ele tapa os buracos do prompt e preenche comportamentos não especificados com alucinações
Coisas em que antes se parava para pensar “isso não encaixa muito bem”, “como vou transmitir essa ideia”, “o que acontece neste caso” desapareceram, e agora esses detalhes ficam para depois de já ter sido construído
Claro, dá para melhorar o processo e refletir sobre como aproveitar melhor essa técnica nova, mas se é melhor do que antes, não sei
Está entrando em declínio
Agora o pessoal de back-end também faz front-end
Essa é a ilusão
Você fica olhando assembly gerado por compilador? Não fica
Então por que está olhando para este código?
Nós apenas elevamos a camada de abstração
Eu também uso bastante essa mesma abordagem
Mesmo antes da IA, eu já fazia isso manualmente
Primeiro eu sentava com o usuário só com caneta e papel; depois criava rapidamente um POC ou demo de frontend, deixava o usuário mexer e então ajustava até funcionar do jeito que ele queria
Para mim, criar em código uma demo rápida de frontend, sem qualidade de produção, muitas vezes já era mais rápido do que construir interações precisas no Figma
Como era possível ter interação completa, eu conseguia capturar muito mais casos de borda da experiência do usuário
Agora, com o Claude Code, ficou mais rápido criar protótipos descartáveis, mas a diferença não é tão enorme assim
Como 80% do trabalho é discutir com o usuário e pensar em como aquilo deve funcionar, o Claude basicamente corta pela metade os 20% restantes em comparação com eu mesmo fazer tudo rapidamente
A primeira versão sai mais rápido, mas as iterações ficam mais lentas quando eu ainda não entendi tudo completamente
Edwin, que bom ver você publicando por aqui
Lembro de termos participado juntos de um hackathon por volta de 2012/2013
A capacidade de chegar mais rápido a um protótipo funcional é algo muito poderoso, mesmo que exista a tentação de simplesmente colocar no ar ideias ainda inacabadas
Requisitos de design e experiência do usuário ganham muito quando é possível ir além de storyboards e wireframes e realmente tocar e vivenciar o fluxo