{"id":717,"date":"2026-09-13T03:50:18","date_gmt":"2026-09-13T06:50:18","guid":{"rendered":"https:\/\/yellowkode.com\/blog\/prototipagem-ia-testar-interacoes-complexas\/"},"modified":"2026-09-13T03:50:18","modified_gmt":"2026-09-13T06:50:18","slug":"prototipagem-ia-testar-interacoes-complexas","status":"publish","type":"post","link":"https:\/\/yellowkode.com\/blog\/prototipagem-ia-testar-interacoes-complexas\/","title":{"rendered":"Prototipagem com IA para testar intera\u00e7\u00f5es complexas antes do c\u00f3digo de produ\u00e7\u00e3o"},"content":{"rendered":"

Em 11 de setembro de 2026, a Nielsen Norman Group publicou um artigo da Megan Chan chamado Test Complex Interactions Earlier with AI Prototyping<\/em>. A tese: ferramentas de IA tornam vi\u00e1vel construir prot\u00f3tipos interativos completos de interfaces complexas, para testar com usu\u00e1rios mais cedo no processo de design. O texto documenta tr\u00eas casos, dois na Ramp e um em Purdue, e prop\u00f5e um processo de cinco passos. Vou destrinchar o mecanismo, mostrar onde a coisa realmente muda de patamar e onde ela quebra.<\/p>\n

O que muda quando o prot\u00f3tipo vira c\u00f3digo de verdade<\/h2>\n

Antes de ferramentas como Cursor, v0, Bolt e Figma Make, prototipar uma interface complexa em Figma significava desenhar telas est\u00e1ticas e ligar com setinhas. Voc\u00ea conseguia representar um caminho feliz, dois no m\u00e1ximo. Se o produto era um filtro com 27 atributos e sub-atributos aninhados (esse \u00e9 literalmente o caso de Purdue que a NN\/G descreve), voc\u00ea n\u00e3o prototipava, voc\u00ea desenhava um mock e torcia.<\/p>\n

O que mudou n\u00e3o foi “a IA desenha melhor”. O que mudou foi que a sa\u00edda deixou de ser imagem e passou a ser c\u00f3digo execut\u00e1vel. Um prompt bem constru\u00eddo em v0 devolve componentes React em shadcn\/ui prontos para rodar. Um pedido em Cursor devolve arquivos que voc\u00ea edita, comita e serve. O prot\u00f3tipo passa a ter estado.<\/p>\n

Uma analogia que ajuda: \u00e9 a diferen\u00e7a entre uma maquete de arquitetura em papel\u00e3o e uma casa com encanamento provis\u00f3rio. Na maquete voc\u00ea aponta a porta. Na casa provis\u00f3ria voc\u00ea abre a porta, entra, e descobre que o corredor \u00e9 estreito demais para passar com a m\u00e3o ocupada. Onde a analogia quebra: casa provis\u00f3ria exige alvar\u00e1, prot\u00f3tipo de IA voc\u00ea joga fora na sexta.<\/p>\n

Por que interfaces com filtro, dashboard e chat s\u00e3o o caso ideal<\/h3>\n

Esses tr\u00eas tipos t\u00eam em comum uma coisa: o n\u00famero de estados poss\u00edveis \u00e9 grande demais para desenhar tela por tela. Um filtro com sete crit\u00e9rios booleanos j\u00e1 tem 128 combina\u00e7\u00f5es de estado ligado\/desligado, antes de considerar valores. Um chat de IA \u00e9 pior, porque a interface tem que gerar uma resposta razo\u00e1vel para praticamente qualquer input do usu\u00e1rio e pode at\u00e9 produzir sa\u00eddas diferentes para o mesmo input. Ferramentas de design tradicionais, limitadas a um conjunto fixo de telas pr\u00e9-constru\u00eddas, n\u00e3o capturam esse comportamento aberto e n\u00e3o determin\u00edstico.<\/p>\n

\u00c9 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\u00eddas n\u00e3o determin\u00edsticas, imitando o produto real. O prot\u00f3tipo n\u00e3o simula respostas, ele chama um modelo. E o participante do teste digita o que quiser, n\u00e3o o que o script prev\u00ea.<\/p>\n

O processo de cinco passos, com foco no que realmente pesa<\/h2>\n

O artigo da NN\/G descreve cinco passos. Reordeno por peso relativo:<\/p>\n

    \n
  1. Decidir o que o prot\u00f3tipo precisa fazer.<\/strong> Nem toda pergunta de pesquisa exige interatividade. Se a d\u00favida \u00e9 sobre nomenclatura de r\u00f3tulo, wireframe est\u00e1tico resolve. Se \u00e9 sobre como o usu\u00e1rio comp\u00f5e filtros, n\u00e3o resolve.<\/li>\n
  2. Tomar as decis\u00f5es de design antes de abrir a ferramenta.<\/strong> Layout, hierarquia, intera\u00e7\u00f5es, estados vazios, estados de erro. A NN\/G \u00e9 direta: a qualidade do prompt depende do pensamento feito nesta etapa.<\/li>\n
  3. Reunir os dados.<\/strong> Exportar dado real do produto (respeitando pol\u00edtica de privacidade, nada de PII) ou pedir a um LLM que gere um dataset sint\u00e9tico.<\/li>\n
  4. Escrever o prompt e anexar os dados.<\/strong> Markdown \u00e9 o formato que LLM parseia melhor. Anexar sketches, wireframes ou telas existentes ajuda.<\/li>\n
  5. Iterar.<\/strong> A primeira sa\u00edda raramente acerta tudo.<\/li>\n<\/ol>\n

    O passo 2 \u00e9 o que separa prot\u00f3tipo utiliz\u00e1vel de gerador de tela gen\u00e9rica. Um prompt vago devolve dashboard gen\u00e9rico com card, gr\u00e1fico e tabela, todos no mesmo peso visual. Um prompt que descreve estados devolve algo test\u00e1vel.<\/p>\n

    Um esqueleto de prompt que funciona<\/h3>\n
    # Interface: editor de pol\u00edtica de despesas\n\n## Layout\n- Coluna esquerda (320px): lista de pol\u00edticas existentes\n- \u00c1rea central: chat com o assistente\n- Coluna direita (400px): preview da pol\u00edtica em edi\u00e7\u00e3o\n\n## Comportamento\n- Ao digitar no chat, o assistente prop\u00f5e altera\u00e7\u00f5es\n- Cada altera\u00e7\u00e3o aparece como diff no preview (verde=adicionado, vermelho=removido)\n- Usu\u00e1rio pode aceitar ou rejeitar cada diff individualmente\n\n## Estados\n- Vazio: nenhuma pol\u00edtica selecionada, mostrar CTA \"criar pol\u00edtica\"\n- Carregando: skeleton no preview enquanto o LLM responde\n- Erro do LLM: mensagem inline no chat, bot\u00e3o \"tentar de novo\"\n- Conflito: se duas regras se contradizem, banner amarelo no topo\n\n## Dados\n[anexar arquivo policies.json com 12 exemplos]\n\n## Stack\nReact + Tailwind, componentes de shadcn\/ui\n<\/code><\/pre>\n
    Repare que metade do prompt \u00e9 sobre estado, n\u00e3o sobre est\u00e9tica. \u00c9 a\u00ed que o prot\u00f3tipo vira ferramenta de pesquisa.<\/p>\n
    O que isso significa na pr\u00e1tica<\/h2>\n
    Na Ramp, segundo o relato da NN\/G, o redesenho do editor de pol\u00edtica focou em editar uma pol\u00edtica atrav\u00e9s de chat com IA. Como a edi\u00e7\u00e3o baseada em conversa dependia de respostas din\u00e2micas da interface, era dif\u00edcil de simular com telas est\u00e1ticas. Durante o teste, os participantes recebiam um link do prot\u00f3tipo carregado com dados pr\u00f3prios sanitizados, e o prot\u00f3tipo 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\u00e7\u00f5es estava confusa, algo que o time n\u00e3o teria encontrado com tela est\u00e1tica.<\/p>\n
    No caso Purdue, os pesquisadores constru\u00edram a mesma interface duas vezes: primeiro est\u00e1tica em Figma, depois interativa com v0 e Bolt. A NN\/G alerta que este foi um estudo de caso sequencial focado num \u00fanico projeto, n\u00e3o um experimento controlado, e portanto o exemplo deve ser interpretado como ilustra\u00e7\u00e3o do que se tornou vi\u00e1vel construir e testar, n\u00e3o como evid\u00eancia de que a prototipagem com IA produz melhor pesquisa. Vale registrar essa nuance, o artigo original n\u00e3o vende milagre.<\/p>\n
    Do meu lado, o que me faz levar isso a s\u00e9rio \u00e9 experi\u00eancia de A\/B. Rodando teste A\/B por anos num fluxo de assinatura, com mesmo backend, mesma API, duas interfaces diferentes, a receita sa\u00eda mensuravelmente diferente. Se o valor estivesse todo atr\u00e1s da API, os dois lados dariam o mesmo n\u00famero. N\u00e3o davam. O que a NN\/G descreve \u00e9 a vers\u00e3o em pesquisa disso: quando voc\u00ea deixa o usu\u00e1rio tocar em algo que responde de verdade, o feedback muda de qualidade, porque a interface passa a carregar informa\u00e7\u00e3o que a tela est\u00e1tica n\u00e3o carrega.<\/p>\n
    O que as imagens do artigo original mostram<\/h3>\n
    Para quem n\u00e3o vai abrir o link: as figuras comparam duas fases do caso Purdue. Na fase 1, wireframes est\u00e1ticos em Figma mostram um mapa com painel lateral de filtros (localiza\u00e7\u00e3o, per\u00edodo, tipo de evento). O usu\u00e1rio v\u00ea o layout mas n\u00e3o consegue clicar. Na fase 2, prot\u00f3tipos gerados com v0 e Bolt mostram a mesma ideia mas com filtros que aplicam de verdade sobre um dataset sint\u00e9tico, atualizando o mapa e as estat\u00edsticas. \u00c9 a diferen\u00e7a entre “aqui vai ter um filtro por gravidade” e “selecione gravidade alta e veja o mapa reagir”.<\/p>\n
    Onde isso quebra<\/h2>\n
    Alguns pontos que o artigo toca de leve e que merecem peso maior:<\/p>\n
    A armadilha da fidelidade<\/h3>\n
    A NN\/G nomeia isso de fidelity trap<\/em>: prot\u00f3tipos gerados por IA podem parecer completos enquanto introduzem todo tipo de suposi\u00e7\u00e3o e imprecis\u00e3o, como usar o padr\u00e3o de design errado para a situa\u00e7\u00e3o, criar uma hierarquia confusa ou repetir elementos desnecessariamente. O risco social \u00e9 pior que o t\u00e9cnico: algu\u00e9m em reuni\u00e3o pergunta “d\u00e1 para subir isso?” e a resposta correta (“n\u00e3o”) passa a exigir explica\u00e7\u00e3o.<\/p>\n
    Isso conecta a uma coisa que raramente \u00e9 dita: quase nenhum engenheiro de IA tem design system publicado e style guide de interface, e \u00e9 por isso que quase toda interface de produto com agente \u00e9 feia. O prot\u00f3tipo gerado por IA herda esse problema em escala, porque o modelo preenche a lacuna com o que ele viu, e o que ele viu \u00e9 m\u00e9dia de internet. Se voc\u00ea n\u00e3o imp\u00f5e o sistema no prompt, ele imp\u00f5e o sistema dele.<\/p>\n
    Custo e lat\u00eancia do pr\u00f3prio prot\u00f3tipo<\/h3>\n
    Iterar em v0 ou Cursor consome cr\u00e9ditos, tempo e paci\u00eancia. A literatura recente sobre vibe coding<\/em> registra que uma experi\u00eancia comum \u00e9 a de struggle com o prompt e itera\u00e7\u00e3o, com projetos exigindo dezenas ou at\u00e9 centenas de itera\u00e7\u00f5es antes da sa\u00edda ficar utiliz\u00e1vel. Para prot\u00f3tipo descart\u00e1vel isso \u00e9 aceit\u00e1vel. Para prot\u00f3tipo que vai ser mantido durante meses de pesquisa, n\u00e3o \u00e9.<\/p>\n
    Dados reais versus dados sint\u00e9ticos<\/h3>\n
    Subir dado real acelera a resposta do usu\u00e1rio no teste, porque ele reconhece o pr\u00f3prio contexto. Mas exige revis\u00e3o de pol\u00edtica de privacidade da sua empresa e revis\u00e3o da pol\u00edtica do fornecedor de IA (quem treina em cima do qu\u00ea). Dado sint\u00e9tico evita o problema mas frequentemente \u00e9 bonito demais, sem os casos degenerados que s\u00f3 existem em produ\u00e7\u00e3o (nome com 80 caracteres, valor negativo, campo nulo onde n\u00e3o deveria).<\/p>\n
    O prot\u00f3tipo n\u00e3o \u00e9 o produto<\/h3>\n
    A literatura sobre vibe coding \u00e9 bem consistente aqui: vibe coding pode levar a d\u00edvida t\u00e9cnica, c\u00f3digo n\u00e3o manuten\u00edvel e produtos com bugs ou inseguros, incluindo casos como senhas armazenadas em texto puro. Prot\u00f3tipo para pesquisa \u00e9 uma coisa. Empurrar isso para produ\u00e7\u00e3o \u00e9 outra, e \u00e9 onde o “d\u00e1 para subir?” mata projeto.<\/p>\n
    O que n\u00e3o d\u00e1 para afirmar ainda<\/h2>\n
    O artigo da NN\/G descreve tr\u00eas casos, e \u00e9 honesto ao dizer que o de Purdue n\u00e3o \u00e9 experimento controlado. N\u00e3o temos dados p\u00fablicos comparando taxa de descoberta de problema de usabilidade entre prot\u00f3tipo est\u00e1tico e prot\u00f3tipo interativo com amostra grande, mesmo protocolo e mesma tarefa. A intui\u00e7\u00e3o de que interativo descobre mais \u00e9 forte e consistente, mas o tamanho do efeito n\u00e3o est\u00e1 quantificado.<\/p>\n
    Tamb\u00e9m n\u00e3o est\u00e1 claro em qual ponto do funil de complexidade o prot\u00f3tipo interativo compensa o custo. Para uma tela de login com um campo, obviamente n\u00e3o. Para um dashboard com sete filtros aninhados, obviamente sim. No meio, a decis\u00e3o ainda \u00e9 gosto informado, n\u00e3o crit\u00e9rio.<\/p>\n
    Por fim, o efeito de longo prazo na equipe \u00e9 uma inc\u00f3gnita. Se o time de design passa a entregar prot\u00f3tipos que rodam, a fronteira com engenharia muda, e ainda estamos aprendendo em que dire\u00e7\u00e3o.<\/p>\n
    Como testar isso voc\u00ea mesmo<\/h2>\n
    Um caminho curto para experimentar em uma tarde:<\/p>\n
      \n
    1. Escolha uma interface com estado real do seu produto. Um filtro com ao menos quatro crit\u00e9rios \u00e9 bom candidato.<\/li>\n
    2. Escreva um markdown de uma p\u00e1gina descrevendo layout, comportamento, estados (vazio, carregando, erro, resultado) e stack.<\/li>\n
    3. Gere 20 a 50 linhas de dado sint\u00e9tico em JSON, cobrindo casos comuns e tr\u00eas casos estranhos (valor nulo, string longa, combina\u00e7\u00e3o improv\u00e1vel).<\/li>\n
    4. Cole prompt e dados em v0 ou Figma Make. Rode. Anote onde o resultado divergiu do que voc\u00ea pediu.<\/li>\n
    5. Itere tr\u00eas vezes no m\u00e1ximo. Se em tr\u00eas itera\u00e7\u00f5es n\u00e3o chegou perto, o problema est\u00e1 no prompt, n\u00e3o na ferramenta.<\/li>\n
    6. Fa\u00e7a um piloto r\u00e1pido com uma pessoa antes de agendar teste com cinco. Voc\u00ea vai descobrir que o prot\u00f3tipo trava num caminho que voc\u00ea n\u00e3o previu, e \u00e9 melhor descobrir sozinho.<\/li>\n<\/ol>\n
      O ganho n\u00e3o \u00e9 est\u00e9tico. O ganho \u00e9 passar a formular pergunta de pesquisa sobre coisas que antes voc\u00ea deixava para depois do deploy porque prototipar era caro demais. \u00c9 isso que o artigo da NN\/G est\u00e1 descrevendo, e \u00e9 isso que vale replicar.<\/p>\n
      Fonte prim\u00e1ria:<\/strong> Chan, Megan. Test Complex Interactions Earlier with AI Prototyping<\/em>. Nielsen Norman Group, 11 de setembro de 2026.<\/p>\n","protected":false},"excerpt":{"rendered":"
      Como usar Cursor, v0 e Figma Make para prototipar interfaces com filtros, dashboards e chat de IA antes de escrever o c\u00f3digo de produ\u00e7\u00e3o.<\/p>\n","protected":false},"author":2,"featured_media":716,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-717","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/posts\/717","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/comments?post=717"}],"version-history":[{"count":0,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/posts\/717\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/media\/716"}],"wp:attachment":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/media?parent=717"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/categories?post=717"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/tags?post=717"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}