UX/UI não morre: a próxima interface será um contrato de delegação

Há uma frase que começa a circular com cada vez mais força: a interface de utilizador caminha para a morte.

O argumento parece evidente. Se posso dizer ao computador “revê estes emails, cruza as reclamações com o CRM, prepara uma resposta para cada cliente e avisa-me antes de enviar”, por que razão haveria de abrir quatro aplicações, aprender os seus menus e executar cada passo com o rato?

A conclusão, no entanto, confunde duas coisas diferentes: a redução da interação manual e o desaparecimento da experiência de utilizador.

Não estamos a deixar de desenhar interfaces. Estamos a mudar aquilo que a interface governa.

Durante décadas, os produtos digitais partiram do princípio de que uma pessoa tinha de traduzir a sua intenção numa sequência de ações: abrir, procurar, selecionar, preencher, comparar, confirmar. Os agentes alteram essa relação porque permitem expressar um resultado e delegar parte do percurso. Mas quanto mais trabalho o sistema executa, mais precisamos de compreender o seu âmbito, as suas decisões operacionais, as suas permissões, a evidência que produz e a sua capacidade de recuperação.

A interface deixa de ser apenas o lugar onde fazemos o trabalho. Torna-se o lugar onde definimos, autorizamos, supervisionamos, verificamos e, quando necessário, desfazemos o trabalho realizado por um agente.

Em resumo

UX/UI não morre. Perde o monopólio da execução direta.

A voz será uma excelente porta de entrada para expressar intenção, interromper e coordenar. O ecrã continuará a ser superior para comparar opções, rever grandes volumes de evidência, editar detalhes, detetar anomalias e compreender consequências.

O futuro mais provável não é uma experiência voice-only, mas uma arquitetura híbrida:

• Voice-first quando falar for a forma mais rápida de declarar um objetivo, acrescentar contexto ou mudar de direção.
• Visual-first quando verificar, comparar ou autorizar exigir precisão.
• API-first para o agente quando existir uma ferramenta estruturada e fiável.
• GUI ou intervenção humana quando a capacidade não estiver disponível, o contexto for ambíguo ou o risco exigir controlo direto.

E sim: vamos desenhar UX para agentes. Mas isso não significa criar ecrãs de que uma IA “goste”. Significa desenhar uma superfície semântica que o agente consiga descobrir e utilizar com fiabilidade: ferramentas com nomes inequívocos, parâmetros tipados, resultados estruturados, permissões mínimas, erros acionáveis, estados consultáveis e operações reversíveis.

O entregável estratégico deixará de ser apenas um wireframe ou um fluxo. Será um contrato de delegação.

A voz muda o ponto de entrada, não elimina a interface

A 5 de agosto de 2026, a documentação oficial da OpenAI descreve uma experiência em que o ChatGPT Voice pode ser utilizado com Work e Codex para iniciar tarefas, verificar progresso, definir prioridades, interromper, redirecionar e coordenar vários agentes através de uma conversa. O GPT-Live acrescenta uma arquitetura full-duplex: consegue ouvir e falar ao mesmo tempo e manter a conversa enquanto delega trabalho mais complexo.

Isto reduz drasticamente o custo de expressar intenção. Já não é necessário saber antecipadamente onde vive cada função. Podemos dizer, em linguagem natural, aquilo que queremos alcançar.

Mas falar não é o mesmo que conceder controlo ilimitado.

O Modo Voz utiliza as ferramentas e permissões disponíveis na experiência selecionada. O contexto do computador pode exigir acesso ao microfone, gravação de ecrã e áudio, acessibilidade, ficheiros locais ou aplicações específicas. Um workspace pode ativar ou restringir funcionalidades. Uma ferramenta pode ler dados sem os poder alterar, criar rascunhos sem os poder enviar ou preparar uma alteração sem a poder colocar em produção.

A voz faz a interação parecer contínua. As permissões, os limites e os estados continuam a ser discretos.

Por isso, uma boa experiência deve separar, verbal e visualmente, pelo menos três mensagens:

“Ouvi-te.”

“Aceitei a nova instrução.”

“A instrução já foi aplicada às tarefas ativas.”

Não são equivalentes. Num sistema com várias tarefas em paralelo, uma correção pode afetar apenas um ramo, chegar tarde demais para uma ação já executada ou ficar pendente de aprovação. A fluidez da conversa não pode esconder essa realidade operacional.

