Machine Experience, ou MX, é a qualidade da experiência que uma máquina tem ao usar o seu produto digital. Quando alguém pede a um assistente de inteligência artificial para consultar um status, comparar opções ou concluir um pedido, quem chega na sua interface não é mais a pessoa, é um agente agindo em nome dela. E a opinião que essa pessoa vai formar sobre o seu produto depende de o agente conseguir ou não terminar a tarefa.

Muito já se fala da experiência das pessoas usando IA, mas o caminho inverso, a experiência que a máquina tem dentro do seu sistema, ainda não é tão explorada pelos times de produto.

O que é Machine Experience (MX)

MX é a qualidade da experiência de um agente de IA ao interagir com um produto digital. Para agir corretamente, esse agente precisa entender o que existe no sistema, quais ações são possíveis, em que estado cada coisa está e o que aconteceu depois que ele executou uma ação. Quando o produto responde bem a isso, o agente conclui a tarefa. Quando não responde, ele erra, desiste ou recomenda outra opção para a pessoa.

Qual a diferença entre UX, AX e MX

Sigla	Quem é o usuário	Pergunta central
UX (User Experience)	A pessoa usando o produto	A pessoa consegue realizar o que precisa?
AX (Agent Experience)	A pessoa que delega ao agente	Ela entende, confia e mantém controle sobre o que é feito em seu nome?
MX (Machine Experience)	O agente que opera no seu produto	O agente conclui a tarefa sem interpretar nada errado?

AX e MX apontam para lados opostos: em AX, a IA é funcionalidade do seu produto e trabalha para o seu usuário. Em MX, a IA é quem está usando o seu produto, e o seu produto é o objeto da experiência.

Por que agentes de IA já são usuários do seu produto?

No artigo do Nielsen Norman Group publicado em abril de 2026, escrito por Sarah Gibbons e Kate Moran, AI Agents as Users, um agente tem um objetivo, encontra uma interface, tenta cumprir esse objetivo através dela, e a interface sustenta ou não sustenta a tentativa. Funcionalmente, isso é um usuário, e não reconhecer esses agentes como usuários não impede que eles já estejam usando os produtos, inclusive falhando ao usar.

Segundo dados da Adobe Analytics divulgados em abril de 2026, o tráfego originado por IA em sites de varejo norte-americanos cresceu 393% no primeiro trimestre de 2026 na comparação com o ano anterior, depois de um crescimento de 693% durante a temporada de compras de 2025. E esse tráfego passou a converter melhor do que o tráfego humano vindo de canais tradicionais, com 37% mais receita por visita.

No mesmo levantamento, a Adobe mediu quanto do conteúdo desses sites é efetivamente legível por modelos de IA. As páginas iniciais ficaram em uma média de 75% de visibilidade e as páginas de produto em 66%. Ou seja, um terço do que existe nas páginas de produto simplesmente não chega até quem está decidindo a compra em nome do cliente.

O que precisa ter atenção é que esse usuário não reclama, não abre chamado, não responde pesquisa de satisfação e não aparece no NPS. Quando não consegue concluir a tarefa, ele desiste ou sugere um concorrente para conseguir finalizar a tarefa. A empresa perde a oportunidade sem nem saber que perdeu, e essa é uma perda que não entra em nenhuma conta de ROI de UX.

Por que isso não se resolve só com integração?

A primeira reação é tratar MX como assunto só de engenharia mas o que faz um agente falhar dentro de um produto costuma ter origem em decisões de design, não de infraestrutura.

Na prática, o agente erra quando:

• A ação principal está atrás de um ícone sem rótulo, e ele não sabe o que aquele botão faz. 
• O texto do botão diz “continuar” sem indicar o que acontece depois, e ele confirma uma etapa que não deveria. 
• O estado de um item é comunicado apenas por cor, e ele entende como disponível algo que está bloqueado. 
• As informações estão agrupadas só visualmente, sem estrutura por trás, e ele relaciona dados errados entre si. 
• Cada tela segue um padrão diferente, e o erro de uma etapa se multiplica nas seguintes. 
• O sistema não confirma de forma explícita que a ação deu certo, e ele repete a operação.

Clareza na nomeação, hierarquia coerente e comportamento previsível sempre foram fundamentos de boa experiência. A diferença é que costumavam ser tratados como refinamento que entra quando sobra tempo no cronograma, e agora viraram determinantes para um agente usar o seu produto. Quem já investiu em estrutura e governança de design sai na frente sem ter feito nada de novo.

O que muda no produto quando a máquina também é usuária

