De uns tempos para cá, quase toda conversa sobre produto chega à mesma pergunta: dá para fazer isso com IA? A pergunta é legítima. As ferramentas melhoraram rápido, e quem não testa fica para trás. Mas, na maioria das vezes, ela aparece cedo demais, antes de alguém ter respondido a pergunta que vem primeiro: qual problema estamos resolvendo, e para quem?

Num projeto recente aqui na Homem Máquina, o pedido era redesenhar um painel de dados para deixá-lo mais fácil de usar. Depois de ouvir os clientes, ficou claro que o problema não era usabilidade. Os clientes maiores exportavam tudo e refaziam a análise no Excel. O problema era escala e saída de dado. Se tivéssemos começado pela ferramenta, teríamos entregado telas mais bonitas para o problema errado.

Depois de muitos anos traduzindo necessidade de negócio em produto digital, cheguei a um jeito simples de organizar essa conversa. Eu chamo de pessoas antes, pessoas depois.

As três partes do trabalho

Todo projeto de produto tem três partes. Elas se misturam no dia a dia, mas pedem coisas diferentes.

  1. Antes: entender o problema. Quem sofre com ele, o que já foi tentado, o que o negócio precisa que mude, o que não pode mudar.
  2. Meio: produzir. Pesquisar, organizar informação, desenhar fluxos, gerar variações, prototipar, escrever, testar.
  3. Depois: decidir. Escolher um caminho, assumir o risco, responder pelo resultado.

Quem trabalha com design vai reconhecer aqui o Double Diamond, o modelo de duplo diamante criado pelo Design Council, do Reino Unido. O primeiro diamante abre e fecha o problema: descobrir e definir. O segundo abre e fecha a solução: desenvolver e entregar. Pessoas antes é o primeiro diamante inteiro. A IA brilha na abertura do segundo, quando é preciso gerar e comparar muitas alternativas. Pessoas depois é o fechamento: testar com quem usa e decidir.

Double Diamond: o primeiro diamante (descobrir e definir) é pessoas antes; a abertura do segundo (desenvolver) é onde a IA acelera; o fechamento (entregar) é pessoas depois. Descobrir Definir Desenvolver Entregar Pessoas antes IA acelera Pessoas depois desafio problema certo solução validada
Double Diamond, do Design Council, com as três partes do trabalho.

Uso o Double Diamond no meu processo há muitos anos, bem antes de a IA entrar no dia a dia. E acho curioso como um modelo criado há mais de vinte anos continua tão atual. A IA mudou a velocidade, principalmente na hora de abrir alternativas no segundo diamante. Mas não mudou a lógica: ainda é preciso entender o problema antes de buscar a solução, e testar a solução antes de decidir. Se algo mudou, foi o risco de pular o primeiro diamante, porque ficou fácil demais gerar soluções.

A IA é extraordinária no meio. Ela encurta horas de trabalho em minutos e abre opções que um time pequeno não teria tempo de explorar. No antes e no depois, ela ajuda, mas não substitui quem está na sala.

Antes: a pergunta certa não está nos dados

Uma ferramenta de IA responde muito bem a perguntas. O difícil é saber qual pergunta importa para o seu negócio, neste momento, com estas restrições. Esse contexto quase nunca está escrito: está na conversa com quem vende, com quem atende, com quem usa o produto todos os dias, e em tudo o que as pessoas não dizem numa reunião.

Traduzir isso em uma definição clara de problema é o trabalho que mais economiza dinheiro num projeto. E é trabalho de gente.

Aqui na Homem Máquina, todo projeto começa por um discovery, e ele começa por dentro. Primeiro conversamos com quem vive o produto do lado do cliente: quem vende, quem atende, quem apresenta o produto toda semana. Às vezes pedimos uma demonstração ao vivo e só observamos onde a pessoa precisa explicar na mão o que a tela deveria dizer sozinha.

Essas conversas levantam hipóteses, mas não fecham nada. A regra é não definir personas só com a visão interna. Elas só ficam prontas depois que falamos com quem usa de verdade. Nas entrevistas, seguimos alguns princípios simples:

  • Comportamento antes de opinião. Pedimos para a pessoa reconstituir uma situação real antes de perguntar o que ela acha.
  • Não conduzir. Perguntamos "o que você faz nesse momento?" em vez de apontar o caminho.
  • Silêncio é dado. Esperamos a pessoa pensar e não preenchemos a pausa.

Tudo isso vai para um mapa coletivo, montado com o cliente: cenários de uso, dores, o que é certeza, o que é suposição e o que ainda é dúvida. O resultado não é uma lista de telas. É uma lista de perguntas do tipo "como poderíamos…", que diz o que vale a pena resolver primeiro.

