Como criar interface para funcionalidade de IA

Desenhar uma funcionalidade de IA parece um problema de interface. Na prática, começa como um problema de contrato. Boa parte do software tradicional foi construída sobre uma expectativa simples: se eu fizer a mesma coisa de novo, espero que o sistema se comporte do mesmo jeito. Um cálculo retorna o mesmo resultado, um filtro aplica a mesma regra, um botão executa uma ação conhecida, uma busca no banco consulta dados existentes.

IA generativa quebra essa expectativa. A mesma entrada pode produzir outra saída. Uma resposta pode estar excelente numa tentativa e ruim na seguinte. Um texto pode parecer correto mesmo quando contém um erro. Isso muda a interface porque muda aquilo que o usuário pode presumir sobre o sistema. Você não está apenas adicionando IA ao produto. Está introduzindo incerteza numa interface que antes comunicava certeza. É por isso que colocar um campo de texto e um botão de “Gerar” raramente resolve o problema.

A interface precisa ser desenhada para a distribuição, não para a demo

Uma demonstração interna costuma ser enganosa. Alguém prepara um prompt, executa, a resposta fica ruim, ajusta, executa novamente, a terceira fica ótima. Essa é a versão que vai para a apresentação. Em produção, o produto encontra centenas de formas de pedir a mesma coisa, dados incompletos, contextos que o time nunca testou e usuários que não sabem escrever o prompt ideal.

Raluca Budiu, da Nielsen Norman Group, resumiu bem o problema em um artigo de agosto de 2026: uma saída de IA é um exemplo, não uma avaliação do sistema. Para Product Design, isso produz uma consequência simples. Não desenhe apenas o “resultado gerado”. Desenhe também:

resultado incompleto;

resultado que precisa ser revisado;

resultado sem informação suficiente;

resultado que muda numa nova tentativa;

resultado que não pode ser produzido;

geração interrompida;

geração que demora mais que o esperado.

O caminho feliz mostra o potencial da IA. Os outros estados mostram se existe produto.

A saída gerada não deveria parecer igual a um dado calculado

Imagine um dashboard financeiro. Em um card:

Receita no mês
R$ 348.240

Ao lado:

Sua receita cresceu principalmente pela recuperação dos clientes enterprise.

Os dois aparecem com a mesma tipografia, no mesmo fundo e com a mesma autoridade visual. Só que são informações de natureza diferente. O primeiro pode ter vindo diretamente de uma consulta ao banco de dados. O segundo pode ser uma interpretação produzida por um modelo. Se a interface não diferencia essas duas coisas, o usuário precisa adivinhar qual delas é fato e qual é inferência. Esse é um problema de design.

Uma boa interface de IA deveria ajudar a responder: o que foi gerado? Em que informação isso se baseou? Posso verificar? Posso corrigir? O sistema executou alguma coisa ou apenas sugeriu? Não é necessário cercar cada frase com alertas sobre inteligência artificial. Mas a diferença de natureza precisa ser perceptível quando ela importa para a decisão.

Mostrar a origem reduz o custo de confiar

Uma das melhores coisas que uma interface de IA pode fazer é facilitar a verificação. Imagine um produto que analisa centenas de transações e escreve:

O aumento de custos deste mês veio principalmente de mídia paga.

Sem contexto, a pessoa tem duas escolhas: confiar, ou começar uma investigação manual. Agora imagine:

O aumento de custos deste mês veio principalmente de mídia paga.

Baseado em: Google Ads +R$ 18.400, Meta Ads +R$ 7.230.

A IA não ficou necessariamente mais inteligente. A interface ficou mais verificável. Isso é especialmente importante quando a resposta utiliza informações que já existem dentro do próprio produto. Sempre que for possível, conecte afirmação a evidência. Pode ser:

• documentos utilizados;

• transações;

• registros;

• trechos de uma fonte;

• período analisado;

• filtros aplicados;

• arquivos;

• entidades consideradas.

A pessoa não precisa conhecer todo o raciocínio interno do modelo. Precisa conseguir confirmar aquilo que é importante para a tarefa.

