Como desenhar experiências de IA em produtos SaaS

A experiência do usuário com IA começa quando o usuário entende o papel da inteligência artificial naquela tarefa, sabe como contestar uma resposta e consegue continuar o trabalho sem reconstruir contexto. Para uma funcionalidade de IA em produto SaaS, o desenho precisa tratar expectativa, contestação e continuidade como partes do fluxo, não como detalhes de interface adicionados no fim.

Por que a experiência de IA começa antes da resposta

Quando uma pessoa usa uma funcionalidade de IA dentro de um produto, ela não está avaliando apenas a qualidade textual da resposta. Ela está tentando decidir o que fazer com aquilo.

Por isso, a interface precisa mostrar o que a saída autoriza, altera ou apenas sugere.

Um resumo bonito pode falhar se o usuário não souber quais dados foram considerados. Uma recomendação plausível pode gerar insegurança se não ficar claro se ela é uma sugestão ou uma ação prestes a ser executada. Uma classificação útil pode perder valor se, depois de ajustá-la, o usuário precisar voltar ao começo do fluxo e preencher tudo de novo.

A pergunta central é simples: o usuário entende o papel da IA naquela tarefa?

Se a resposta for não, a interface provavelmente está delegando julgamento demais para a pessoa no momento errado. O produto mostra uma saída, mas não explicita o que essa saída significa operacionalmente. O usuário passa a interpretar a IA por pistas indiretas: tom de voz, posição do botão, confiança visual da interface, ausência de alerta ou presença de uma opção de confirmar.

Isso cria uma forma ruim de confiança. Não a confiança construída por uso consistente, mas a confiança sugerida pelo acabamento da tela.

Em produtos com IA, confiança é infraestrutura de uso. Ela depende de expectativas claras, caminhos de correção e continuidade da tarefa. Esse raciocínio também se conecta ao tema mais amplo de como criar uma estratégia de inteligência artificial conectada ao negócio: uma funcionalidade inteligente precisa melhorar uma decisão ou operação concreta, não apenas demonstrar capacidade técnica.

Definir a expectativa: recomendar, redigir, classificar ou executar

Antes de desenhar campo de prompt, cards de resposta ou botões de ação, a liderança de produto precisa nomear o tipo de ajuda que a IA presta.

Há uma diferença grande entre recomendar, redigir, classificar e executar.

Quando a IA recomenda, o usuário espera uma orientação para decidir. O desenho deve deixar claro que a decisão continua com a pessoa ou com uma regra do processo. A interface pode mostrar justificativa, critérios usados e alternativas possíveis.

Quando a IA redige, o usuário espera um rascunho editável. O desenho deve favorecer revisão, ajuste de tom, remoção de trechos e comparação com o histórico da tarefa. O risco é o produto tratar o texto como final quando ele deveria ser matéria-prima.

Quando a IA classifica, o usuário espera que um item seja colocado em uma categoria útil para o fluxo. A experiência precisa mostrar o rótulo sugerido, a razão da classificação e o impacto daquele rótulo. Se classificar muda prioridade, responsável ou próximo passo, isso precisa aparecer.

Quando a IA executa, a expectativa é mais forte. O produto deixa de sugerir e passa a alterar alguma coisa: enviar, publicar, mover, acionar, criar, encerrar. Aqui, a experiência deve ter critérios de confirmação e, em tarefas de maior impacto, revisão adicional.

A frase operacional ajuda a revelar a promessa real da funcionalidade. Por exemplo:

• A IA sugere a próxima ação para este ticket.
• A IA resume o histórico deste cliente para apoiar a triagem.
• A IA preenche um rascunho que será revisado antes do envio.
• A IA classifica a solicitação e propõe uma prioridade.
• A IA executa a alteração somente depois de confirmação.

Essa frase não é texto de marketing. É um instrumento de desenho. Se a equipe não consegue escrevê-la com clareza, a interface tende a compensar uma decisão de produto que ainda não foi tomada.

A Anthropic distingue fluxos com caminhos predefinidos de agentes que decidem dinamicamente seu processo e uso de ferramentas, e recomenda começar pela solução mais simples e acrescentar complexidade quando necessário, conforme seu artigo sobre padrões de agentes. Essa distinção não decide a experiência por você, mas ajuda a evitar uma confusão comum: chamar tudo de agente quando, para o usuário, talvez baste uma recomendação bem delimitada.

Desenhar a contestação como parte normal do fluxo

Contestar uma resposta de IA não deveria parecer um erro do usuário nem uma falha excepcional do sistema. Em uma funcionalidade inteligente, contestar é parte normal do trabalho.

É comum ver fluxos reduzirem contestação a um botão genérico de gostei ou não gostei. Esse tipo de reação pode servir para análise posterior, mas raramente ajuda a pessoa a terminar a tarefa naquele momento.