A IA ajuda bastante nessa fase, organizando material e cruzando informações. Mas ela não faz a entrevista, não percebe a hesitação de quem está explicando um processo e não decide o que é prioridade. Foi assim naquele projeto do painel de dados que contei no começo: antes de mexer em qualquer tela, fomos ouvir clientes-chave e os diferentes perfis que usam o produto.

Meio: onde a IA acelera de verdade

É aqui que eu testo tudo cedo, e separo o que funciona do que é fogo de palha. Na prática, a IA me ajuda a:

  • organizar e resumir material de pesquisa;
  • gerar muitas variações de um fluxo ou de um texto para comparar;
  • sair do papel para um protótipo navegável em pouco tempo;
  • revisar consistência, linguagem e casos que esquecemos;
  • acelerar o próprio processo de design, dentro das ferramentas que o time já usa, como o Figma.

No meu dia a dia, uso o Claude e o ChatGPT para pensar junto, organizar pesquisa e revisar textos. Com o Claude Code, o VS Code e o GitHub, saio do desenho direto para protótipos em código. E o Figma, com o FigJam, segue como o lugar onde o time desenha, homologa e mantém o design system.

O ganho é real. Mas velocidade no meio só vale se o antes estiver certo. Caso contrário, a IA só ajuda a chegar mais rápido no lugar errado.

Figma ou direto no código? Depende do projeto

Aqui na Homem Máquina, essa pergunta aparece cada vez mais. Com IA, já dá para pular etapas: sair de uma conversa direto para um protótipo em código, sem passar pelo Figma. Às vezes é exatamente o que o projeto pede. Às vezes é um atalho que custa caro depois.

Não existe resposta única. Quem decide é o contexto de cada projeto:

  • O legado. Se o cliente já tem um design system no Figma, ou um produto com anos de história, a ferramenta precisa conversar com o que existe.
  • O cliente. Quem vai manter aquilo depois? Que time existe do outro lado, e que ferramentas ele domina?
  • As regras. Muitos clientes têm políticas próprias sobre onde os dados podem estar e quais ferramentas de IA são permitidas. E nós temos as nossas. As duas valem, e a mais restritiva manda.

Nesse mesmo projeto, o protótipo navegável usado nas conversas com usuários foi montado com o Claude, direto em código, em três ou quatro dias. As telas continuaram sendo homologadas no Figma do cliente, porque é lá que o designer deles trabalha. Uma ferramenta não substituiu a outra: cada uma ficou com a parte em que é melhor.

Escolher a ferramenta também é uma decisão de produto. E, como toda decisão, é trabalho de gente.

Depois: decidir é assumir

A IA pode te dar dez opções em segundos. Escolher uma delas é outra coisa: é dizer "vamos por aqui" sabendo o que se ganha e o que se perde. Essa escolha envolve critério, contexto e responsabilidade. Quando o resultado não vier, alguém precisa responder por ele, e esse alguém não é a ferramenta.

E decidir bem não é decidir sozinho. Antes de bater o martelo, a gente volta às pessoas. Aqui na Homem Máquina, depois de projetar vem a validação: sessões individuais, com usuários reais, sobre um protótipo navegável. Algumas coisas fazem diferença:

  • Voltar a quem participou do discovery. Assim cada dor levantada lá no começo tem a chance de ser checada por quem a sentiu.
  • Trazer também alguém de fora. Uma pessoa sem histórico com o projeto mostra o que fica claro sem nenhuma explicação.
  • Tarefa antes de opinião. A pessoa tenta fazer algo real na tela antes de dizer se gostou.
  • Critério de sucesso definido antes. Combinamos o que conta como "resolvido" antes da sessão, para não decidir no calor do momento.

No fim, cada dor do discovery recebe um veredito: resolveu, resolveu em parte, não resolveu, ou apareceu um problema novo. E encerramos agradecendo, sem prometer que tudo o que foi dito vira funcionalidade. Depois, acompanhamos a implementação, porque o que foi desenhado precisa chegar inteiro ao produto.

A IA pode sugerir o que um usuário faria. Só o usuário mostra o que ele faz de fato.

Por isso, no meu trabalho, quem decide no final é sempre uma pessoa. Não porque eu desconfie da tecnologia, mas porque toda decisão precisa de alguém que responda por ela.

Quatro perguntas antes de "colocar IA" em um projeto

Se você lidera um negócio e está avaliando usar IA em um produto ou processo, comece por estas:

  1. Qual problema, de quem? Se a resposta não cabe em uma frase, ainda é cedo para escolher ferramenta.
  2. Que parte do trabalho vai ficar mais rápida? Se for o meio, ótimo. Se for o antes ou o depois, desconfie.
  3. Que regras valem aqui? Veja o que a sua empresa permite sobre dados e uso de IA, e alinhe isso com os parceiros e fornecedores que vão trabalhar no projeto.
  4. Quem decide no final? Defina antes de começar quem olha o resultado e responde por ele.

IA com critério não é usar menos IA. É saber onde ela entra. Pessoas antes, pessoas depois.