Não esconda o custo de verificar

IA frequentemente economiza tempo em uma etapa e devolve esse tempo como revisão. A geração leva quatro segundos. A pessoa passa cinco minutos verificando. Isso pode continuar sendo útil — talvez a alternativa manual levasse vinte minutos. Mas a métrica correta não é o tempo de geração. É o tempo até um resultado utilizável.

O framework PROVE, publicado pela Nielsen Norman Group, chama atenção justamente para isso na dimensão de Velocity: é preciso considerar preparação, prompting, revisão, correção e movimentação entre ferramentas, não apenas o tempo que o modelo levou para responder. Para interface, isso muda o objetivo. Não basta gerar rápido. É preciso tornar revisar rápido.

A correção precisa custar menos que começar de novo

Esse é um bom teste para qualquer funcionalidade de IA. Depois que a resposta aparece, o que o usuário consegue fazer? Apagar tudo? Gerar novamente? Ou realmente trabalhar sobre o resultado? Uma funcionalidade útil pode permitir:

• editar diretamente;

• aceitar apenas uma parte;

• rejeitar um trecho;

• pedir uma versão específica;

• regenerar somente uma seção;

• comparar alternativas;

• voltar para uma versão anterior;

• desfazer uma alteração aplicada.

Imagine uma IA que escreve uma descrição de produto com cinco parágrafos. Quatro estão bons. Um está errado. Se “Regenerar” produz cinco novos parágrafos, a pessoa perde quatro coisas que já havia aprovado para tentar corrigir uma. A interface transformou variabilidade em retrabalho. Quando possível, a unidade de correção deveria acompanhar a unidade do erro.

“Não sei” é um estado de interface

Software tradicional tende a apresentar erro quando alguma coisa tecnicamente falha. IA cria uma categoria mais difícil: o sistema funcionou perfeitamente e mesmo assim não deveria responder. Talvez falte informação, talvez a pergunta esteja fora do escopo, talvez as fontes disponíveis não permitam concluir, talvez a confiança seja insuficiente para aquela tarefa. Nesses casos, uma resposta incompleta e explícita pode ser melhor que uma resposta convincente. Por exemplo:

Não encontrei informação suficiente nos documentos conectados para determinar por que este contrato foi cancelado.

Isso pode ser muito mais útil que inventar uma explicação plausível. O problema é que interfaces de IA frequentemente tratam quantidade de resposta como sinal de qualidade. Uma caixa vazia parece erro. Um parágrafo parece sucesso. Nem sempre. Às vezes a melhor saída do sistema é dizer:

não consigo concluir isso com o contexto disponível.

Essa possibilidade precisa existir no design.

Erros diferentes precisam parecer diferentes

“Não funcionou” é uma categoria ampla demais para IA. Existem pelo menos quatro situações bastante diferentes.

O sistema não conseguiu concluir

Timeout, indisponibilidade do modelo, limite de uso ou outro problema técnico. A solução costuma seguir princípios conhecidos de software: explicar o que aconteceu e permitir continuar.

Não existe contexto suficiente

A infraestrutura funcionou, mas o sistema não consegue responder de maneira adequada. Talvez seja necessário adicionar uma fonte, selecionar outro período ou fornecer determinada informação.

A solicitação está fora do escopo

O usuário está tentando fazer algo que aquela funcionalidade não foi desenhada para fazer. A melhor solução pode começar antes do erro, deixando capacidade e limite mais claros.

A resposta parece boa, mas está errada

Esse é o caso mais difícil porque não existe estado visual de erro. A defesa está em outras decisões do produto: fontes, possibilidade de conferir, edição, aprovação, limites de autonomia.

Um único componente de “erro” não resolve todas essas situações.

Campo de prompt não é automaticamente a melhor interface para IA

O chat virou a metáfora dominante da IA. Isso não significa que toda funcionalidade de IA precise virar chat. Se a tarefa é conhecida, transferir para o usuário a responsabilidade de escrever a instrução pode criar trabalho desnecessário.

Imagine um sistema financeiro. A necessidade recorrente é:

