Prototipagem rápida com IA funciona quando começa por uma hipótese decidível, usa a menor fidelidade necessária, inclui estados e limites reais, é testada com pessoas e converte cada observação em uma decisão registrada. Gerar uma interface não valida o problema nem o produto.
Na terça-feira, o time descreve uma ideia em um prompt. Pouco depois, recebe uma interface navegável, com textos, imagens e transições. Na quarta, a apresentação já tem dezoito telas. Na sexta, alguém faz a pergunta que deveria ter vindo antes: o que exatamente precisamos aprender?
Ninguém sabe se a dúvida era sobre a proposta, a ordem das etapas, a compreensão de uma recomendação ou a confiança para concluir a tarefa. O protótipo parece avançado, mas a decisão continua parada. A velocidade produziu um artefato e ocultou a hipótese.
Esse é o risco central da prototipagem assistida por inteligência artificial. Quando o custo de materializar uma solução cai, fica mais fácil gerar antes de enquadrar e polir antes de observar. A saída convincente cria uma falsa sensação de progresso.
A alternativa não é recusar a velocidade. É reposicioná-la. O protótipo vale pelo intervalo que encurta entre hipótese, experiência observável e decisão. Se não muda o que o time sabe, é apenas produção antecipada.
Interface pronta não é evidência
Um protótipo é uma representação construída para investigar uma incerteza. Pode ser um desenho em papel, uma sequência clicável, uma conversa simulada, um serviço encenado ou um trecho em código. Sua qualidade depende da pergunta que consegue responder com custo e risco adequados.
A orientação pública do GOV.UK sobre protótipos recomenda explorar, compartilhar e testar abordagens antes de comprometer a construção. Também alerta que código de protótipo não deve simplesmente migrar para produção, porque segurança, desempenho e qualidade operacional obedecem a outro padrão.
A IA amplia a quantidade de formas possíveis, mas não altera essa distinção. Uma tela completa prova que uma ferramenta conseguiu compor elementos. Não prova que pessoas reconhecem o ponto de entrada, entendem a linguagem, recuperam-se de uma falha ou desejam resolver o problema daquela maneira.
O avanço não está na quantidade de telas geradas. Está na quantidade de incerteza relevante que o time conseguiu remover.
Comece por uma hipótese que permita decidir
“Testar o novo fluxo” é amplo demais. Uma hipótese útil liga pessoa, contexto, comportamento esperado e consequência. Também informa qual decisão será tomada depois do teste.
Pessoa e contexto: quem tenta fazer o quê, em qual situação?
Incerteza: o que ainda não sabemos e por que importa?
Hipótese: acreditamos que determinada mudança ajudará a produzir qual comportamento?
Evidência observável: o que veremos ou ouviremos se a hipótese se sustentar?
Risco: qual dano, custo ou decisão errada queremos evitar?
Decisão posterior: com que evidência avançamos, redesenhamos ou interrompemos?
Considere uma equipe que deseja resumir informações complexas antes de uma decisão. Ela poderia testar se as pessoas entendem o resumo, se encontram a fonte original e se percebem quando há incerteza. Isso é mais útil do que perguntar se “gostaram da experiência”. A primeira formulação produz comportamentos observáveis; a segunda tende a produzir opinião genérica.
O enquadramento também expõe a escolha de negócio. Se a hipótese se sustentar, qual custo pode cair, que risco fica mais controlado ou que etapa pode avançar? Se não houver consequência para a decisão, talvez o teste ainda não mereça prioridade.
Use a menor fidelidade que responda à pergunta
Fidelidade não é uma escada obrigatória entre rascunho e beleza. Ela é a combinação de aspectos que precisam parecer reais para provocar o comportamento relevante.
Se a dúvida é sobre ordem, um fluxo simples basta. Se é sobre linguagem, o conteúdo precisa estar próximo do real. Se é sobre tempo de resposta de uma assistência de IA, a latência deve ser simulada. Se é sobre confiança em uma recomendação, origem, incerteza, correção e recusa precisam existir.
A técnica Wizard of Oz é especialmente útil: uma pessoa opera nos bastidores uma parte que parece automatizada. Assim, o time testa interação, expectativa e operação antes de integrar um modelo. A simulação deve ser informada à pessoa conforme o protocolo de pesquisa e nunca usada para induzi-la a acreditar em uma capacidade inexistente fora do teste.
Escolher pouca fidelidade preserva reversibilidade. Quanto menos o time investe antes de aprender, mais fácil abandonar uma direção ruim. Alta fidelidade tem função quando detalhes visuais, acessibilidade, resposta do sistema ou integração são parte da hipótese. Ela não é um prêmio por avanço.
Um briefing para gerar sem perder o problema
Prompts melhores não compensam pesquisa ausente, mas podem tornar a geração mais disciplinada. O pedido precisa limitar o escopo e dizer o que ainda é desconhecido.
Você apoiará a criação de um protótipo de pesquisa, não de uma solução final. Pessoa: [perfil baseado em evidência]. Tarefa: [resultado que precisa alcançar]. Contexto: [momento, canal e restrições]. Hipótese: [afirmação testável]. Incerteza principal: [pergunta]. Crie somente o menor fluxo necessário para investigá-la. Inclua estados inicial, carregamento, vazio, erro, incerteza, correção, retorno e conclusão quando aplicáveis. Use linguagem [critérios]. Liste pressupostos em separado. Não invente evidências nem declare a hipótese validada. Ao final, explique o que o protótipo permite testar e o que permanece fora de escopo.
O prompt funciona como contrato de exploração. A seção de pressupostos impede que escolhas geradas ganhem status de requisito. A seção de fora de escopo reduz a chance de uma demonstração se transformar, por inércia, no produto a ser construído.
Dados reais só devem entrar em ambiente aprovado, com minimização e proteção adequadas. Em muitos testes, dados fictícios realistas atendem à hipótese sem expor uma pessoa. Quando contexto real for indispensável, consentimento, acesso, retenção e descarte fazem parte do desenho da pesquisa.
Refine uma camada por vez
Quando fluxo, conteúdo, estados, hierarquia e acabamento mudam juntos, o time não sabe o que provocou o resultado. Trabalhar por camadas cria um histórico inteligível.
- Fluxo: ponto de entrada, sequência, decisão, retorno e saída.
- Conteúdo: rótulos, instruções, explicações, tom e informação necessária.
- Estados: espera, vazio, indisponibilidade, erro, baixa confiança, correção e recuperação.
- Hierarquia: o que precisa ser percebido primeiro e qual ação merece destaque.
- Acessibilidade: teclado, foco, contraste, zoom, tecnologias assistivas e diferentes formas de interação.
- Acabamento: consistência visual e movimento apenas quando alteram compreensão ou confiança.
As Diretrizes de Acessibilidade para Conteúdo Web 2.2 são critérios testáveis desenvolvidos para diferentes tecnologias. Um protótipo inicial pode não demonstrar conformidade completa, mas não deve adiar todas as perguntas de acessibilidade. Foco, ordem, tamanho de alvo, mensagens e alternativas podem mudar a própria arquitetura.
Estados revelam o sistema que a tela feliz esconde
Geradores tendem a privilegiar o caminho ideal. Produtos reais operam com informação ausente, respostas lentas, permissões negadas, baixa confiança e intenção ambígua. Em experiências com IA, também há saída incorreta, irrelevante ou segura demais para ser útil.
| Estado | Pergunta de produto | Comportamento a observar |
|---|---|---|
| Entrada incompleta | O sistema explica o que falta sem culpar? | A pessoa entende como prosseguir. |
| Processamento | Existe expectativa adequada sobre tempo e controle? | A pessoa espera, cancela ou abandona. |
| Baixa confiança | O limite está claro e há alternativa? | A pessoa interpreta incerteza e escolhe um caminho. |
| Saída incorreta | É possível corrigir, reportar ou refazer? | A pessoa recupera a tarefa sem perder trabalho. |
| Indisponibilidade | Há continuidade manual ou retorno seguro? | A tarefa pode seguir sem improviso perigoso. |
| Conclusão | Consequência e próximo passo estão compreensíveis? | A pessoa confirma o resultado correto. |
O People + AI Guidebook sobre erros diferencia falhas do sistema, da interação e do contexto, e recomenda devolver controle quando a automação não consegue continuar. Prototipar essas transições cedo protege experiência e operação.
Teste tarefas, não uma apresentação
No teste moderado, a pessoa recebe uma situação plausível e tenta concluir uma tarefa. O time observa onde ela hesita, que palavras interpreta, que informação procura e como reage à resposta. A orientação do GOV.UK para testes de usabilidade recomenda definir perguntas de pesquisa, recrutar pessoas reais ou prováveis usuárias e criar tarefas sem entregar a resposta.
Abertura: explique que o serviço, e não a pessoa, está sendo avaliado.
Contexto: apresente uma situação compatível com a experiência dela.
Tarefa: peça um resultado, sem indicar o caminho.
Observação: registre ação, fala, hesitação, erro, recuperação e expectativa.
Sondagem: pergunte o que ela esperava encontrar e por quê.
Fechamento: revele limitações da simulação, explique o uso dos dados e agradeça.
A própria IA pode ajudar a preparar variações de tarefas, checar consistência das notas e localizar eventos recorrentes. Ela não deve assumir o papel do participante. Também não deve concluir que ausência de comentário significa compreensão.
Transforme achado em próxima rodada
Depois da sessão, separe observação de interpretação. “Três participantes tocaram em voltar após ler a recomendação” é observação de uma rodada específica. “As pessoas não confiam em IA” é uma generalização que os dados talvez não permitam.
Converta cada evidência em uma mudança rastreável. O novo prompt pode receber o trecho do fluxo, o problema observado, a hipótese explicativa e as partes que devem permanecer. Peça alternativas, não uma correção única. Depois escolha com base no risco e teste novamente.
| Campo | O que registrar |
|---|---|
| Hipótese | A dúvida e a decisão que ela informa. |
| Versão | Camada alterada e elementos preservados. |
| Evidência | Comportamento, fala e contexto, sem interpretação inflada. |
| Leitura | Explicações possíveis e contraditórios. |
| Decisão | Avançar, ajustar, investigar por outro método ou descartar. |
| Próximo teste | O que precisa mudar e qual sinal será observado. |
Meça aprendizado e consequência
Tempo para gerar uma versão é uma métrica de processo. Sozinha, não mostra valor. Acompanhe tempo entre hipótese e decisão, proporção de testes que mudaram uma escolha, problemas relevantes encontrados antes da produção e custo de retrabalho evitado. Para a experiência, observe conclusão, erro, recuperação, compreensão e confiança calibrada.
Depois que uma direção avança, conecte o aprendizado à operação e ao negócio: contatos de suporte, abandono, tempo de atendimento, incidentes, conversão ou custo podem ser relevantes conforme o caso. Declare sempre o que é associação, hipótese ou efeito demonstrado.
O núcleo do AI Risk Management Framework do NIST recomenda testar sistemas antes da implantação e durante a operação, combinando métodos quantitativos e qualitativos e registrando incerteza. O protótipo inicia a avaliação, mas não encerra a responsabilidade.
Quando parar de prototipar
Uma rodada deve terminar com uma escolha. Avance quando a evidência sustenta a hipótese e os riscos restantes pertencem à engenharia, à operação ou a outro tipo de teste. Redesenhe quando o problema continua válido, mas a interação falha. Interrompa quando o benefício não aparece, o risco não pode ser controlado ou a solução depende de uma capacidade inexistente.
Também é hora de parar quando mais acabamento não responde à dúvida. O time pode precisar voltar à pesquisa, medir o processo atual, executar uma prova técnica ou comparar alternativas financeiras. Persistir no mesmo artefato não é iteração quando a pergunta mudou.
O relatório de IA da Figma publicado em 2026 reuniu 8.403 respostas de pesquisa e 639 entrevistas em dez mercados, incluindo o Brasil. A empresa relata maior participação cruzada entre design e desenvolvimento e argumenta que, quando construir fica mais rápido, escolher o que merece ser construído ganha importância. É um levantamento de fornecedor, baseado em respostas declaradas. Serve como sinal de mudança do trabalho, não como prova de ganho para qualquer equipe.
Perguntas frequentes
Um protótipo gerado por IA já pode virar produto?
Não automaticamente. O protótipo serve para reduzir incerteza. Código, segurança, desempenho, dados, acessibilidade e operação precisam de critérios próprios antes da produção.
Qual fidelidade usar primeiro?
A menor fidelidade capaz de responder à dúvida atual. Fluxos e linguagem podem começar simples; comportamento técnico ou acessibilidade podem exigir uma simulação mais realista.
A própria IA pode avaliar o protótipo?
Ela pode fazer uma crítica preliminar contra critérios explícitos, mas não substitui observação com pessoas nem testes técnicos. Uma saída plausível não é evidência de uso.
Quantas pessoas devem participar do teste?
Depende da diversidade do público, do risco e da pergunta. Prefira rodadas pequenas e frequentes, recrutando pessoas compatíveis com o contexto, e continue até a evidência sustentar uma decisão.
Quando parar de iterar?
Quando a hipótese tiver evidência suficiente para avançar, mudar ou ser descartada, e quando a próxima incerteza exigir produção ou outro método de pesquisa em vez de mais acabamento.
O próximo passo
Volte à sexta-feira do início. As dezoito telas não eram o problema. O problema era não saber que decisão elas deveriam informar. Uma pergunta clara teria permitido construir menos, observar melhor e aprender antes.
Escolha uma hipótese atual do seu produto. Preencha o canvas, defina a menor fidelidade e prepare uma tarefa observável. Use IA para materializar e comparar, não para declarar a resposta. Ao final, registre o que entrou, o que mudou e por que a próxima rodada merece existir.
Se sua equipe precisa encurtar o caminho entre ideia, evidência e decisão, conheça o serviço de Fast Prototyping da AIUX Brasil ou converse conosco sobre um ciclo aplicado ao seu contexto.