A ascensão do "designer de modelos": o papel do design está mudando nos produtos de IA

• Barron Webster, com mais de 8 anos de experiência em design de produtos de IA, atua na Figma no primeiro cargo de "designer de modelos" do mundo, o que sinaliza o surgimento de uma nova função híbrida em que designers colaboram diretamente com LLMs
• O trabalho central do designer de modelos é compensar as limitações dos modelos fundacionais e introduzir na organização de design novas ferramentas e uma nova forma de pensar para projetar funcionalidades de IA
• Diferentemente do design tradicional de UI, projetar produtos de IA exige prototipar primeiro o comportamento do modelo e só depois desenhar a UI; caso contrário, há o risco de criar uma interface que não corresponda ao funcionamento real
• A construção de um sistema de avaliação (Evals) é o núcleo do controle de qualidade em produtos de IA, e são necessárias ferramentas para que designers possam manipular e executar casos de avaliação em loops rápidos de feedback
• Na era da IA, é essencial que designers compreendam profundamente a estrutura de entrada e saída dos modelos e tenham capacidade de entender o sistema como um todo, tornando-se participantes das decisões, e não meros criadores de UI

---

Apresentação de Barron Webster

• Designer que esteve profundamente envolvido com produtos de IA por mais de 8 anos, com visão para enxergar além dos ciclos de hype
• Participou do design do Teachable Machine, lançado em 2017 no Google Creative Lab, uma das primeiras ferramentas que permitiam ao consumidor treinar modelos de IA
• Depois trabalhou em recursos de IA na Replit, contribuindo para o crescimento da startup até se tornar um unicórnio
• Recentemente entrou na Figma como o primeiro designer de modelos do mundo

O papel do designer de modelos

• Faz parte da equipe de pesquisa em IA da Figma e cumpre duas missões principais
  • Resolver situações em que extrair o máximo desempenho possível dos modelos fundacionais ainda não é suficiente
  • Como os dados da Figma estão em um formato proprietário, os modelos fundacionais não lidam bem com eles, então o trabalho é preencher essa lacuna
• Introduzir na organização de design novas ferramentas e uma mentalidade AI-first
  • A Figma é uma grande empresa, e muitos designers não têm experiência em projetar experiências com IA
  • Projetar funcionalidades de IA é diferente do design tradicional de produto
• O objetivo é criar ferramentas para que designers possam prototipar, ainda no início do processo, a essência das funcionalidades de IA sem precisar se tornar engenheiros
  • Se alguém projeta a UI de uma funcionalidade que nunca experimentou diretamente, corre o risco de criar uma interface perfeita apenas para casos ideais, mas incompatível com o funcionamento real

O futuro das ferramentas de design para IA

• A ferramenta que ele mais quer ver é uma em que designers possam manipular e executar casos de avaliação em loops rápidos de feedback
  • Se uma funcionalidade de IA não funcionar em um arquivo do Figma, isso deve poder ser adicionado imediatamente como caso de teste
  • Ajustar o prompt do sistema, testar outro modelo e coisas do tipo deveriam ser possíveis na hora
• Hoje, o problema é que o loop de feedback é lento demais
  • O núcleo de toda boa ferramenta de design é eliminar ou reduzir o loop de feedback
  • Grande parte do trabalho de montar conjuntos de avaliação ainda é manual, voltado à organização dos dados
• Ele também pensa em como diferenciar funcionalidades de IA na Figma
  • Como é uma plataforma de design, espera-se uma saída mais bem projetada do que em ferramentas como Claude Code ou Cursor
  • O ponto-chave é encontrar uma estratégia de avaliação direcionada e bons proxies para “bom design”
  • Isso também é uma questão filosófica em nível de escola de arte

A entrada de Barron no mundo da IA