Uma contestação boa muda o próximo passo.

Se a IA usou um dado errado, o usuário deve conseguir corrigir o dado usado. Se a resposta veio estreita demais, deve conseguir pedir uma alternativa. Se a classificação estiver inadequada, deve poder trocar o rótulo e preservar a justificativa revisada. Se o impacto for alto, deve haver um caminho para revisão humana ou autorização dentro do fluxo.

Algumas formas concretas de contestação:

• Corrigir uma informação usada pela IA.
• Rejeitar a resposta e manter o fluxo manual.
• Pedir outra alternativa com o mesmo contexto.
• Editar a justificativa antes de confirmar.
• Marcar uma resposta como inadequada para a tarefa.
• Enviar a decisão para revisão de outra pessoa.

Há um limite que precisa ficar explícito: feedback do usuário não significa, por si só, que o modelo aprendeu automaticamente. A Microsoft descreve a ExP como uma plataforma para incorporar experimentação ao ciclo de desenvolvimento, validar hipóteses, medir impacto e iterar produtos, segundo sua página sobre experimentação. Isso sustenta a importância de testar hipóteses e medir impacto, mas não autoriza prometer que cada correção do usuário retreina o modelo em tempo real.

Para a experiência, essa distinção é decisiva. Se o produto diz “obrigado pelo feedback” e nada muda na tarefa atual, o usuário percebe que ajudou o sistema, mas não necessariamente concluiu seu trabalho. Se a contestação ajusta a próxima etapa, a IA passa a fazer parte de um fluxo operável.

Preservar continuidade quando a resposta não encerra a tarefa

Boa parte das respostas de IA não encerra a tarefa. Elas aproximam, organizam, sugerem ou reduzem incerteza. Por isso, desenhar continuidade é tão relevante quanto desenhar a resposta.

Continuidade significa que, depois de aceitar, ajustar ou rejeitar a saída da IA, o usuário segue em frente sem reinserir informações já fornecidas e sem perder o estado da tarefa.

Isso não quer dizer guardar tudo para sempre. Quer dizer manter o contexto suficiente para o próximo passo, dentro dos limites da funcionalidade.

A Anthropic define engenharia de contexto como a seleção e manutenção das informações disponíveis ao modelo durante a inferência, incluindo instruções, ferramentas, dados externos e histórico, dentro de uma janela limitada, em seu texto sobre engenharia de contexto. Para produto, a implicação prática é menos glamourosa e mais relevante: a equipe precisa decidir quais elementos do contexto são visíveis, reutilizáveis e descartáveis em cada etapa.

Continuidade pode aparecer de formas simples:

• Mostrar quais dados foram considerados na resposta.
• Permitir retomar uma alternativa sem refazer a pergunta.
• Manter a edição do usuário como novo estado da tarefa.
• Preservar a justificativa ajustada quando a prioridade muda.
• Oferecer continuação manual sem apagar a contribuição da IA.
• Registrar que uma recomendação foi rejeitada e seguir para outra ação.

Essa discussão se aproxima de liderança e humano ampliado, porque a melhor experiência não é a que elimina o julgamento humano. É a que coloca esse julgamento no ponto certo do fluxo.

Também há uma conexão direta com roadmap de IA. Se a continuidade exige mudanças profundas no fluxo, no modelo de dados ou nas permissões do produto, talvez a funcionalidade precise entrar no roadmap como capacidade de produto, não como ajuste de interface.

Priorização de tickets como hipótese de desenho

Imagine um exemplo fictício: um produto SaaS de atendimento adiciona uma funcionalidade de IA para apoiar a priorização de tickets de suporte.

A funcionalidade lê o texto do ticket, algumas informações do cliente disponíveis no produto e o histórico recente daquela solicitação. Em seguida, sugere uma prioridade e uma justificativa curta para a triagem.

A experiência pode ser desenhada de duas formas.

Na primeira, a interface mostra: “Prioridade alta”. Abaixo, um texto convincente. O usuário pode aceitar ou fechar. Parece eficiente, mas deixa perguntas abertas. A IA classificou ou executou? A prioridade já mudou no sistema? O usuário pode corrigir a justificativa? O que acontece se a sugestão estiver parcialmente certa?

Na segunda, a promessa funcional é explícita: “A IA recomenda uma prioridade para apoiar a triagem. A alteração só será aplicada depois da confirmação.”

Nesse fluxo, a expectativa fica clara. A IA recomenda, não executa sozinha.

A contestação também faz parte da tela. O usuário pode ajustar a prioridade sugerida, editar a justificativa, indicar que uma informação usada está incorreta ou enviar para revisão de um líder de suporte. Se ele muda a prioridade de alta para média, o produto pergunta se a justificativa deve ser atualizada. Se ele marca que o histórico considerado está incompleto, o fluxo permite seguir manualmente em vez de bloquear a triagem.

