Pesquisa de UX precisa entrar no loop do desenvolvimento turbinado por IA, propõe NN/G

Quando um agente de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → consegue implementar uma funcionalidade numa tarde, o modelo clássico de pesquisa (estudar antes, só então construir) perde sentido prático. É esse o problema que o Nielsen Norman Group (NN/G) coloca num artigo publicado em 13 de novembro de 2026 por Tony Alicea, que batiza a solução proposta de research-in-the-loop.

O ponto de partida é uma mudança de economia, não de ferramenta. Por boa parte da história do software, construir era caro e corrigir um erro depois do lançamento custava ainda mais caro: dinheiro, tempo, confiança do cliente. Por isso a pesquisa formativa vinha antes do código. Com agentes de IA escrevendo grande parte da implementação, esse cálculo mudou: muitos times hoje escolhem uma direção, publicam, observam o que acontece e ajustam, porque iterar ficou barato.

O problema que a velocidade cria

O texto da NN/G usa uma analogia simples: fotografia em filme exigia cuidado em cada clique, porque cada exposição custava caro e o resultado só aparecia depois da revelação. A fotografia digital trocou isso por dezenas de cliques, ajuste e novo clique, quase sem custo. Desenvolvimento de software com agentes de IA está passando pelo mesmo tipo de virada: construir, lançar, observar o dashboard, corrigir.

O problema é que um dashboard mostra o que aconteceu, não por quê. Uma equipe pode ver que usuários abandonaram um fluxo sem enxergar o que eles tentavam fazer ou o que os confundiu. Essa é a pergunta que a pesquisa sempre respondeu, e ela não desaparece só porque o ciclo de entrega ficou mais curto. Construir a coisa errada rapidamente ainda é um fracasso, só que mais rápido.

Diferente de uma foto ruim, um release ruim chega a pessoas reais.

Tony Alicea, autor do artigo, Nielsen Norman GroupUnlike a bad photo, a bad release reaches real people.

O que é research-in-the-loop

A proposta do NN/G parte de uma inversão: em vez de a pesquisa sempre preceder o desenvolvimento, ela entra na própria especificação da funcionalidade. Antes da construção, a pesquisa ajuda a definir o que aquele release precisa capturar. Durante a construção, o agente de código implementa essa captura junto com a funcionalidade. Depois do lançamento, pesquisadores analisam o que aconteceu, e o aprendizado alimenta os próximos requisitos.

O artigo organiza essa atividade em três tipos, que se complementam mas não se substituem:

Instrumentação torna avaliação e investigação mais eficientes, mas não substitui descoberta independente: ela só revela o que foi desenhada para medir.

Como fica uma especificação com pesquisa embutida

O artigo traz um exemplo concreto: um produto de help desk onde departamentos antes precisavam passar tickets por uma fila central e passa a permitir transferência direta entre eles. Como a funcionalidade será construída rapidamente por um agente de IA, o time escreve, junto do spec de produto, uma seção de pesquisa que o próprio agente lê para instrumentar o código. Traduzindo o exemplo da NN/G:

## Pesquisa

O que esperamos: transferência direta entre departamentos leva o
ticket ao time certo mais rápido, com menos repasses.

Sinais de que funcionou: menos tempo entre abertura e resolução;
menos tickets passando por três ou mais departamentos; custo
médio de suporte por ticket mais baixo.

Sinais de problema: mais tickets devolvidos para revisão ou
reabertos pelo cliente.

O que rastrear: cada repasse (quem enviou, quem recebeu, tempo de
espera, se foi devolvido), num dashboard simples agrupado por
departamento, para orientar com quem conversar.

Quando falar com pessoas: se um departamento devolve uma fração
alta de tickets, ou eles empacam ali, marcar entrevista contextual
com a equipe daquele departamento.

Com essa seção, o mesmo agente que implementa a transferência de tickets já constrói o log de eventos, o dashboard e a pergunta de devolução. A pesquisa deixa de depender de uma fila separada de tempo de engenharia.

Vale notar o limite que o próprio NN/G marca: esse spec não é um desenho de avaliação completo. Ele diz o que medir, não se a mudança observada foi causada pela funcionalidade nova ou por sazonalidade, mudança de equipe ou outro fator. Isolar causa de correlação ainda exige grupo de comparação, tamanho de amostra e período de observação, decisões que continuam sendo trabalho de pesquisador, não do agente.

Onde entra o trabalho qualitativo

Instrumentação cobre só o que o release foi desenhado para capturar: mostra o que as pessoas fizeram, não por quê. O artigo descreve três formas de encaixar pesquisa qualitativa no loop, que podem rodar em paralelo:

• Cadência: sessões em ritmo fixo (semanal, por exemplo), não amarradas a um release específico, para checar fluxos críticos e a saúde geral da experiência.
• Sinais: dados de release ou feedback que apontam algo estranho (um departamento onde tickets empacam, um grupo que se comportou fora do esperado) disparam uma rodada de investigação.
• Decisões: escolhas difíceis de reverter (preço, promessa ao cliente, tratamento de dado sensível, um modelo mental novo) merecem evidência antes do comprometimento, muitas vezes via protótipo que o próprio agente constrói rapidamente.

Um time que só segue sinais acaba estudando apenas o que decidiu instrumentar, e é aí que a descoberta aberta continua sendo insubstituível.

O que muda para quem faz produto e design

Para quem desenha a experiência ou decide o que será construído, a seção de pesquisa passa a viver ao lado do contexto de UX↳UX33 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025UX, IA e Front-End: quando experiência, inteligência e código se encontram para criar o futuro digitalProduto & UX · jul 2025Novidades em UX/UI para 2025: O futuro do design de experiências digitaisProduto & UX · abr 2025Ver tudo em Produto & UX → e dos requisitos de produto, como parte do que o time constrói, não como etapa que atrasa o build. Isso exige do pesquisador fluência em spec e markdown, noção básica de Git, instrumentação de analytics (eventos, coortes, feature flags, rollout gradual) e entendimento de quem tem acesso a quais dados via API ou MCP.

O artigo é claro que isso não substitui a espinha dorsal da profissão: fazer boa pergunta, evitar viés, desenhar experimento quantitativo sólido, sintetizar com julgamento e manter prática ética de pesquisa. Um agente constrói uma pesquisa em minutos; quem responde pelas perguntas certas continua sendo o pesquisador.

Embora o artigo não trate de acessibilidade diretamente, a lógica se aplica sem esforço a esse terreno: se a instrumentação já nasce na spec, nada impede que critérios de acessibilidade (uso de leitor de tela, navegação por teclado, contraste em componentes novos) entrem como sinal a rastrear desde o primeiro dia, em vez de virarem auditoria avulsa depois do lançamento. É uma leitura que o material sugere, mais do que afirma.

O que fica em aberto

O próprio NN/G admite que o modelo é uma proposta, não um playbook fechado. Entre as perguntas sem resposta: quem é dono da seção de pesquisa (pesquisador, PM, os dois?); como evitar que instrumentação em excesso vire sensação de vigilância para quem usa o produto; e o que acontece com pesquisa generativa e longitudinal, que não cabem claramente em nenhum dos três tipos (avaliação, investigação, descoberta).

O artigo termina sugerindo um primeiro passo pequeno: mapear onde o sinal de usuário já existe, escrever uma única seção de pesquisa (hipótese, critério de sucesso e de dano, o que rastrear, quando falar com gente) e levá-la ao time que vai construir o próximo release, antes de tentar reorganizar todo o processo de pesquisa da empresa de uma vez.

Fonte: Nielsen Norman Group