O agente é um androide sem corpo

A metáfora mais útil não é “um chatbot mais inteligente”. É um androide sem corpo.

Pode falar connosco, ouvir enquanto pensamos, observar partes do ambiente digital e utilizar as “mãos” que lhe são emprestadas por ferramentas, APIs, conectores, terminais e permissões do sistema. Também pode manter contexto, coordenar subtarefas e reagir a eventos.

Capacidade metafórica	Implementação digital
Voz	Conversa speech-to-speech, transcrição e síntese
Ouvidos	Microfone, deteção de atividade e áudio partilhado
Olhos	Capturas, navegador, ficheiros e dados estruturados
Mãos	APIs, ferramentas MCP, terminal, conectores e automatizações
Memória	Contexto de conversa, ficheiros e instruções autorizadas
Sistema nervoso	Orquestração, eventos, estados e chamadas a ferramentas
Consciência de limites	Policies, sandbox, permissões, schemas e checkpoints humanos

O ponto decisivo é que não tem mãos universais. Emprestamos-lhe mãos específicas.

Pode ler email se existir uma ferramenta autorizada para o fazer. Pode redigir se a ferramenta permitir criar rascunhos. Só pode enviar se existir uma ação de envio e a autoridade concedida incluir esse verbo, esse destinatário e esse volume. Pode analisar transações sem ter permissão para cancelar uma subscrição. Pode preparar um rollback sem o poder executar em produção.

Cada verbo adicional — ler, alterar, publicar, enviar, apagar, pagar — aumenta o raio de impacto.

É por isso que a interface não desaparece. Quando o sistema apenas sugere, o custo de um erro pode ser uma resposta fraca. Quando atua, o erro pode propagar-se para fora da conversa. O design deve tornar visível a diferença entre capacidade e autoridade.

Do design de ecrãs ao design de colaboração

A UX tradicional organiza possibilidades: menus, botões, hierarquias e percursos. A UX agêntica tem de organizar responsabilidades.

Antes desenhávamos uma ação: “Enviar”. Agora temos de desenhar uma delegação completa:

“Identifica os clientes afetados, redige uma resposta com base nesta política, não prometas compensações superiores a 100 euros, cria rascunhos mas não envies nada e avisa-me quando encontrares um caso ambíguo.”

O produto tem de converter esta frase num estado operacional verificável. Deve distinguir:

• O resultado pretendido.
• As fontes autorizadas e excluídas.
• As ações permitidas e proibidas.
• Os limites de dinheiro, volume, tempo e âmbito.
• Os critérios de sucesso.
• Os pontos que exigem intervenção humana.
• A evidência que demonstrará que o trabalho foi bem executado.
• A forma de corrigir ou reverter o resultado.

Isto altera a unidade mínima de design. Já não é apenas o clique. É a relação de trabalho entre uma pessoa, um ou vários agentes e os sistemas sobre os quais atuam.

O Magentic-UI explora esta relação através de coplaneamento, cotarefas, multitarefa, guardas de ação e memória. A ideia importante não é uma interface concreta, mas a existência de graus de participação: supervisão distante, controlo próximo, resolução conjunta ou tomada de controlo total pela pessoa. O utilizador deve conseguir mudar de nível sem reiniciar toda a tarefa.

Um plano, por exemplo, não deve ser uma lista decorativa gerada pelo modelo. Deve ser um objeto manipulável: reordenar passos, cancelar um ramo, mudar uma fonte, reduzir o âmbito ou acrescentar um checkpoint obrigatório.

Vamos desenhar UX/UI para agentes?

Sim, mas convém separar duas disciplinas que vão partilhar o mesmo produto.

UX para pessoas que colaboram com agentes	Experiência para agentes que usam sistemas
Linguagem compreensível	Nomes de ferramentas inequívocos
Resumo antes do detalhe	Schemas estritos de entrada e saída
Comparação visual	Dados estruturados e tipados
Explicação contextual	Descrições operacionais precisas
Confirmação proporcional ao risco	Sinais de impacto e reversibilidade
Pausa, redirecionamento e tomada de controlo	Estados de tarefa consultáveis
Evidência e proveniência	Identificadores estáveis e referências
Undo e recuperação	Operações idempotentes ou compensatórias
Acessibilidade multimodal	Erros legíveis por máquina
Responsabilidade organizacional	Logs e rastos auditáveis

