Synthetic Users na prática
Um guia técnico de experimentação para testes de conceito, copy e usabilidade com IA
Eu não gosto de personas.
Não porque dá trabalho fazer. Dá, e muito. O problema pra mim é outro: ela não evolui. Ela congela um momento da jornada que deixa de existir rápido demais. Para usar personas no dia a dia, as pessoas têm que querer muito, rs. É um esforço miserável para outros times se quer lembrarem das personas. Imagina achar, entender e aplicar.
Se você já construiu personas baseadas em pesquisa real, sabe o que dá: entrevistas, síntese, documentação, validação. Horas organizando aprendizados, cruzando dados, discutindo detalhes. Aí o produto muda, a empresa pivota (passei por isso mais vezes do que queria), e aquela persona começa a ficar desatualizada. A atualização raramente acontece na mesma velocidade do negócio. O usuário muda, o produto muda, o contexto muda e fica um documento, ali existindo...
Pensa num exemplo simples. O Spotify existe pra ouvir música. Esse job (de Job to be done) das pessoas não mudou. Antes a gente lidava com isso por radiola (tu nem sabe o que é isso, né?!), depois walkman, depois iPod e por ai vai. A tecnologia mudou, o comportamento e contexto de uso mudou, mas a necessidade central continua a mesma. O que muda é como a pessoa usa o produto em cada etapa da jornada. No começo ela não sabe criar playlist. Depois já compartilha, descobre artistas, usa o Discover Weekly à vontade. E ela continua sendo a mesma pessoa em estágios diferentes da jornada, com comportamentos completamente distintos.
A persona normalmente captura um desses momentos e congela. Você desenha para a Ana que está no onboarding, mas três meses depois a Ana já não é mais essa pessoa no onboarding. Ela evoluiu. Só a persona não foi junto.
Foi por isso que eu fui para a escola do Job to be Done. E foi tentando resolver esse gap, entender rápido, evoluir rápido, sem depender de agenda, que comecei a explorar Synthetic Users.
Não como substituto de usuários reais. Nunca foi essa a intenção. Não estava tentando pular pesquisa ou substituir pessoas por máquina. O que eu precisava era acelerar entendimento, gerar hipóteses mais rápido e testar decisões antes de colocar algo no mundo.
O processo que vou mostrar aqui levou no máximo uma semana para sair do zero até a segunda versão dos perfis funcionando. Trabalhando 2-3 horas por dia, em paralelo com tudo mais que eu estava fazendo. Não precisa ser complexo, precisa ter boa base e começar simples até você e seu time calibrar os inputs, o método e os outputs da forma que vocês precisam.
Antes de continuar, deixa eu te situar no que você vai encontrar a partir daqui. Não vou falar de ferramenta, não vou vender IA como solução mágica e não vou defender que Synthetic Users substituem pesquisa real. O que vou mostrar é o processo como ponto de partida não como regra.
Nos próximos tópicos você vai ver:
Contexto do meu primeiro uso
O que são Synthetic Users
O viés de otimismo: o problema que ninguém te conta
Etapa 1: Curadoria antes da IA
Etapa 2: Definindo limites antes de pedir qualquer coisa
Etapa 3: Construindo os primeiros Synthetic Users
Etapa 4: Testando conceito, copy e usabilidade
O template de prompt que eu uso
Como evoluir os perfis ao longo do tempo
Ferramentas pra começar hoje
Contexto
Na época, eu estava como Founding Designer em uma healthtech. O foco era um app mobile para pessoas com diabetes tipo 1 aumentarem o engajamento com o tratamento e terem mais qualidade de vida.
Falamos de uma condição crônica, descoberta muitas vezes na infância, sem cura. Uma rotina diária de decisões. Contagem de carboidratos. Aplicação de insulina. Medo de hipoglicemia e hiperglicemia. Carga cognitiva constante.
A gente tinha múltiplos perfis convivendo dentro da mesma solução. Pessoas recém diagnosticadas. Pessoas que já viviam com a condição há anos. Pessoas que não aceitavam o diagnóstico. Médicos que precisavam acompanhar pacientes e ao mesmo tempo manter eficiência clínica.
A pergunta era sempre a mesma: estamos entendendo de verdade como essas pessoas pensam, decidem e agem com ou sem a nossa solução?
Recrutar usuários leva tempo. Entrevistas exigem agenda. Testes têm no-show. A coleta de dados qualitativos e quantitativos é lenta. E o produto não espera.
O problema não era falta de pesquisa. Era velocidade de síntese, atualização do conhecimento e como a empresa usava isso.
Foi aí que Synthetic User deixou de ser curiosidade, virou experimento e depois aprendizado prático.
Se você é designer, vai entender como acelerar discovery sem abandonar rigor. Se é founder ou trabalha com produto, vai enxergar como simular decisões antes de expor algo para o mercado. Se trabalha com marketing ou copy, consegue testar narrativas e objeções antes de colocar uma campanha no ar.
O que são Synthetic Users
No post dele, John Whalen descreve:
Meet synthetic users: AI-generated personas that mimic real people’s needs, behaviors, and preferences. These virtual allies are revolutionizing the way we approach feedback and design…
Synthetic Users são perfis gerados por IA que simulam comportamentos de um grupo de usuários.
Mas aqui vai um ponto importante:
Eles não substituem pesquisa real. Eles não criam empatia real. Eles não são validação final para tudo.
São hipóteses estruturadas para acelerar o conhecimento sobre o usuário. E, de quebra, tornam esse conhecimento mais acessível para outros times, porque transformam dados separados em algo que pode ser consultado, testado e evoluído.
Se forem mal alimentados, viram reflexo do nosso próprio viés. A IA não corrige erro de base, tá?! Ela amplifica elas, onde os dados rasos entram, dados rasos com certeza vão sair.
Personas x Synthetic Users
Não tem como não fazer a comparação, então segue a imagem com um resumo mais direto que eu pude fazer.
Mas existe uma diferença que não está na tabela.
Na prática, a persona representa um estado. O Synthetic User pode representar um comportamento em evolução.
Lembra do exemplo que dei agora a pouco da Ana usuária do Spotify? Se um usuário começa como iniciante e depois domina o produto, a persona normalmente não acompanha essa mudança, não sem muito esforço do time para atualizar todo o material (Manualmente). Já um Synthetic User pode ser atualizado com novos dados e evoluir junto com o produto com um clique.
O viés de otimismo: o problema que ninguém te conta
Antes de ir para o caso prático, preciso falar sobre isso porque você vai topar com ele, acho que em tudo que tem IA e Pesquisa junto.
O Synthetic User pode ter um viés de otimismo forte. Ele tende a achar que o usuário vai entender a proposta, que o fluxo vai fazer sentido, que a cópia vai ser clara. Isso acontece porque ele é gerado a partir de padrões, e padrões não capturam a desorientação real de alguém usando um produto pela primeira vez.
A saída são os guardrails: limites e direcionamentos explícitos que você define no prompt. Coisas como “simule um usuário que nunca ouviu falar desse conceito” ou “considere que essa pessoa foi diagnosticada há duas semanas” fazem diferença. E mesmo com guardrails, validar com usuário real continua sendo necessário. Mas você vai para essa validação com hipóteses muito mais afiadas.
A partir daqui você vai encontrar o processo completo por etapas, o caso de teste real com resultados, o template de prompt, como validei com usuários reais e o que aconteceu quando os insights bateram.
Também compartilho a estrutura de guardrails e como integrar isso com as ferramentas que você já usa.
Etapa 1: Curadoria antes da IA
O problema
Quando se fala em Synthetic Users, a tentação é abrir o modelo e começar a testar. É fácil. É rápido. Dá a sensação de produtividade, ali na hora.
Eu poderia ter feito isso.
Mas se eu tivesse começado pelo prompt, teria começado pelo lugar errado.
O risco não é a IA errar. O risco é você usar uma base rasa e depois confiar em algo que só reorganiza suposições que já estavam ali. Synthetic User não cria conhecimento do zero. Ele organiza o que você entrega.
Se a base for fraca, o resultado vai parecer sofisticado, mas vai continuar fraco.
Foi aqui que percebi que o problema não era “como usar IA”. O problema era: o que exatamente eu já sei sobre esse usuário?
O que eu fiz
Antes de abrir qualquer modelo, organizei o que já existia.
Dados públicos sobre diabetes. Livros que a gente usava como referência. Jornada mapeada. Anotações de entrevistas. Notas do time comercial. Observações minhas assistindo gravações de uso no UXCam. Exportações de dados quantitativos: entrei no Superset, criei filtros de data, exportei o que precisava anonimizado em CSV.
Nada glamouroso. CSV, documentos e organização manual.
Queria garantir que, quando eu pedisse para a IA simular comportamento, ela estivesse trabalhando sobre algo real. Não sobre memória estatística da internet.
A instrução central que dei ao modelo: use somente os dados que estou fornecendo. Não extrapole. Não invente.
Synthetic User nasce da curadoria. Não nasce do prompt.
A melhor forma de fazer
Não comece pela ferramenta.
Comece respondendo três perguntas:
O que eu já sei sobre meu usuário que está espalhado e não estruturado?
Quais dados qualitativos eu tenho acesso hoje e nunca usei direito?
Que comportamento real eu consigo observar no meu produto agora?
Depois disso, organize o mínimo necessário para que outra pessoa entenda aquele usuário sem você precisar explicar.
Uma prática que faz diferença aqui é a triangulação de dados (faço isso pra tudo que preciso pesquisar): cruzar pelo menos três fontes diferentes para confirmar um padrão antes de levá-lo para a IA. Entrevista qualitativa + dado de analytics + gravação de sessão, por exemplo. Quando três fontes distintas apontam para o mesmo comportamento, você tem base sólida. Quando só uma aponta, você tem hipótese, e hipótese não deve virar premissa. O NNGroup tem um artigo bom sobre triangulação se quiser aprofundar.
Só então leve para a IA.
O objetivo não é criar usuários sintéticos. É organizar conhecimento e depois simular cenários sobre esse conhecimento.
Dica extra: Conecte seu Design System com princípios e pilares de design do seu time. Isso é dado, sobre o que se esperar de qualidade e direcionamento da sua ferramenta.
Etapa 2: Definindo limites antes de pedir qualquer coisa
O problema
Você tem a base de conhecimento montada. A tentação agora é abrir o chat e soltar o prompt.
Não faz isso ainda.
O modelo vai usar qualquer coisa disponível para responder, incluindo o que aprendeu durante o treinamento, que é basicamente a internet inteira. Se você não definir os limites explicitamente, ele vai misturar seus dados reais com padrões genéricos de algum artigo de blog, e você não vai conseguir distinguir o que veio de onde.
O resultado parece bom. Parece fundamentado. Mas você não sabe de onde veio metade das afirmações.
O que eu fiz
Criei um projeto no ChatGPT e salvei todos os documentos da base de conhecimento dentro dele. Antes de fazer qualquer pergunta, defini as instruções de comportamento do agente:
Responda somente com base nos dados fornecidos
Quando não houver dado suficiente para uma afirmação, diga que não há dado
Sempre cite qual dado embasou cada característica do perfil gerado
Não extrapole comportamentos além do que os dados sugerem
No contexto de IA, essas instruções têm um nome: guardrails. São os limites que você define antes de pedir qualquer coisa, para que o modelo trabalhe dentro do que você quer, não do que ele acha que você quer. Você vai ver esse termo aparecer de novo no template de prompt mais pra frente. Mas ele nasce aqui.
Pedir o raciocínio por trás de cada geração foi o que me permitiu validar se o modelo estava sendo útil ou só reorganizando suposições que eu mesmo já tinha.
Quando ele dizia “esse perfil tende a evitar registrar a glicemia porque sente culpa” e eu perguntava “de onde veio isso?”, ele precisava me mostrar qual entrevista ou dado de uso embasava aquela afirmação. Se não conseguia mostrar, eu descartava ou marcava como hipótese a validar.
Dicas para você
Crie um projeto dedicado para cada produto ou contexto. Não misture bases de conhecimento diferentes no mesmo espaço. Se você usa os Synthetic Users para teste de conceito, copy e usabilidade, pensa em criar projetos separados com guardrails calibrados para cada objetivo. Os limites que fazem sentido para testar uma tela são diferentes dos limites para testar uma mensagem de WhatsApp.
Antes de fazer qualquer pedido, cole as instruções de comportamento. Se você usar o ChatGPT, as instruções personalizadas do projeto já fazem esse papel.
E sempre que o modelo trouxer uma afirmação sobre comportamento de usuário, pergunte: “qual dado embasou essa afirmação?” Se ele não conseguir responder com algo que você reconhece da sua base, trate como hipótese, não como dado.
Etapa 3: Construindo os primeiros Synthetic Users
O problema
Com o modelo configurado, a primeira geração raramente sai pronta. Ela sai crua.
Os primeiros perfis costumam ser razoáveis na estrutura, mas superficiais no comportamento. Descrevem o usuário de fora, como se estivessem lendo uma ficha, não como se conhecessem a pessoa. Faltam as nuances que fazem um perfil ser útil: o que essa pessoa sente quando trava, o que faz quando não entende, qual o momento em que desiste.
Se você aceitar a primeira geração como resultado final, vai usar um artefato que parece profundo mas não é.
O que eu fiz
O prompt inicial foi direto, sem tentar resolver tudo de uma vez:
“Transforme esses dados reais de uso em pelo menos 3 Synthetic Users. Para cada perfil: descreva o comportamento, dê um exemplo de uso prático, explique o processo de avaliação e dê opções de uso para cada Synthetic User.”
Depois dos primeiros rascunhos, comecei a iterar com frameworks que eu já usava.
Pedi para aprofundar com Job to be Done quebrado em funcional, emocional e social. Funcional é o que a pessoa precisa fazer. Emocional é o que sente enquanto faz. Social é como se posiciona em relação ao tratamento diante de outras pessoas, família, médico, amigos. Segue link para quem quiser saber e aprender mais sobre JTBD framework.
Depois pedi para conectar cada perfil ao AHA Moment dentro da jornada real do produto. Qual é o momento em que esse perfil sente que a ferramenta vale? Quando para de usar por obrigação e começa a usar porque faz sentido?
Por último, pedi grupos por comportamento para garantir diversidade: usuário novo, usuário engajado, usuário resistente.
Um exemplo do que saiu: Fernanda, 26 anos, vive com DM1 desde a adolescência, já tentou várias soluções mas se frustrou com respostas genéricas. O Job to be Done dela no nível emocional: quando registra a glicemia, quer saber se está boa ou ruim e receber uma recomendação para aquele momento específico. Não uma resposta genérica.
Isso não veio na primeira geração. Veio depois de duas ou três iterações pedindo mais profundidade emocional e pedindo que cada afirmação fosse embasada nos dados que eu havia fornecido.
Veja como as synthetic users se parecem. Link do exemplo da primeira interação no Canva do Chat GPT
Dicas para você
Não aceite a primeira geração. Trate como rascunho e itere. O modelo entrega estrutura na primeira passagem, não profundidade.
Para cada perfil, pergunte: “qual é o momento em que essa pessoa desiste?” e “o que ela faz quando não entende algo?” Essas duas perguntas forçam o modelo a sair da descrição genérica e ir para o comportamento real.
Essa é também a etapa onde os guardrails fazem mais diferença. O modelo naturalmente gera perfis otimistas, que assumem que o usuário vai entender a proposta e completar o fluxo. Para combater isso, seja explícito sobre o que você não quer ver:
“Não gere perfis que assumam que o usuário já conhece o domínio do produto”
“Inclua pelo menos um perfil que já tentou soluções parecidas e se frustrou”
“Para cada perfil, mostre onde ele desistiria, não apenas onde teria sucesso”
A diferença entre um guardrail vago e um útil é especificidade. “Seja realista” não funciona. “Inclua um perfil que usou o produto por duas semanas e parou” funciona.
E crie grupos por comportamento antes de criar grupos por demografia. Perfil por nível de engajamento com o produto é muito mais útil do que perfil por idade ou cargo.
Etapa 4: Testando conceito, copy e usabilidade
O problema
Você tem os perfis prontos. E agora?
A maioria das pessoas usa o Synthetic User só para criar os perfis e para por aí. Mas o valor real vem quando você usa esses perfis para simular interações com o produto antes de ir para o usuário real.
O risco de não fazer isso é levar para entrevista ou teste algo que ainda tem problemas óbvios. Você gasta tempo de recrutamento, agenda, energia do time para descobrir coisas que poderiam ter sido identificadas antes.
O que eu fiz
Estava desenhando uma tela que mostrava o impacto glicêmico dos alimentos. A lógica era: a pessoa com DM1 precisa calcular carboidrato antes de comer para saber quanto de insulina tomar. Mas o problema não era só o cálculo, era a educação. A maioria dos usuários não sabia que tapioca, apesar de pequena, tem pico glicêmico alto e demora a ser metabolizada.
A tela mostrava os ingredientes da refeição e um indicador visual de impacto glicêmico para cada um. Simples visualmente, complexo conceitualmente.
Antes de levar para usuários reais, rodei um teste com o Synthetic User. O prompt foi assim:
“Esqueça os testes anteriores dessa conversa e faça um novo teste com as seguintes instruções: 1. Quero testar se o conceito da tela que mostra o ‘impacto glicêmico’ da refeição/ingredientes transmite claramente o que é cada elemento, considerando que o termo ‘impacto glicêmico’ não estará descrito na tela. 2. Avalie se a tela: transmite claramente o impacto glicêmico de cada ingrediente, permite que o usuário entenda a diferença entre quantidade de carboidrato e impacto glicêmico, é útil para tomada de decisão. 3. Adicione algum perfil mais iniciante, que não entenda muito sobre diabetes. 4. Avalie também como um product design expert, levando em consideração os princípios de design que definimos para a Atri.”
O resultado:
Resultado completo do teste de conceito no chat gerou esse Canvas no Chat GPT
O modelo simulou a Mariana, perfil iniciante, recém diagnosticada, usando a tela. Ela entendeu as cores, mas travou na palavra “impacto”. Queria saber: “Tapioca tem impacto médio. O que eu posso substituir?”
Quando levei a tela para o WhatsApp, para um grupo de especialistas (enfermeiras, educadores, endocrinologistas) e para usuários finais, o feedback foi quase idêntico. Uma educadora disse exatamente isso: “Uma pessoa nova não sabe o que é impacto glicêmico. Precisaria de uma explicação antes.” Um usuário do grupo disse: “Eu vejo que a tapioca tem impacto médio. O que eu posso comer no lugar?”
Aqui funcionou para mim, não porque o Synthetic User foi perfeito, ele não foi. Mas porque me deu hipóteses precisas para levar para validação real onde as hipóteses mais se confirmaram do que foram refutadas.
Fiz o mesmo com copy. Tínhamos um bot no WhatsApp, que era o canal principal de comunicação com os pacientes. Antes de colocar qualquer mensagem no ar, eu colava o texto no chat e pedia para os perfis reagirem como usuários reais receberiam aquela mensagem.
O prompt era simples:
“Você acabou de receber essa mensagem do bot da (Startup) no WhatsApp: [mensagem]. Como você reage? Faz sentido? O tom está certo para o momento em que você está na jornada? O que te dá vontade de responder ou de ignorar?”
O que aparecia consistentemente: mensagens que pareciam claras para mim soavam clínicas demais para o perfil iniciante, ou genéricas demais para o perfil que já estava engajado há meses. Pequenos ajustes de tom e de momento de envio que o Synthetic User identificou antes de qualquer teste real com paciente.
Dicas para você
Use o Synthetic User para três tipos de teste antes de ir para o usuário real:
Teste de conceito: peça para o perfil interagir com uma tela ou fluxo e descrever o que entende de cada elemento. Onde ele travaria? O que não entenderia sem ajuda?
Teste de copy: cole o texto de uma notificação, onboarding ou campanha e peça para o perfil reagir. Ele entendeu a proposta? A promessa faz sentido para ele? O tom está certo para o momento da jornada?
Teste de usabilidade simulado: peça para o perfil completar uma tarefa específica e descrever cada passo. Onde ele hesitaria? Onde desistiria?
Em todos os casos, sempre inclua pelo menos um perfil iniciante e um perfil resistente. O viés de otimismo aparece nos perfis mais engajados. Os perfis de borda são onde os problemas reais aparecem.
O template de prompt que eu uso
Esse é o esqueleto que evoluiu ao longo dos meses, simplista, mas bom o suficiente para iniciar sua experimentação:
Contexto do produto:
[descreva o produto, o problema central que ele resolve e o público-alvo]
Base de conhecimento disponível:
[liste os dados que você forneceu: entrevistas, analytics, jornadas, documentos]
Instrução central:
Use somente os dados fornecidos. Não extrapole. Quando não houver dado, diga que não há dado.
Pedido:
Crie [X] Synthetic Users para [contexto específico].
Para cada perfil, inclua:
- Nome e dados demográficos básicos
- Job to be done funcional, emocional e social
- Comportamento típico com o produto
- Momento de AHA (quando esse perfil sente que o produto vale)
- Principal barreira ou frustração
- Cenário de uso: simule essa pessoa usando [funcionalidade específica]
Guardrails:
- Inclua pelo menos um perfil iniciante que não domina o domínio do produto
- Inclua pelo menos um perfil resistente ou cético
- Cite os dados que embasam cada característica relevante
- Ao simular uso, mostre onde a pessoa travaria, não apenas onde teria sucesso
- (se tiver DS) Ao analisar interface use o Design System: [link do Design system ou json com tokens + princípios] como fonte de verdade e qualidade.
Como evoluir os perfis ao longo do tempo
O problema
Você criou os primeiros Synthetic Users, validou com usuários reais, os insights bateram. Ótimo. Mas o produto continua evoluindo, o comportamento dos usuários muda e, três meses depois, aqueles perfis já não representam mais a realidade.
Se você não atualizar, vai acontecer exatamente o que acontece com a persona tradicional: o artefato fica bonito, salvo em alguma pasta, e ninguém mais consulta porque todo mundo sabe que está desatualizado.
A grande promessa do Synthetic User é justamente essa: ele pode acompanhar o produto em movimento. Mas só acontece se você alimentar o processo.
O que eu fiz
A cada 2-3 meses, eu exportava novos dados de uso do SuperSet, consolidava novas notas de entrevistas no Notion e alimentava o modelo com esse update. O pedido era direto: “Use esses dados para evoluir os Synthetic Users existentes. Se o comportamento de algum perfil mudou significativamente, reformule. Se houver um novo padrão que não cabia nos perfis anteriores, crie um novo.”
Com isso, a Mariana que era iniciante lá no começo foi evoluindo. Três meses depois, já não era mais novata. Estava engajada com o tratamento, criava suas próprias rotinas. O perfil mudou junto. E isso é exatamente o que eu reclamava da persona tradicional: ela não conseguia acompanhar esse movimento sem um esforço enorme.
Dicas para você
Crie um ciclo fixo de atualização, mesmo que simples. A cada sprint, trimestre ou milestone relevante, reserve um tempo para exportar novos dados e rodar o update. Não precisa ser todo mês. Precisa ser consistente.
Guarde as versões antigas antes de atualizar. Comparar a Mariana de três meses atrás com a Mariana de hoje é uma forma rápida de enxergar como o produto está afetando o comportamento real dos usuários. Isso vira insumo de retrospectiva e de planejamento.
E se um perfil mudar muito, não atualize: crie um novo e archive o antigo com a data. Perfis com data são muito mais úteis do que perfis sem contexto temporal.
Sobre dados sensíveis e privacidade
Uma pergunta que aparece sempre: e se os dados dos meus usuários são confidenciais?
Duas respostas práticas.
Antes de passar qualquer dado para o modelo, anonimize. Você não precisa do nome real do usuário para capturar o comportamento dele. Exporte sem informações de identificação pessoal. Isso resolve 90% da preocupação com LGPD.
E você pode instruir explicitamente o modelo a não usar informações pessoais identificáveis nos perfis gerados. O Synthetic User vai carregar o comportamento e o contexto, não o CPF do seu usuário.
O que fazer agora (sem automatizar nada ainda)
Faz manual primeiro.
Antes de pensar em N8N, Make, Zapier ou qualquer automação, você precisa entender se o processo funciona no seu contexto. Automação de coisa que não funciona só escala o problema.
A sequência que funciona:
Reúna os dados que você já tem: entrevistas passadas, analytics, jornadas, notas soltas
Crie um projeto no ChatGPT, NotebookLM, Claude, Gemini ou o que você ja usar e coloque a base de conhecimento lá
Gere os primeiros perfis com o template acima
Leia com atenção e valide contra o que você já sabe sobre os seus usuários
Ajuste os guardrails até os perfis fazerem sentido
Use esses perfis num teste de conceito antes de ir para usuário real
Compare os resultados
Se der certo, e eu acredito que vai pelo menos parcialmente, aí você começa a pensar em automação.
Ferramentas pra começar hoje
Saiba que existe ferramentas "prontas", exemplo: https://www.syntheticusers.com/
Mas é MUITO BOM para você, o time e o próprio resultado, você entender como tudo funciona. Então vamos lá!
Para produzir Synthetic Users, o ChatGPT com projetos foi o que eu usei. Simples, acessível, funciona bem com "RAG manual”. O NotebookLM é excelente para base de conhecimento, mas ainda sem automação nativa. O Delve.ai é mais especializado em personas e Synthetic Users. O UXPilot e o Maze AI têm funcionalidades de agentes para teste com perfis sintéticos.
Para alimentar com dados: qualquer ferramenta de analytics que você já usa, Amplitude, Mixpanel, Google Analytics, exporte os eventos relevantes. Notion, Confluence ou Google Docs e qualquer outro lugar que você armazene dados qualitativos. Há o Clarity (gratuito), Hotjar e Smartlook para anotações de comportamento via gravação de sessão.
O aprendizado que fica
Synthetic User não é bala de prata. Não substitui entrevista, não substitui observação, não substitui o contato com o usuário real.
Mas para quem não tem orçamento de pesquisa, prazo apertado ou simplesmente precisa gerar hipóteses antes de ir para o campo, ele pode levar o design e o produto para outro nível com surpreendentemente pouco esforço.
A condição é uma só: dados ruins entram, dados ruins saem. Invista na curadoria. Defina guardrails. Valide.
E não coloque tudo nas costas da IA sem validar o que ela gerou. Isso não é diferente do que você faria com qualquer estagiário talentoso. Você orienta, acompanha e confere o trabalho.
Se você quiser compartilhar como está usando Synthetic Users no seu contexto, me manda mensagem. Estou sempre testando e evoluindo os experimentos pra ter resultados melhores.
Referências: