Na Tradeverifyd, a IA era parte essencial de como o time trabalhava, e o design precisava acompanhar o ritmo sem perder a voz. Reorganizei meu jeito de trabalhar em volta disso: desenhar dentro do próprio produto, ouvir toda conversa com cliente através de agentes, e escrever meu julgamento de design onde o time inteiro, e os agentes dele, podiam usar.
Papel
Staff Product Designer
Quando
Maio a outubro de 2026
Produto
Plataforma de inteligência de supply chain, B2B
Feito com
Claude Code, GitHub, Storybook
84pull requests abertos como designer, 65 com merge
1.000+reações ao artigo sobre esse jeito de trabalhar
Contexto
O time não usava Figma. A plataforma mudava tão rápido que qualquer arquivo de design ficava defasado em relação ao que estava no ar, e uma designer trabalhando lá vira gargalo. A IA era parte essencial de como a engenharia trabalhava.
Eu fiquei com o trabalho inteiro de designer: enquadrar o problema, definir a direção, decidir cada tela e segurar a qualidade do que ia pro ar. O Claude Code transformava essas decisões no produto real, o que me deixou desenhar na velocidade em que o time construía.
Parte 1
Design dentro do produto, não do lado
Como eu trabalhava
Dependia do trabalho e do prazo.
Pra um conceito novo, eu começava no papel. Desenhava no caderno, um agente de IA transformava o desenho em wireframe, e eu usava isso pra validar a hipótese antes de construir qualquer coisa. Depois construía no produto real.
Pra uma mudança que precisava sair na mesma semana, eu ia quase direto pra construção. O Claude Code construía a mudança numa branch do produto real, com os componentes reais, e eu revisava como antes e depois, com telas reais.
Nos dois casos, a engenharia seguia dali, o backend, os testes e os detalhes de produção, às vezes a partir de uma branch pronta, às vezes a partir de issues com prints e critérios de aceite. A gente testou os dois jeitos e foi ajustando pro que atualizava o produto melhor.
O jeito de sempre
IdeiaUm problema pra resolver
MockupDesenhado num arquivo
HandoffSpecs e marcações
RefazerA engenharia redesenha em código
DesvioO arquivo e o produto se separam
Um conceito novo
EsboçoNo papel, no meu caderno
WireframeUm agente de IA desenha a partir do esboço
ValidarTestar a hipótese primeiro
ConstruirNo produto real, com o Claude Code
PassarUma branch pronta ou issues
Uma mudança pra esta semana
Tela realComeçar do produto no ar
ConstruirO Claude Code constrói numa branch
RevisarAntes e depois, telas reais
PassarUma branch pronta ou issues
Redesenhado. O jeito de sempre, com handoff (em cima), e os meus dois caminhos, dependendo do prazo.
Regras que eu mantive
Nada visual vai pro ar sem eu ver. Toda mudança chegava primeiro pra mim como antes e depois.
Componentes reais ou nada. Um protótipo feito com as peças reais mostra o que o produto consegue fazer de verdade, e cada contorno ganhava uma nota pra engenharia.
Nunca inventar dado. As telas usam o formato real do dado. Se o dado não sustentava um design, isso virava uma issue, não um número falso.
Uma descoberta vira uma issue. Com critérios de aceite, backend incluído, pra nada depender de alguém lembrar de uma reunião.
Parte 2
Ouvir todo cliente, mesmo sem estar na sala
O que eu construí
Eu participava de algumas calls com clientes, mas não conseguia estar em todas. Os times de vendas e de customer success conversavam com clientes toda semana, com pessoas de várias empresas diferentes, e a maior parte dessas conversas era transcrita. Então juntamos todas as anotações deles numa pasta compartilhada, e eu criei agentes que liam essas notas, agrupavam o que os clientes diziam por tema e tipo de dor, e ligavam cada dor às issues que já estavam resolvendo aquilo.
Toda semana eu rodava e publicava o resultado no GitHub, onde o time inteiro conseguia ver o que os clientes estavam pedindo, agrupado pela reunião de onde veio. A IA virou os meus olhos e ouvidos nas conversas em que eu não estava, e as decisões de design passaram a partir do que os clientes realmente diziam.
Toda semana
CallsVendas e CS conversam com clientes
NotasTudo numa pasta compartilhada
AgentesLeem todas as notas, toda semana
DoresAgrupadas por tema e tipo
IssuesLigadas ao trabalho, no GitHub
Redesenhado. De notas de call espalhadas a dores de cliente ligadas ao trabalho.
Parte 3
Julgamento de design que o time todo usa
Por quê
Quando a IA faz parte do jeito como todo mundo trabalha, a alavanca não é desenhar mais rápido. É colocar julgamento de design onde a IA lê. Então escrevi o meu, com as minhas palavras, e transformei em ferramentas que o time usava todo dia.
Meu julgamentoescrito com as minhas palavras
Julgamento de designo que a Giulia faria, aplicado a qualquer tela
UX writertexto de produto curto e simples
Revisor do design systemcheca toda mudança, parte do DS Police
Toda mudançarevisada com o mesmo olhar, por qualquer pessoa do time
Redesenhado. O julgamento de uma designer, usado por três agentes, em toda mudança.
O que o julgamento diz
O essencial cabe num cartão. São as regras que os agentes aplicam, e as que eu mesma aplico.
Bom design é invisívelVocê olha, respira, entende.
Ajudar a decidirToda tela leva a uma ação, não só a mais dado.
Confiança pra decidirDá pra levar isso pro meu chefe?
Toda ação legívelO que é clicável parece clicável. Racione a cor principal.
Espaço, tamanho, peso, corNessa ordem, pra criar hierarquia.
Agrupar com espaço, não com caixaCaixa não é organização.
Desenhar os estados esquecidosVazio diz por quê, erro diz o que fazer.
Nunca só corSempre com um texto ou um ícone junto.
Redesenhado. Oito regras do julgamento de design que os agentes usam.
Parte 4
Falando disso em público
O artigo
Escrevi sobre esse jeito de trabalhar no LinkedIn, em português e inglês: o que mudou quando uma product designer parou de usar o Figma. Passou de 1.000 reações somando as duas versões, e ainda é a primeira coisa que as pessoas comentam quando falam comigo.
84 pull requests de uma designer, 65 com merge, e 151 issues que transformaram decisões de design em trabalho que a engenharia conseguia pegar. Três agentes de design que o time todo usou, um deles parte do DS Police. Um ciclo semanal que transformava calls com clientes em dores ligadas ao trabalho. E um jeito de trabalhar que deixou uma designer acompanhar o ritmo de um time que trabalhava com IA todo dia.
A alavanca não é desenhar mais rápido. É colocar julgamento de design onde o trabalho acontece.
O que eu levei comigo: ferramenta muda, e tudo bem. O trabalho continua sendo decidir o que é bom, e garantir que vá pro ar desse jeito.