explicar por que meus custos aumentaram em relação ao mês anterior.

Você poderia oferecer um campo “Pergunte qualquer coisa sobre suas finanças”. Ou poderia oferecer:

Explicar variação deste mês

A segunda opção parece menos poderosa. Mas tem uma vantagem enorme: produto e usuário sabem qual tarefa está acontecendo. Isso permite controlar melhor entrada, contexto, formato da saída, fontes, avaliação, tratamento de erro e próxima ação. Campo aberto faz sentido quando exploração é parte do valor. Quando o job é conhecido e recorrente, uma ação específica frequentemente produz uma experiência melhor.

Sugestões de prompt servem para ensinar capacidade

Quando um campo aberto faz sentido, a interface ainda não deveria começar em branco. Um placeholder como “Pergunte alguma coisa...” explica quase nada. Sugestões podem ensinar rapidamente qual tipo de relação o produto espera:

Resuma as principais mudanças deste mês.

Compare esta conta com o mês anterior.

Encontre cobranças fora do padrão.

Explique este documento em linguagem simples.

Não são apenas atalhos. São documentação embutida na interface. Elas ajudam o usuário a construir um modelo mental de o que esta IA faz bem — e, indiretamente, do que talvez não valha pedir ali.

Espera precisa virar estado

Uma geração pode levar dois segundos. Também pode levar vinte. Ou dois minutos quando envolve arquivos, múltiplas ferramentas ou uma tarefa mais longa. O spinner tradicional começa a falhar quando a duração deixa de parecer instantânea. A interface precisa decidir: a pessoa precisa esperar? Se sim, mostre progresso suficiente para que ela saiba que o sistema continua funcionando. Se não, transforme a geração em uma tarefa que pode continuar em segundo plano.

Isso exige outros estados — analisando documentos, preparando resultado, concluído, falhou, resultado disponível — e exige decidir onde a saída aparece quando a pessoa já saiu daquela tela. Uma geração longa não é apenas problema de loading. É um pequeno workflow assíncrono dentro do produto.

O trabalho do usuário precisa sobreviver à falha

Imagine escrever uma instrução detalhada durante quatro minutos. Clicar em gerar. A requisição falha. O campo volta vazio. O problema técnico durou dois segundos. O produto destruiu quatro minutos de trabalho.

Isso vale também para uploads, seleções, contexto configurado, ajustes feitos sobre uma saída, feedback e versões. Quanto mais trabalho existe antes da geração, mais importante fica preservar estado. IA já introduz incerteza suficiente na saída. A interface não deveria adicionar incerteza sobre se o trabalho do usuário continuará existindo.

Cada uso pode ter custo real

Um botão tradicional pode executar uma operação cujo custo marginal é quase irrelevante. Uma geração pode consumir tokens, chamadas de ferramentas, busca, processamento de documentos e serviços de terceiros. Isso cria decisões que eventualmente chegam à interface. Quem pode usar? Existe limite? Por usuário ou organização? O que acontece ao atingir esse limite? O usuário sabe que uma operação é especialmente cara? É possível cancelar uma execução? Pode gerar dez versões simultaneamente? Precisa existir fila?

Não significa colocar “esta resposta custou R$ 0,17” na interface. Significa admitir que a economia da funcionalidade faz parte do desenho do produto. Um botão de “Regenerar” que parece gratuito pode não ser gratuito para quem opera o SaaS.

Se a IA pode agir, a interface muda de categoria

Gerar uma resposta é uma coisa. Executar uma ação é outra. Imagine:

Resuma estas cobranças.

versus:

Cancele as cobranças duplicadas.

No primeiro caso, uma saída ruim produz informação ruim. No segundo, pode alterar o sistema. A partir desse ponto, entram perguntas de autorização e reversibilidade: o que a IA pode fazer? Em nome de quem? Com quais permissões? A pessoa confirma antes? A ação pode ser desfeita? Existe histórico? Fica claro o que será afetado?

Uma interface de agente não deveria usar o mesmo contrato de uma interface de geração de texto. Quanto maior a autonomia, maior precisa ser a clareza sobre intenção, consequência e controle.