Para uma pessoa, uma capacidade pode ser representada por texto, um cartão, um botão, uma comparação ou uma conversa. Para um agente, a mesma capacidade precisa de uma representação estruturada.

O Model Context Protocol formaliza parte desta segunda superfície. Uma ferramenta pode declarar nome, descrição, inputSchema, outputSchema e resultados estruturados. Isto permite ao agente descobrir o que existe, validar parâmetros e receber uma saída sem depender da interpretação de um ecrã.

Mas um protocolo não substitui o design. Uma função chamada processItem continua ambígua. Uma ferramenta chamada create_refund_draft, que exige order_id, reason, maximum_amount e requires_human_approval, comunica muito melhor a sua intenção, os seus limites e o seu risco.

A nova responsabilidade de produto é desenhar a superfície semântica das ferramentas.

A investigação AXIS oferece um sinal útil: longas sequências de cliques visuais podem introduzir latência e menor fiabilidade, enquanto uma abordagem API-first pode concluir tarefas com menos passos. Os resultados foram obtidos no Microsoft Word e não devem ser generalizados sem cuidado, mas ilustram uma direção clara: as aplicações preparadas para agentes vão precisar de capacidades estruturadas, além de ecrãs para pessoas.

O novo entregável: um contrato de delegação

Um contrato de delegação não é necessariamente um documento jurídico nem um único ecrã. É o conjunto observável de condições que determina o resultado pretendido, aquilo que o agente pode fazer e a forma como o seu trabalho será verificado.

Pode organizar-se em oito camadas.

Camada	Pergunta de design	Affordance necessária
Intenção	Que resultado entendeu o sistema?	Resumo editável: “Entendi que…”
Contexto	Que fontes, períodos e exclusões vai utilizar?	Painel de fontes e atualidade
Capacidade	Que ferramentas existem e estão ligadas?	Inventário de capacidades e estado
Autoridade	O que pode ler, alterar, enviar ou apagar?	Permissões por verbo, objeto e impacto
Plano	Como se decompõe a tarefa e onde se decide?	Timeline editável e checkpoints
Execução	O que está em curso, bloqueado ou alterado?	Estado observável, pausa e takeover
Evidência	O que prova que o resultado está correto?	Diffs, fontes, testes e proveniência
Recuperação	Como se corrige, reverte ou escala?	Undo, rollback e ações compensatórias

Intenção

“Limpa a minha caixa de entrada” é ambíguo. “Arquiva newsletters com mais de 90 dias, etiqueta faturas e não apagues mensagens” define um resultado e limites. Antes de iniciar uma tarefa ampla, a interpretação deve poder ser editada.

Contexto

O utilizador precisa de saber que dados entram e quais ficam de fora. Uma análise de contas deve indicar bancos, períodos, moedas e atualidade. “Não encontrei os dados” não é o mesmo que “não tenho permissão”, “a fonte não está ligada” ou “a ferramenta falhou”.

Capacidade e autoridade

Ter uma ferramenta não implica permissão para usar todas as suas ações. Ler não é alterar. Alterar não é publicar. Publicar não é apagar. A autoridade deve ser concedida por verbo, objeto, período, volume e nível de impacto.

Plano e execução

O plano deve permitir alterações sem reiniciar o trabalho. A execução tem de mostrar que ramos continuam ativos, que instrução utiliza cada um e que ações já não podem ser desfeitas.

Evidência

Uma resposta convincente não chega. O agente deve ligar afirmações e alterações a fontes, operações, diffs, testes ou capturas. O Codex já mostra parte deste padrão ao devolver alterações para revisão, resultados de terminal e evidência de validação.

Recuperação

Cada ação com efeitos deve declarar se é reversível, parcialmente reversível ou irreversível. Quando não existe undo técnico, o produto precisa de uma ação compensatória: restaurar uma versão, enviar uma correção, criar um ticket ou escalar para uma pessoa responsável.

Padrões concretos para uma interface agêntica

A teoria torna-se útil quando é traduzida em componentes de produto.

Cabeçalho de missão

Deve mostrar o objetivo atual, o agente responsável, o ambiente de execução, o tempo decorrido, o estado e o nível de autoridade. Estados como a preparar, à espera de aprovação, em execução, bloqueado, a verificar, concluído, falhou e revertido são mais informativos do que uma animação genérica de “a pensar”.

Resumo do resultado

Um fecho útil deve responder a seis perguntas:

Campo	Conteúdo
Resultado	O que foi alcançado
Âmbito	Que fontes, contas ou ficheiros foram processados
Alterações	O que foi modificado fora da conversa
Exceções	O que ficou incompleto e porquê
Riscos	Que pressupostos ou incertezas permanecem
Próxima ação	O que convém fazer agora

Timeline de atividade

Não precisa de expor raciocínios privados nem uma transcrição interminável. Deve registar ações observáveis: ferramenta utilizada, objeto afetado, hora, resultado, evidência gerada e reversibilidade.

Cartão de aprovação

“Preciso de permissão” é insuficiente. A aprovação deve descrever uma ação concreta:

Ação: enviar 14 respostas
Destinatários: lista para revisão
Fonte do conteúdo: política de suporte v3.2
Dados incluídos: nome, encomenda e proposta de compensação
Impacto: comunicação externa
Reversibilidade: irreversível depois do envio
Alternativas: guardar rascunhos / enviar 2 casos de teste
Aprovação válida durante: 10 minutos

Proveniência e incerteza

Cada afirmação ou gráfico importante deve estar ligado à fonte, data, ferramenta e transformação. Um “92% de confiança” isolado diz pouco. É melhor explicar a causa: “faltam dois extratos”, “três documentos contradizem a política atual” ou “a classificação utiliza correspondência aproximada”.

Centro de recuperação

O botão não deve dizer apenas “Desfazer”. Deve explicar o que será restaurado e qual o raio de impacto: “Restaurar 18 etiquetas de email para o estado das 10:42”.

A segurança também é uma decisão de UX

Um agente que lê páginas, emails ou documentos pode encontrar instruções maliciosas incorporadas nesses materiais. Se também tiver ferramentas com permissões amplas, uma entrada não fiável pode transformar-se numa ação real.

A OWASP usa o email como exemplo de agência excessiva: um assistente que só precisa de ler mensagens recebe também capacidade de envio, e uma injeção indireta tenta levá-lo a reencaminhar informação sensível. A mitigação não consiste apenas em escrever um prompt melhor. Consiste em eliminar funções desnecessárias, usar credenciais de leitura, exigir revisão antes do envio e limitar o volume.

A resposta de UX também não pode ser pedir confirmação para cada microação. Isso cria fadiga e ensina as pessoas a aprovar sem ler. O design deve combinar:

• Privilégio mínimo por defeito.
• Aprovações em momentos de impacto significativo.
• Separação entre leitura, escrita, publicação e eliminação.
• Limites de volume, dinheiro, tempo e destinatários.
• Estado visível e capacidade de paragem.
• Evidência posterior e registo auditável.
• Recuperação técnica ou compensatória.

A governação atravessa todo o produto. O NIST AI RMF organiza a gestão do risco em torno de Govern, Map, Measure e Manage. Para o design, isto implica definir papéis, responsáveis, critérios de avaliação e procedimentos de incidente antes de uma demonstração se transformar em infraestrutura crítica.

Que trabalho vai diminuir e que trabalho vai crescer

A parte desconfortável é que nem todas as tarefas atuais vão conservar o mesmo valor.

É razoável esperar menos procura por trabalho centrado exclusivamente em produzir muitas variações de ecrãs, documentar percursos determinísticos ou converter requisitos estáveis em componentes previsíveis. Os agentes já conseguem acelerar parte dessa produção e a linguagem natural reduzirá alguns passos intermédios.

Outras responsabilidades vão crescer:

• Modelar como uma intenção aberta se transforma num objetivo verificável.
• Desenhar transições entre autonomia, colaboração e tomada de controlo humana.
• Definir permissões e aprovações proporcionais ao risco.
• Desenhar estados para tarefas paralelas e de longa duração.
• Criar ferramentas e APIs compreensíveis por agentes.
• Representar proveniência, incerteza e cobertura de evidência.
• Desenhar undo, rollback e ações compensatórias.
• Avaliar comportamento, não apenas ecrãs.
• Trabalhar com segurança, jurídico, operações e negócio na governação.
• Manter acessibilidade entre voz, texto, imagem, teclado e controlo direto.