• Aula Computer Utopias da RISD em 2014-2015: era anterior aos LLMs, quando a pesquisa em machine learning era centrada em classificadores
  • Modelos de classificação de imagem eram o que havia de mais interessante, impulsionando filtros faciais do Snapchat e a busca de imagens do Google
  • Moderação de conteúdo e sistemas de recomendação eram temas centrais
  • Era o auge de Facebook, Twitter e Cambridge Analytica, e a invenção do feed algorítmico criava novo material para projetar
• Google Creative Lab entre 2016 e 2018: trabalhou em Google Lens, Google Assistant e Teachable Machine
  • Quase todos os projetos aplicavam inovações em modelos
  • Os modelos eram usados não para gerar texto, mas para organizar ou anotar conteúdo existente
  • Também participou da promoção de um caso em que um agricultor japonês de pepino usou TensorFlow para classificar pepinos

A experiência na Replit

• Trabalhou lá por mais de 3 anos, começando quando praticamente não havia recursos de IA e assumindo o papel de avaliar como aplicá-la
• Conforme os modelos melhoravam continuamente, buscava formas de adicionar funcionalidades de IA confiáveis que também aproveitassem novas capacidades
• Tudo começou com recursos básicos acionados manualmente, como selecionar código para receber uma explicação por IA ou gerar código em um arquivo existente
• Após o lançamento de cada recurso, o ciclo de aumento das expectativas dos usuários se repetia
  • Permitir geração de snippets de código → pedidos por arquivos ou projetos inteiros
  • Tornar possível gerar tudo → pedidos por edições específicas
  • Tornar possível fazer edições específicas → pedidos para começar tudo do zero
• O padrão recorrente era: tentar criar uma funcionalidade com o modelo existente → se não der certo, esperar → tentar de novo quando sair um novo modelo fundacional
• Havia restrições específicas do produto em um ambiente de programação
  • Mesmo que o modelo escrevesse bem o código, era preciso descobrir como editar no lugar certo
  • Até o Sonnet 3.5, os modelos tinham dificuldade em lidar com números de linha
  • Foi necessário desenvolver soluções provisórias para precisão de edição, evitar duplicação de conteúdo e substituir funções
  • A maioria dessas soluções se tornava inútil 6 a 12 meses depois, com a chegada de novos modelos

Um caso de mudança para validação pelo usuário

• Quando o agente da Replit criava arquivos automaticamente e escrevia código, um grande desafio técnico era testar o aplicativo construído pelo agente
  • Exemplo: verificar se uma página de login realmente funcionava
• A abordagem da engenharia era: subir um sandbox, criar funcionalidade de screenshot e alimentar um modelo multimodal com essas imagens para decidir onde clicar ou digitar
  • Em essência, isso implementava uma espécie de uso de computador pelo modelo
• A proposta de Barron e de outro engenheiro foi diferente: mostrar o site ao usuário e pedir que ele mesmo o testasse
  • Ao transferir validação e testes para o usuário, contornava-se todo o problema técnico complexo
• Quando há alguém focado não no problema técnico, mas no problema do usuário, muita coisa pode ser pulada ou simplificada

Descobrindo product-market fit

• Antes da IA, a estratégia tradicional de produto era: fazer um plano, considerar a base de usuários existente e traçar uma estratégia de expansão de mercado ou categoria
• Com a velocidade das mudanças em IA, a estratégia da Replit se tornou muito mais reativa
• A empresa tinha forte product-market fit no mercado educacional, especialmente após a pandemia e a educação remota
• A melhora das funcionalidades de IA gerou um dilema
  • Desenvolvedores independentes e hackers gostavam de IA
  • Professores eram contra, porque ela podia permitir que estudantes pulassem o aprendizado básico
• Quando o agente da Replit foi lançado, não estava claro quem era o usuário-alvo
  • Em vez de um projeto top-down, lançar a funcionalidade e observar a reação foi mais bem-sucedido
  • Depois do lançamento, as conversas com usuários revelaram um público: profissionais de operações em empresas de tecnologia que precisavam coletar dados de vendas ou montar dashboards, semelhantes a usuários de Zapier ou Retool