Conteúdo também pode virar instrução

Existe ainda uma restrição que Product Design não deveria tratar como detalhe exclusivo de segurança. Prompt injection acontece quando conteúdo lido pelo modelo contém instruções destinadas a alterar o comportamento do sistema. A Nielsen Norman Group define o problema como um ataque em que instruções são inseridas em conteúdo que o LLM lê, como prompt, página ou documento, tentando fazê-lo quebrar regras, revelar informação ou usar ferramentas de forma indevida.

Isso importa especialmente quando a funcionalidade:

• lê documentos de terceiros;

• navega em páginas;

• consulta e-mails;

• acessa dados privados;

• utiliza ferramentas;

• executa ações.

O usuário pode enxergar “analisar este PDF”. O sistema está enxergando “executar instruções sobre conteúdo que pode não ser confiável”. Essa diferença precisa entrar na arquitetura antes da interface.

Antes de lançar, avalie o comportamento que realmente chegará ao usuário

Testar uma funcionalidade de IA uma vez não responde se ela funciona. A orientação da NN/g é avaliar com múltiplas entradas representativas, execuções repetidas e alguma medida da incerteza do resultado, justamente porque sistemas desse tipo apresentam variabilidade.

Isso pode virar um processo bastante concreto: escolha tarefas reais, inclua casos simples e difíceis, execute mais de uma vez, defina antecipadamente o que significa uma saída aceitável, registre onde o sistema falha, compare o custo de correção. Não existe um número universal de prompts ou repetições que sirva para qualquer funcionalidade. O volume precisa acompanhar variabilidade, risco e importância da decisão.

Mas existe uma pergunta que o time deveria conseguir responder antes do lançamento: em quais tipos de caso isso funciona bem, e em quais ainda não funciona? “Ficou ótimo na demo” não é avaliação.

A boa interface de IA não tenta esconder que existe IA

Também não precisa transformar toda tela num painel técnico sobre modelos. O objetivo é mais simples: dar ao usuário o nível de compreensão e controle necessário para trabalhar com uma saída que pode variar. Isso normalmente significa pensar em algumas coisas antes do componente visual:

• qual tarefa está sendo resolvida;

• qual parte da saída pode estar errada;

• como ela pode ser verificada;

• como pode ser corrigida;

• o que acontece quando não existe resposta suficiente;

• quanto tempo a operação pode levar;

• o que acontece se ela falhar;

• quais ações o sistema pode executar;

• como essas ações são autorizadas e revertidas.

É isso que torna uma funcionalidade de IA diferente de adicionar mais um botão ao produto. Um botão tradicional diz:

clique aqui e isto acontecerá.

Uma funcionalidade de IA frequentemente diz:

clique aqui e o sistema tentará produzir algo útil dentro de determinadas condições.

A interface precisa explicar essas condições sem obrigar a pessoa a conhecer o modelo por trás delas. Esse é o novo contrato. E é por isso que o trabalho de Product Design começa antes do campo de prompt.

Sobre situações em que o resultado ou uma ação envolve risco maior, vale continuar por Como comunicar segurança sem assustar o cliente.

Fontes

Nielsen Norman Group. One AI Output Is an Example, Not an Evaluation, Raluca Budiu, 14 de agosto de 2026. Discute por que uma única execução não permite avaliar o desempenho de sistemas de IA e recomenda trabalhar com entradas representativas, repetições e incerteza na avaliação.

Nielsen Norman Group. How to Decide When an AI Tool Is Worth Keeping, Caleb Sponheim, 7 de agosto de 2026. Apresenta o framework PROVE: Problem Alignment, Risk, Output Quality, Velocity e Experience. Neste artigo, a referência é usada principalmente para a ideia de medir o tempo total do workflow, incluindo revisão e correção, e não apenas o tempo de geração.

Nielsen Norman Group. Artificial Intelligence: Glossary, Caleb Sponheim, 21 de agosto de 2026. Referência para conceitos utilizados em produto e UX de IA, incluindo agentes, avaliações, contexto e prompt injection.