O designer deixa de ser apenas quem organiza controlos numa superfície. Passa a participar na definição de quem pode fazer o quê, em nome de quem, com que informação, sob que limites e com que responsabilidade.

O que uma equipa de design deve fazer hoje

Não é preciso esperar que toda a organização tenha agentes autónomos. Pode começar-se com seis perguntas aplicadas a qualquer fluxo existente:

1. Que resultado tenta alcançar a pessoa? Não que botão carrega, mas que alteração quer produzir no mundo.
2. Que partes podem ser delegadas em segurança? Separar investigação, preparação, alteração e publicação.
3. Que evidência permitiria verificar o resultado? Fontes, diffs, testes, amostras ou métricas.
4. Onde deve intervir uma pessoa? Ambiguidade, impacto externo, dinheiro, dados sensíveis ou irreversibilidade.
5. Como recupera o sistema de um erro? Undo, snapshot, rollback ou ação compensatória.
6. Como se expõe a mesma capacidade a pessoas e agentes? Uma representação compreensível e outra estruturada.

Também convém alterar os entregáveis. A par do journey map ou do protótipo, uma equipa deve documentar:

• Matriz de autoridade por ação.
• Modelo de estados e eventos.
• Inventário de ferramentas.
• Schemas e erros esperados.
• Checkpoints humanos.
• Plano de evidência e proveniência.
• Estratégia de recuperação.
• Métricas de qualidade da colaboração.

A próxima grande interface não será um ecrã

A interface gráfica não desaparece. Deixa de ser o centro exclusivo da experiência.

Continuaremos a precisar de botões, formulários, tabelas, gráficos e editores. Mas a sua função muda. Em muitos casos, deixarão de ser o instrumento com que executamos cada passo para se tornarem a superfície onde compreendemos a missão, delimitamos autoridade, observamos progresso, revemos evidência e decidimos se aceitamos, corrigimos ou revertemos.

A voz torna esta mudança visível porque nos permite expressar intenção sem percorrer manualmente o software. O Codex e outros agentes tornam-na operacional porque conseguem utilizar ferramentas, agir em paralelo e produzir alterações para revisão. Esta combinação não mata UX/UI. Obriga a disciplina a amadurecer.

Passamos de desenhar instrumentos que uma pessoa opera diretamente para desenhar relações de trabalho com um androide sem corpo: um sistema que ouve, observa, executa, se engana e precisa de limites compreensíveis.

A próxima grande interface não será apenas um ecrã.

Será um contrato.

Perguntas frequentes

A voz vai substituir as interfaces gráficas?

Não. A voz reduz o custo de expressar intenção, iniciar trabalho e interromper uma tarefa. As interfaces visuais continuam a ser melhores para comparar alternativas, rever evidência, editar com precisão, compreender estados complexos e confirmar ações de risco.

Haverá menos trabalho para designers UX/UI?

Provavelmente haverá menos trabalho centrado exclusivamente em produzir variações de ecrãs e fluxos determinísticos. Crescerá o trabalho sobre modelos de interação, permissões, observabilidade, comportamento, avaliação, acessibilidade multimodal, recuperação e governação.

O que significa desenhar UX para agentes?

Significa criar capacidades que um agente consiga descobrir e invocar de forma fiável: nomes de ferramentas claros, schemas estritos, resultados estruturados, permissões mínimas, erros acionáveis, estados consultáveis e operações reversíveis.

O que é um contrato de delegação?

É a especificação observável que liga o resultado pedido ao contexto autorizado, às ferramentas disponíveis, aos limites de autoridade, ao plano, aos checkpoints, à evidência, à responsabilidade e às opções de recuperação.

Quando deve um agente pedir aprovação?

Quando uma ação produz um efeito externo significativo, expõe dados sensíveis, aumenta privilégios, envolve dinheiro, afeta terceiros, ultrapassa o âmbito concedido ou é difícil de reverter. A aprovação deve ser proporcional ao risco, não uma interrupção para cada microação.

Como se mede uma boa experiência humano-agente?

Para além de sucesso e velocidade, convém medir correções necessárias, intervenções evitáveis, tempo para detetar erros, cobertura de evidência, cumprimento do âmbito, qualidade da recuperação, confiança calibrada e percentagem de ações reversíveis.