No projeto com a Arlequim Technologies, entregamos 33 famílias de componentes, cada uma com seus estados, variações, documentação de uso e consistência entre os modos light e dark. No projeto com a PRIMe Unimed, foram 27 componentes personalizados construídos sobre Angular Material, junto com o redesenho de 9 fluxos e a reestruturação de menus e hierarquias.

Nos dois casos existe uma documentação de quais objetos existem, em que estados eles podem estar e quais ações são possíveis sobre eles, usada igualmente por design, produto e desenvolvimento. Essa base foi construída pensando em pessoas, mas essa organização torna um produto legível também para uma máquina. Design System entregue como biblioteca de telas bonitas não resolve mais. Design System é vantagem competitiva quando estamos falando de agentes usando o produto.

Na Medeor MedTech, o nosso desafio era projetar uma solução de IA que apoiasse profissionais de saúde durante o atendimento clínico, com sugestões e acesso facilitado aos dados do paciente, sem interromper o fluxo de trabalho. Aquele projeto era AX, com a IA trabalhando para o usuário final. Antes de qualquer interface, fomos entender como o atendimento acontece, quais informações o profissional precisa em cada etapa e onde a IA gerava valor real em vez de aumentar carga cognitiva num contexto que já é denso. Muda o interlocutor, muda o problema, e em nenhum dos dois casos a resposta vem pronta da tecnologia.

Quando não faz sentido abrir o produto para agentes

Antes que isso vire corrida, vale dizer que nem todo produto ganha com agente dentro. O próprio Nielsen Norman Group levanta situações em que facilitar essa entrada é decisão ruim:

• Quando a visita é o produto, como em modelos que vivem de publicidade ou de tempo de navegação. 
• Quando o atrito existe por razão regulatória ou de segurança, como em serviços financeiros e saúde. 
• Quando o dado por trás da interface é competitivamente sensível, como preço e disponibilidade em tempo real.
• Quando a própria empresa quer ser a camada inteligente sobre os seus dados.

O arriscado é deixar isso acontecer por omissão, se um concorrente passar a suportar agentes e você não, essa precisa ter sido uma escolha da empresa.

Por onde um time de produto começa

Dá para começar a pensar em MX sem ter que parar o time para isso:

1. Peça para alguém do time completar três tarefas centrais do produto usando um agente e registre onde ele trava. É o teste mais barato disponível hoje.
2. Separe, nos logs, tráfego automatizado de tráfego humano. Muita empresa descobre nessa hora que já tem um público que não está sendo medido.
3. Revise a acessibilidade dos fluxos críticos com critério de experiência, não como checklist de conformidade.
4. Verifique se o seu Design System documenta estados e ações possíveis, e não apenas aparência.
5. Decida conscientemente onde você quer agentes e onde não quer, e registre o motivo da decisão.

Pessoas vão continuar precisando de interface, de contexto e de espaço para decidir, e essa parte não desaparece. O que muda é que a experiência da pessoa passa a depender também da capacidade do agente dela de concluir a tarefa dentro do seu produto. Isso continua sendo uma decisão de design, tomada por pessoas.

Se o seu time está começando a esbarrar nesse assunto e quer entender o que fazer primeiro, fala com a gente.

E se quiser dar um passo antes disso, baixe gratuitamente o nosso Template de Diagnóstico de Produto, que traz um bloco de perguntas específico para quem está construindo funcionalidades com IA.

Perguntas frequentes sobre Machine Experience

O que significa MX em design de produto? MX significa Machine Experience e descreve a qualidade da experiência que um agente de inteligência artificial tem ao interagir com um produto digital. O foco é se a máquina consegue entender o sistema e concluir tarefas dentro dele.

Qual a diferença entre MX e AX? AX, ou Agent Experience, trata da experiência da pessoa que delega tarefas a um agente de IA. MX trata da experiência do agente que opera dentro do seu produto. Em AX a IA é funcionalidade do produto, em MX a IA é usuária dele.

MX substitui UX? Não. Pessoas continuam precisando de interfaces desenhadas para compreensão e decisão. MX acrescenta um segundo público ao trabalho de design e cobra com mais urgência fundamentos que já eram conhecidos, como clareza de nomeação, hierarquia coerente e previsibilidade.

MX é a mesma coisa que SEO para IA? Não. Otimizar conteúdo para ser encontrado e citado por IAs é um trabalho de descoberta. MX começa depois, quando o agente já está dentro do produto e precisa entender o que pode fazer ali e agir com segurança.

Por onde uma empresa deve começar a olhar para MX? O primeiro passo é observar um agente tentando completar tarefas centrais do produto e registrar onde ele falha. Em seguida, revisar acessibilidade dos fluxos críticos e verificar se o Design System documenta estados e ações, não apenas componentes visuais.