A continuidade aparece no próximo passo. Depois da confirmação, o ticket segue para a fila correspondente, com a justificativa revisada. Se a sugestão for rejeitada, o produto mantém o contexto da triagem e permite atribuir manualmente. Se a decisão exigir revisão, o ticket vai para uma etapa visível, não para um limbo operacional.

Nada nesse exemplo prova resultado. Os efeitos seriam hipóteses a medir: redução de retrabalho na triagem, maior clareza sobre decisões de prioridade, menor abandono do fluxo ou melhor consistência entre justificativa e ação. A utilidade do exemplo está no desenho da decisão, não em prometer desempenho.

Critérios para avaliar a experiência antes de lançar

Antes de lançar uma funcionalidade de IA, produto, design e engenharia deveriam avaliá-la com critérios de experiência e de operação. A pergunta não é apenas “a resposta está boa?”. É “a resposta permite uma decisão confiável dentro do fluxo?”.

A avaliação pode começar por seis critérios:

Critérios de desenho: expectativa, contestação e continuidade

Checklist proposto por este guia para avaliar uma funcionalidade de IA antes de detalhar interface, prompts ou métricas.

• Expectativa explícita: o usuário sabe se a IA está recomendando, redigindo, classificando, buscando informação ou executando uma ação? A condição mínima é conseguir descrever a função da IA em uma frase operacional dentro do fluxo.
• Limite visível: o usuário entende quando a resposta depende de contexto incompleto, dado desatualizado ou interpretação probabilística? A interface deve indicar incerteza ou escopo sem transferir para o usuário a responsabilidade de adivinhar o limite.
• Contestação acionável: o usuário tem uma forma clara de corrigir, rejeitar, pedir alternativa ou escalar a resposta? A contestação precisa mudar o próximo passo da tarefa, não apenas coletar uma reação genérica.
• Continuidade preservada: depois de aceitar, ajustar ou rejeitar a resposta, o usuário continua a tarefa sem reinserir informações já fornecidas? O fluxo deve manter contexto suficiente para o próximo passo.
• Saída manual disponível: existe um caminho claro para concluir a tarefa sem depender da IA? A IA deve apoiar o fluxo e preservar a operação quando a resposta não serve para a tarefa.
• Revisão alinhada ao risco: ações com maior impacto exigem confirmação, revisão ou autorização adicional? A autonomia da IA deve variar conforme o risco da tarefa.

Esses critérios também podem ser conectados a metas de confiabilidade. O Google SRE define objetivos de nível de serviço como metas de confiabilidade que orientam decisões de engenharia, com acordo sobre metas, uso de orçamento de erro para priorização e processo de revisão, no guia sobre objetivos de serviço. A aplicação ao produto não é copiar uma métrica pronta, mas tratar qualidade percebida, falhas aceitáveis e revisão como decisões explícitas.

Em outras palavras: se a experiência depende da IA acertar sempre, o desenho está frágil. Uma funcionalidade madura considera acerto parcial, incerteza, falha e interrupção como estados possíveis do fluxo.

Quando dar mais controle melhora a experiência

Existe uma tentação recorrente em produtos com IA: quanto mais a IA fizer sozinha, mais avançada a funcionalidade parece. Mas autonomia não é sinônimo de boa experiência.

Em algumas tarefas, a melhor decisão é a IA sugerir menos. Em outras, é pedir confirmação antes de agir. Em outras, é transferir a decisão para uma pessoa, mantendo o contexto organizado para que a revisão seja rápida e responsável.

Reduzir autonomia pode melhorar a experiência quando:

• O impacto da ação é difícil de reverter.
• O contexto disponível é frequentemente incompleto.
• A justificativa é tão relevante quanto a resposta.
• O usuário precisa prestar contas da decisão.
• A tarefa envolve exceções frequentes.
• A operação não pode parar quando a IA falha.

O ponto não é fazer a IA parecer maior dentro do produto. É escolher uma parte da tarefa que ela consiga apoiar sem confundir o usuário sobre o que foi sugerido, alterado ou confirmado.

Para a liderança, a pergunta de fechamento é prática: o fluxo deixa claro o que esperar, como contestar e como continuar? Se essa resposta ainda não estiver visível na experiência, vale redesenhar o fluxo antes de ampliar o papel da IA.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

• Inteligência no produto: como evoluir um software com IA
• Como preparar dados para uma funcionalidade inteligente
• Como integrar IA ao fluxo que o usuário já utiliza

Fontes

• Anthropic: Building effective agents
• Anthropic: Effective context engineering for AI agents
• Microsoft Research: Experimentation Platform
• Google SRE: Implementing SLOs