Agentes de IA como Usuários: Repensando a UX para Máquinas que Tomam Decisões

Pense no último fluxo de checkout que você projetou. Botões bem posicionados, hierarquia visual clara, feedback visual em cada etapa. Agora imagine que quem vai usar não é uma pessoa — é um agente de IA autônomo executando uma tarefa em nome de alguém.

O botão vermelho que você escolheu para chamar atenção? Irrelevante. A animação de loading? Invisível. O microcopy cuidadoso do CTA? Pode até atrapalhar se não for semanticamente claro.

Estamos entrando em uma fase onde parte significativa das interações com produtos digitais será feita por máquinas agindo em nome de humanos. E isso não é especulação — já está acontecendo com Claude Computer Use, Manus e dezenas de outras implementações de agentes em produção.

O problema: interfaces foram desenhadas para olhos humanos

Toda a disciplina de UX se construiu sobre uma premissa implícita: o usuário final é um humano com percepção visual, atenção limitada e padrões cognitivos específicos.

Isso moldou tudo:

• Hierarquia visual baseada em tamanho, cor e posição
• Feedback através de estados visuais (hover, loading, success)
• Prevenção de erros por atrito deliberado
• Affordances que dependem de reconhecimento visual

Quando o usuário é um agente de IA, essas premissas colapsam.

Um agente pode interagir com sua interface de três formas distintas:

1. Via API — acessa diretamente os endpoints, ignora a interface visual completamente
2. Via leitura de tela — interpreta o DOM ou elementos de acessibilidade
3. Via visão computacional — “olha” screenshots e decide onde clicar

Cada método tem implicações diferentes para o design. E a maioria dos produtos hoje está despreparada para qualquer um deles.

O que muda na prática

Clareza semântica supera clareza visual

Quando um humano olha um formulário, ele entende pelo contexto visual que “Nome” é um campo de texto e “Enviar” é a ação final. Um agente precisa dessa informação em estrutura — não em pixels.

Isso significa:

• Labels explícitos conectados programaticamente aos campos
• HTML semântico real (não divs com classes que “parecem” botões)
• Atributos ARIA corretos (não como checklist de acessibilidade — como fonte de informação)
• Estados e erros comunicados via texto, não apenas via cor

Interface para humanos

• Campo destacado em vermelho = erro
• Botão grande e verde = ação principal
• Loading spinner = aguarde
• Tooltip no hover = explicação

Interface para agentes

• aria-invalid='true' + mensagem de erro textual
• role='button' + aria-label descritivo
• aria-busy='true' + status textual
• Descrição inline ou aria-describedby

Perceba: não é que a versão visual está errada. É que ela é insuficiente quando o consumidor da interface não processa pixels.

Feedback precisa ser programático, não apenas visual

Um humano vê o botão mudar de cor e entende que a ação foi processada. Um agente precisa de confirmação estruturada — um status code, uma mudança de estado no DOM, um elemento que aparece ou desaparece de forma detectável.

Na prática, isso significa:

• Mudanças de estado refletidas no DOM, não apenas no CSS
• Mensagens de sucesso ou erro como elementos de texto, não apenas toast visual
• URLs que mudam quando o estado muda (deep linking funcional)
• Respostas consistentes e previsíveis para as mesmas ações

Prevenção de erros não pode depender de “você tem certeza?”

Diálogos de confirmação são uma técnica comum de prevenção de erros para humanos. Para agentes, podem ser armadilhas — ou simplesmente ignorados.

Se o agente está executando uma tarefa automatizada, ele vai clicar “sim” no diálogo de confirmação sem pensar. O diálogo não previne nada.

A prevenção de erros para agentes precisa ser estrutural:

• Ações destrutivas protegidas por autenticação adicional
• Rate limiting inteligente
• Validação server-side que não depende de confirmação do client
• Logs de ação que permitem reversão

As três camadas de acesso para agentes

O Nielsen Norman Group propõe um framework útil para pensar em interfaces agnósticas de usuário:

• APIs bem documentadas e consistentes para acesso direto
• Camada de acessibilidade robusta para agentes que leem tela
• Interface visual que também funciona para interpretação por visão

A maioria dos produtos hoje tem (com sorte) a terceira camada. Algumas têm APIs, mas desconectadas da experiência principal. Quase nenhuma pensa na camada de acessibilidade como uma interface para agentes.

Por que isso importa agora

Não estamos falando de um futuro distante. Agentes de IA já estão:

• Agendando reuniões acessando calendários
• Fazendo compras em nome de usuários
• Preenchendo formulários e submetendo documentos
• Navegando interfaces complexas para extrair informações

Se o seu produto não é acessível para agentes, você está criando uma barreira de adoção. E se o seu concorrente resolve isso primeiro, ele captura esse canal.

Mais concretamente: um agente que não consegue completar uma compra no seu e-commerce vai completar no concorrente que tem uma interface mais interpretável.

O que fazer com isso

Para quem gerencia produto

Comece a incluir “agent personas” no seu processo de discovery. Assim como você considera diferentes perfis de usuários humanos, considere:

• Agentes que acessam via API — o que eles precisam?
• Agentes que navegam via leitura de tela — sua acessibilidade está real?
• Agentes que usam visão computacional — seus elementos são interpretáveis?

Para quem projeta interface

• Priorize semântica sobre estética em elementos interativos
• Garanta que todo feedback visual tenha um equivalente programático
• Teste sua interface com leitores de tela — não como checklist, como uso real
• Documente a estrutura da interface, não apenas o design

Para quem desenvolve

• HTML semântico não é opcional — é a API da sua interface
• Estados de componentes devem ser refletidos em atributos, não apenas em classes CSS
• Considere endpoints alternativos para fluxos que dependem de confirmação visual

O paradoxo da interface invisível

Existe uma ironia aqui: quanto melhor você projetar para agentes, menos eles precisarão da interface visual. O endpoint ideal para um agente é uma API limpa. A interface visual se torna fallback — ou nem é usada.

Isso não significa que interfaces visuais vão desaparecer. Humanos ainda vão usar seu produto diretamente. Mas significa que o valor diferencial da interface visual muda: ela serve para supervisão, não para execução.

O humano olha a tela para verificar o que o agente fez. Não para fazer ele mesmo.

Isso inverte a hierarquia tradicional. A interface visual se torna uma camada de transparência sobre uma operação que acontece em outra camada.

O que isso exige de designers e PMs

Projetar para agentes exige uma mudança de mentalidade mais do que uma mudança de técnica. Não é sobre aprender novas ferramentas — é sobre abandonar a premissa de que o usuário vê o que você projetou.

• Você precisa pensar em estrutura antes de pensar em visual
• Você precisa considerar interpretação programática como um canal legítimo
• Você precisa aceitar que parte do seu trabalho vai ser “invisível” no sentido tradicional

O designer que entende isso agora vai estar preparado para um mercado que ainda está acordando para o problema. O que não entende vai continuar otimizando cores de botão para um usuário que nem vai olhar para eles.