Sistema de avaliação (Evals)

• Nos dois primeiros anos na Replit, quase não se usavam avaliações, porque a prática ainda não era difundida
• Com o agente, as avaliações passaram a ser mais usadas, principalmente como métrica de desenvolvimento de produto
  • Quando saía um novo modelo, observava-se o desempenho em avaliações de programação para decidir se valia a pena testar apps
• Na Sandbar, muito tempo foi investido em escrever avaliações sobre a personalidade do modelo
  • Além das avaliações amplas de benchmark da indústria, construir avaliações específicas do produto era um novo tipo de trabalho de design
• O fluxo era: escrever o prompt → ajustar o prompt → criar a avaliação → checar o desempenho → combinar com testes manuais e feedback subjetivo
• Sem avaliações, o trabalho manual para verificar se a IA funciona aumenta muito
• Exemplos de avaliações na Sandbar
  • Se não souber a resposta, o modelo deve fazer uma única pergunta de esclarecimento, concreta e específica, em vez de alucinar
  • Não pode fazer mais de duas perguntas de uma vez
  • Deve manter a resposta concisa, com exceções

A dificuldade das avaliações

• Sycophancy é um dos temas mais difíceis ao escrever avaliações
  • Trata-se da ideia de que o modelo deve contrariar o usuário quando isso for apropriado
  • Decidir qual taxa de falha é aceitável torna-se uma decisão de produto e design, parte da filosofia de design do produto
• Muitas vezes, resultados ruins em avaliações não vêm de queda de desempenho, e sim de avaliações mal escritas
  • Ex.: numa avaliação do tipo “deve ser muito conciso”, se o usuário disser “minha mãe morreu”, “sinto muito” pode receber pontuação alta, mas ainda assim não é a resposta desejada
• Avaliações servem principalmente para evitar regressões, verificando se certas características são mantidas
  • Isso é semelhante à cobertura de testes em programação
• Algo como desenvolvimento guiado por testes (TDD) ainda é raro na engenharia de IA
  • Ou seja, escrever primeiro a avaliação e depois produzir o código que a faça passar
• Existe a possibilidade de surgir no futuro a profissão de designer de avaliações
  • Um papel parecido com o de sistemas de design, mas voltado a desenhar dashboards que ajudem equipes a entender o desempenho da IA

Ideias de funcionalidades de IA na Figma

• Ele está considerando a ideia de "crítica de design como serviço"
  • Pedir à IA uma crítica de design
  • Isso levanta perguntas interessantes sobre a personalidade desse sistema
• Oferecer posturas selecionáveis (por exemplo, estilo “Dieter Rams”) versus definir um padrão
• Focar em acessibilidade e contraste, que geram feedback mais objetivo, versus buscar algo mais amplo
• Ainda não está claro quanto disso entrará na experiência real do produto

Para onde devem evoluir as ferramentas de avaliação

• Ele quer ferramentas que reduzam a velocidade de iteração para criar avaliações
• Hoje, todo mundo que trabalha com avaliações precisa basicamente fazer o mesmo tipo de trabalho
  • Conectar mapeamento, formatação, pipelines e uma interface que permita ver as saídas em um só lugar
• As ferramentas para texto são bem razoáveis, mas faltam ferramentas para outros formatos
• Já existem plataformas parecidas, como a Design Arena
  • Nelas, as pessoas votam na melhor saída desejada em testes cegos side-by-side
• Ele quer poder fazer algo semelhante diretamente em arquivos do Figma
  • Incluindo comentar e apontar problemas
  • Deve ser possível criar rapidamente um conjunto de testes, rodá-lo de uma vez, receber 100 respostas e iterar em 30 segundos
  • Hoje, todas as peças já existem, mas o processo ainda leva tempo demais

O papel dos designers na criação de modelos

