Em 11 de setembro de 2026, a Nielsen Norman Group publicou um artigo da Megan Chan chamado Test Complex Interactions Earlier with AI Prototyping. A tese: ferramentas de IA tornam viável construir protótipos interativos completos de interfaces complexas, para testar com usuários mais cedo no processo de design. O texto documenta três casos, dois na Ramp e um em Purdue, e propõe um processo de cinco passos. Vou destrinchar o mecanismo, mostrar onde a coisa realmente muda de patamar e onde ela quebra.
O que muda quando o protótipo vira código de verdade
Antes de ferramentas como Cursor, v0, Bolt e Figma Make, prototipar uma interface complexa em Figma significava desenhar telas estáticas e ligar com setinhas. Você conseguia representar um caminho feliz, dois no máximo. Se o produto era um filtro com 27 atributos e sub-atributos aninhados (esse é literalmente o caso de Purdue que a NN/G descreve), você não prototipava, você desenhava um mock e torcia.
O que mudou não foi “a IA desenha melhor”. O que mudou foi que a saída deixou de ser imagem e passou a ser código executável. Um prompt bem construído em v0 devolve componentes React em shadcn/ui prontos para rodar. Um pedido em Cursor devolve arquivos que você edita, comita e serve. O protótipo passa a ter estado.
Uma analogia que ajuda: é a diferença entre uma maquete de arquitetura em papelão e uma casa com encanamento provisório. Na maquete você aponta a porta. Na casa provisória você abre a porta, entra, e descobre que o corredor é estreito demais para passar com a mão ocupada. Onde a analogia quebra: casa provisória exige alvará, protótipo de IA você joga fora na sexta.
Por que interfaces com filtro, dashboard e chat são o caso ideal
Esses três tipos têm em comum uma coisa: o número de estados possíveis é grande demais para desenhar tela por tela. Um filtro com sete critérios booleanos já tem 128 combinações de estado ligado/desligado, antes de considerar valores. Um chat de IA é pior, porque a interface tem que gerar uma resposta razoável para praticamente qualquer input do usuário e pode até produzir saídas diferentes para o mesmo input. Ferramentas de design tradicionais, limitadas a um conjunto fixo de telas pré-construídas, não capturam esse comportamento aberto e não determinístico.
É por isso que na Ramp, segundo o relato da NN/G, o designer Andrew Lucas usou Cursor para prototipar uma interface de IA conversacional conectada a um agente que produzia saídas não determinísticas, imitando o produto real. O protótipo não simula respostas, ele chama um modelo. E o participante do teste digita o que quiser, não o que o script prevê.
O processo de cinco passos, com foco no que realmente pesa
O artigo da NN/G descreve cinco passos. Reordeno por peso relativo:
- Decidir o que o protótipo precisa fazer. Nem toda pergunta de pesquisa exige interatividade. Se a dúvida é sobre nomenclatura de rótulo, wireframe estático resolve. Se é sobre como o usuário compõe filtros, não resolve.
- Tomar as decisões de design antes de abrir a ferramenta. Layout, hierarquia, interações, estados vazios, estados de erro. A NN/G é direta: a qualidade do prompt depende do pensamento feito nesta etapa.
- Reunir os dados. Exportar dado real do produto (respeitando política de privacidade, nada de PII) ou pedir a um LLM que gere um dataset sintético.
- Escrever o prompt e anexar os dados. Markdown é o formato que LLM parseia melhor. Anexar sketches, wireframes ou telas existentes ajuda.
- Iterar. A primeira saída raramente acerta tudo.
O passo 2 é o que separa protótipo utilizável de gerador de tela genérica. Um prompt vago devolve dashboard genérico com card, gráfico e tabela, todos no mesmo peso visual. Um prompt que descreve estados devolve algo testável.
Um esqueleto de prompt que funciona
# Interface: editor de política de despesas
## Layout
- Coluna esquerda (320px): lista de políticas existentes
- Área central: chat com o assistente
- Coluna direita (400px): preview da política em edição
## Comportamento
- Ao digitar no chat, o assistente propõe alterações
- Cada alteração aparece como diff no preview (verde=adicionado, vermelho=removido)
- Usuário pode aceitar ou rejeitar cada diff individualmente
## Estados
- Vazio: nenhuma política selecionada, mostrar CTA "criar política"
- Carregando: skeleton no preview enquanto o LLM responde
- Erro do LLM: mensagem inline no chat, botão "tentar de novo"
- Conflito: se duas regras se contradizem, banner amarelo no topo
## Dados
[anexar arquivo policies.json com 12 exemplos]
## Stack
React + Tailwind, componentes de shadcn/ui
Repare que metade do prompt é sobre estado, não sobre estética. É aí que o protótipo vira ferramenta de pesquisa.
O que isso significa na prática
Na Ramp, segundo o relato da NN/G, o redesenho do editor de política focou em editar uma política através de chat com IA. Como a edição baseada em conversa dependia de respostas dinâmicas da interface, era difícil de simular com telas estáticas. Durante o teste, os participantes recebiam um link do protótipo carregado com dados próprios sanitizados, e o protótipo operava como o produto real, permitindo aos participantes interagirem naturalmente e dar feedback preciso. A descoberta chave foi que a maneira de rastrear e exibir edições estava confusa, algo que o time não teria encontrado com tela estática.
No caso Purdue, os pesquisadores construíram a mesma interface duas vezes: primeiro estática em Figma, depois interativa com v0 e Bolt. A NN/G alerta que este foi um estudo de caso sequencial focado num único projeto, não um experimento controlado, e portanto o exemplo deve ser interpretado como ilustração do que se tornou viável construir e testar, não como evidência de que a prototipagem com IA produz melhor pesquisa. Vale registrar essa nuance, o artigo original não vende milagre.
Do meu lado, o que me faz levar isso a sério é experiência de A/B. Rodando teste A/B por anos num fluxo de assinatura, com mesmo backend, mesma API, duas interfaces diferentes, a receita saía mensuravelmente diferente. Se o valor estivesse todo atrás da API, os dois lados dariam o mesmo número. Não davam. O que a NN/G descreve é a versão em pesquisa disso: quando você deixa o usuário tocar em algo que responde de verdade, o feedback muda de qualidade, porque a interface passa a carregar informação que a tela estática não carrega.
O que as imagens do artigo original mostram
Para quem não vai abrir o link: as figuras comparam duas fases do caso Purdue. Na fase 1, wireframes estáticos em Figma mostram um mapa com painel lateral de filtros (localização, período, tipo de evento). O usuário vê o layout mas não consegue clicar. Na fase 2, protótipos gerados com v0 e Bolt mostram a mesma ideia mas com filtros que aplicam de verdade sobre um dataset sintético, atualizando o mapa e as estatísticas. É a diferença entre “aqui vai ter um filtro por gravidade” e “selecione gravidade alta e veja o mapa reagir”.
Onde isso quebra
Alguns pontos que o artigo toca de leve e que merecem peso maior:
A armadilha da fidelidade
A NN/G nomeia isso de fidelity trap: protótipos gerados por IA podem parecer completos enquanto introduzem todo tipo de suposição e imprecisão, como usar o padrão de design errado para a situação, criar uma hierarquia confusa ou repetir elementos desnecessariamente. O risco social é pior que o técnico: alguém em reunião pergunta “dá para subir isso?” e a resposta correta (“não”) passa a exigir explicação.
Isso conecta a uma coisa que raramente é dita: quase nenhum engenheiro de IA tem design system publicado e style guide de interface, e é por isso que quase toda interface de produto com agente é feia. O protótipo gerado por IA herda esse problema em escala, porque o modelo preenche a lacuna com o que ele viu, e o que ele viu é média de internet. Se você não impõe o sistema no prompt, ele impõe o sistema dele.
Custo e latência do próprio protótipo
Iterar em v0 ou Cursor consome créditos, tempo e paciência. A literatura recente sobre vibe coding registra que uma experiência comum é a de struggle com o prompt e iteração, com projetos exigindo dezenas ou até centenas de iterações antes da saída ficar utilizável. Para protótipo descartável isso é aceitável. Para protótipo que vai ser mantido durante meses de pesquisa, não é.
Dados reais versus dados sintéticos
Subir dado real acelera a resposta do usuário no teste, porque ele reconhece o próprio contexto. Mas exige revisão de política de privacidade da sua empresa e revisão da política do fornecedor de IA (quem treina em cima do quê). Dado sintético evita o problema mas frequentemente é bonito demais, sem os casos degenerados que só existem em produção (nome com 80 caracteres, valor negativo, campo nulo onde não deveria).
O protótipo não é o produto
A literatura sobre vibe coding é bem consistente aqui: vibe coding pode levar a dívida técnica, código não manutenível e produtos com bugs ou inseguros, incluindo casos como senhas armazenadas em texto puro. Protótipo para pesquisa é uma coisa. Empurrar isso para produção é outra, e é onde o “dá para subir?” mata projeto.
O que não dá para afirmar ainda
O artigo da NN/G descreve três casos, e é honesto ao dizer que o de Purdue não é experimento controlado. Não temos dados públicos comparando taxa de descoberta de problema de usabilidade entre protótipo estático e protótipo interativo com amostra grande, mesmo protocolo e mesma tarefa. A intuição de que interativo descobre mais é forte e consistente, mas o tamanho do efeito não está quantificado.
Também não está claro em qual ponto do funil de complexidade o protótipo interativo compensa o custo. Para uma tela de login com um campo, obviamente não. Para um dashboard com sete filtros aninhados, obviamente sim. No meio, a decisão ainda é gosto informado, não critério.
Por fim, o efeito de longo prazo na equipe é uma incógnita. Se o time de design passa a entregar protótipos que rodam, a fronteira com engenharia muda, e ainda estamos aprendendo em que direção.
Como testar isso você mesmo
Um caminho curto para experimentar em uma tarde:
- Escolha uma interface com estado real do seu produto. Um filtro com ao menos quatro critérios é bom candidato.
- Escreva um markdown de uma página descrevendo layout, comportamento, estados (vazio, carregando, erro, resultado) e stack.
- Gere 20 a 50 linhas de dado sintético em JSON, cobrindo casos comuns e três casos estranhos (valor nulo, string longa, combinação improvável).
- Cole prompt e dados em v0 ou Figma Make. Rode. Anote onde o resultado divergiu do que você pediu.
- Itere três vezes no máximo. Se em três iterações não chegou perto, o problema está no prompt, não na ferramenta.
- Faça um piloto rápido com uma pessoa antes de agendar teste com cinco. Você vai descobrir que o protótipo trava num caminho que você não previu, e é melhor descobrir sozinho.
O ganho não é estético. O ganho é passar a formular pergunta de pesquisa sobre coisas que antes você deixava para depois do deploy porque prototipar era caro demais. É isso que o artigo da NN/G está descrevendo, e é isso que vale replicar.
Fonte primária: Chan, Megan. Test Complex Interactions Earlier with AI Prototyping. Nielsen Norman Group, 11 de setembro de 2026.