• Ele já vivenciou duas abordagens: treinar do zero e fine-tuning
• No treinamento do zero: a maior contribuição do designer é mostrar à organização onde as necessidades e dores do usuário são maiores
  • Na Replit, houve treinamento de um modelo customizado para erros comuns e simples em código Python
  • Ele se envolveu mais em definir o problema e descobrir como aplicar o modelo treinado ao produto do que no treinamento em si
• No fine-tuning: já existe um modelo, um produto e avaliações, e deseja-se melhorar o desempenho
  • Quem escreve prompts, escreve avaliações e conversa com usuários entende com clareza se as expectativas estão sendo atendidas
  • Quando o prompt engineering chega ao limite, o fine-tuning se torna o próximo passo
• O papel central de tradução do designer é: lembrar das suposições do usuário
  • Engenheiros e designers que trabalham de perto com modelos podem esquecer que o usuário não conhece os detalhes
  • É preciso usar o “idiota interior” para comunicar o que um usuário ingênuo, que não conhece as características do modelo de IA, tentaria fazer e onde travaria

Conselhos para designers de produtos de IA

• O mais sustentável e impactante é: investir bastante tempo antecipadamente para entender de verdade as entradas e saídas do modelo
  • O que é o prompt, que informações do usuário entram, quais ferramentas podem ser chamadas, que avaliações existem
  • Desenvolver intuição sobre o que acontece ao ajustar esses controles
• Não se deve virar apenas um criador de UI para saídas que não entende profundamente
  • Se alguém disser “o modelo entrega isso, então desenhe a interface”, é possível fazê-lo, mas não será possível propor melhorias com base em insights reais do usuário
  • O trabalho acabará sendo excessivamente reativo a mudanças posteriores no modelo
• É preciso fazer parte da decisão sobre se a nova funcionalidade é realmente desejada, e não ser apenas quem recebe a tarefa
• Isso pode ser difícil para designers sem familiaridade com código
  • É preciso ter interfaces como Langsmith ou aprender a rodar diretamente o ambiente de desenvolvimento

Casos de maior impacto

• Agente da Replit: ele convenceu a equipe a pedir que o usuário verificasse diretamente se o aplicativo gerado estava funcionando
  • Ao focar no caminho mais simples de validação pelo usuário, economizou-se muito esforço
• Lançamento do LaMDA (LLM inicial do Google): ele passou muito tempo testando o modelo de várias maneiras para descobrir o que funcionava melhor
  • Na época isso ainda não se chamava “prompting”, mas consistia em tentar fazer o modelo agir de forma confiável como se fosse outra coisa
  • O demo em que se podia conversar com Plutão ou suas luas foi o resultado de inúmeras tentativas até encontrar o que funcionava melhor
  • Sem ampla experimentação, não teria sido possível fazer escolhas estratégicas

O prompting para designers

• A pergunta “designers devem fazer prompting?” é diferente da pergunta “designers devem programar?”
• No caso da programação, a resposta é bem mais refutável: é possível construir XYZ com a tecnologia ABC? Perguntar a um engenheiro chega perto de saber diretamente
• O comportamento de modelos de IA é, por natureza, mais subjetivo e sutil
  • Não há substituto para entender esse material diretamente, em profundidade

Isso ainda é design?

• Trata-se de projetar comportamento, algo que pode nunca ficar perfeito — e tudo bem
• É uma mentalidade diferente do design de UI, em que se controla cada pixel e a perfeição é recompensada
• Ainda envolve fazer mockups e usar ferramentas de design
• Na Figma, ele cria casos de avaliação, revisa saídas e corrige partes estranhas
• É algo quase terapêutico, como um fidget spinner
  • Se lhe derem um mockup de site e 30 minutos, ele ficará feliz ajustando a tipografia
• É o tipo de trabalho que nunca termina de verdade, sempre passível de melhoria, a menos que a funcionalidade seja removida