A indústria de produto digital tem um novo acrónimo. E desta vez não é cosmético.

​

O Design in Tech Report 2026, apresentado no SXSW por John Maeda (VP de Engineering na Microsoft), introduz uma ideia simples e incómoda: estamos a passar de UX para AX. De User Experience para Agentic Experience. De experiências desenhadas para pessoas que clicam, navegam e decidem, para experiências onde agentes de Inteligência Artificial agem em nome dessas pessoas.

​

A implicação é direta. Se durante duas décadas o trabalho de um Product Designer foi ajudar alguém a fazer algo, agora o problema passa a ser diferente: como é que ajudo alguém a perceber se aquilo foi bem feito?

​

Esta é uma mudança que não se resolve com um novo plugin no Figma. Muda o que desenhamos, como avaliamos qualidade e onde o nosso trabalho tem mais impacto. E, ao contrário do que podes estar a pensar, não significa menos Design. Significa Design diferente, iremos explorar exatamente o quê ao longo deste artigo. Se ainda estás a dar os primeiros passos neste mundo, a Imersão User Experience 101 da TheStarter (gratuita e online) é um bom ponto de partida para entender os fundamentos antes de mergulhar no que vem a seguir.

​

O fosso que mudou de lado

​

A distinção que Maeda usa vem de um conceito clássico de Design de interação, proposto por Don Norman nos anos 80. Norman identificou dois fossos entre o utilizador e o sistema: o fosso da execução e o fosso da avaliação. Dois espaços onde o Design tem de intervir para que a experiência funcione.

​

O fosso da execução é a distância entre o que uma pessoa quer fazer e o que a interface lhe permite fazer. Durante décadas, o trabalho de UX foi reduzir essa distância. Menos cliques, menos fricção, menos confusão. Fluxos claros, hierarquias visuais legíveis, feedback imediato.

​

O fosso da avaliação é diferente. É a distância entre o que o sistema fez e a capacidade da pessoa de perceber se o resultado está correto.

​

Num mundo onde o teu próximo utilizador pode não ser humano, o fosso da execução encolhe drasticamente. O agente não precisa de um botão para reservar um voo. Não precisa de um menu para filtrar resultados. Não precisa de um processo guiado para completar um checkout. Ele executa. E é aí que o segundo fosso se abre.

​

Como é que o utilizador sabe que o voo reservado é o melhor? Que o filtro aplicado não excluiu opções relevantes? Que o agente não tomou um atalho que lhe custa dinheiro? Esta é a nova superfície de Design. Não o ecrã onde alguém clica, mas o momento onde alguém confia, ou deixa de confiar.

​

Desenhar para agentes não é desenhar menos interfaces. É desenhar os momentos onde um ser humano precisa de decidir se confia no que a máquina fez.

​

E há uma razão pela qual esta transição é mais difícil do que parece: código é fácil de avaliar. Funciona ou não funciona. Design é mais ambíguo. Como a Anthropic descreve no seu artigo sobre avaliação de agentes de Inteligência Artificial, os agentes operam em loops de ação, resultado, feedback e correção. Em domínios onde o feedback é claro (como programação), a Inteligência Artificial melhora rapidamente. Em domínios onde o julgamento é subjetivo (como Design), a melhoria é mais lenta. Não porque o Design seja menos importante, mas porque é mais difícil de medir.

​

O design system já não é documentação. É uma instrução para uma máquina

​

Se a mudança de UX para AX parece abstrata, há uma consequência muito concreta que já está a acontecer nas equipas de produto: os design systems estão a mudar de audiência.

​

Há uma ideia que tem circulado com força nas comunidades de Design de produto. O raciocínio é mais ou menos este: durante anos, um design system era documentação para developers. Componentes, tokens, estados, convenções de nomenclatura. A equipa de Design criava a biblioteca, a equipa de engenharia consultava-a, e o resultado era (com sorte) consistência visual.

​

Agora, o consumidor do design system pode ser uma máquina. Um agente de Inteligência Artificial que lê os teus componentes no Figma através do MCP (Model Context Protocol), interpreta os tokens semânticos, entende os estados de cada componente e gera código a partir dessa estrutura.

​

Isto muda tudo. Porque quando um developer interpretava mal o teu Design, o resultado era aborrecido mas recuperável. Havia uma revisão de código, uma conversa, um ajuste. Quando uma máquina interpreta mal o teu Design, replica o erro à escala, sem hesitar.

​

Os fundamentos que as equipas de design systems sempre defenderam (tokens semânticos em vez de hex codes soltos, nomenclatura consistente entre Figma e código, todos os estados desenhados para cada componente) passam de boas práticas a pré-requisitos operacionais. Sem tokens semânticos, o agente adivinha que cor usar, e adivinha mal. Sem estados completos, o agente assume que o único estado que existe é o default. Sem Code Connect configurado, o agente sabe que um botão existe no Figma mas não faz ideia de que é o mesmo botão que os developers já implementaram.

​

Queres aprofundar como funcionam design systems na prática, desde os fundamentos até à escala? Na TheStarter temos o curso Design Systems [Completo], online e ao vivo. Fazemos várias turmas por ano.

​

A configuração técnica é um investimento de uma vez. Mas há um problema mais profundo que nenhum setup resolve.

​

A armadilha da montagem eficiente

​

Este novo modelo de trabalho com agentes vai puxar na direção da eficiência. E eficiência, neste contexto, significa: montar rápido a partir de peças que já existem.

​

Se tratares a biblioteca de componentes como ponto de partida (em vez de resultado de um processo criativo), acabas com algo estruturalmente correto mas visualmente indistinto. Otimizado para montagem. É o que acontece com a maioria das interfaces geradas por vibe coding: rápidas de construir, consistentes, completamente substituíveis. Funcionam para entregar. Não funcionam se queres uma linguagem visual que seja tua.

​

Há uma distinção aqui que vale a pena fazer explícita. O design system é uma destilação. Uma descoberta comprimida. Os componentes que extrais dele são o resultado de ter desenhado a página inteira, ter pensado na tipografia em contexto, ter experimentado como cada elemento comunica no conjunto. Quando saltas diretamente para a montagem, perdes o pensamento que deu origem às peças.

​

O processo criativo não é overhead. É confuso, não-linear, e impossível de automatizar. E é exatamente essa confusão que torna a destilação que alimentamos à máquina relevante.

​

Isto não é um argumento contra eficiência. É um argumento a favor de investir naquilo que torna a eficiência útil. Um sistema rápido a produzir output descartável custa mais a longo prazo do que o tempo que pensas estar a poupar.

​

Gosto é o que sobra quando produzir custa zero

​

Paul Graham escreveu em 2002 um ensaio sobre gosto que se tornou uma referência para programadores e designers. O argumento central é que gosto não é subjetivo. É uma competência que se desenvolve com prática, exposição e auto-crítica. E que design sem gosto não tem como melhorar, porque não há critério para distinguir o bom do mau.

​

Em 2026, este argumento é mais relevante do que nunca. Se a Inteligência Artificial consegue produzir uma interface funcional em minutos, o que separa uma interface funcional de uma interface boa? A resposta está no que a máquina ainda não consegue fazer: as decisões de craft que vão além do pixel.

​

Micro-interações que comunicam estado sem precisar de texto. O peso específico de uma sombra. O ritmo de uma escala tipográfica. A sensação de espaço numa composição. Estas são decisões que requerem exposição a centenas de interfaces, análise consciente do que funciona e porquê, e uma biblioteca mental de padrões, erros e trade-offs que nenhum modelo de linguagem consegue replicar (ainda, esperemos nós).

​

Há quem argumente que a Inteligência Artificial vai eventualmente dominar tudo isto. Pode ser. Mas hoje, e no futuro próximo, o gosto é o fator que transforma algo funcional em algo intencional. E essa diferença é o que define se um produto tem identidade ou é apenas mais uma montagem de componentes Tailwind.

​

Se queres investir exatamente nesta competência, o curso Craft Design: Para Além dos Pixels na TheStarter é dedicado a isso mesmo: desenvolver sensibilidade visual, atenção ao detalhe e capacidade de elevação de interfaces. Inscreve-te.

​

O que muda na prática para Product Designers e Product Managers

​

A teoria é interessante, mas a pergunta que importa é: o que fazes diferente na segunda-feira?

​

Investe mais tempo em Discovery, menos na produção. Se a Inteligência Artificial reduz radicalmente o custo de construir, o que se torna mais raro e mais difícil de replicar é saber o que construir. Enquadrar o problema certo, escolher a direção certa, definir critérios de sucesso claros. Um Product Designer que sabe fazer isto é mais difícil de substituir do que um que executa mockups rapidamente. Para Product Managers, a implicação é semelhante: a capacidade de definir o "porquê" e o "para quem" torna-se o gargalo, não a velocidade de entrega¹.

​

Aprende a avaliar output, não apenas a produzi-lo. Se o agente produz a primeira versão de uma interface, o teu trabalho é saber se essa versão é boa. Isso requer vocabulário visual, experiência com padrões de interação, e capacidade de articular o que está errado e porquê. Não basta dizer "não gosto". Precisas de saber se a hierarquia está correta, se os affordances são claros, se a interface comunica o estado certo no momento certo.

​

Trata o teu design system como infraestrutura para agentes. Tokens semânticos, estados completos, nomenclatura consistente entre Figma e código, descrições em cada componente. Não porque é bonito, mas porque sem isto, o agente adivinha. E quando um agente adivinha à escala, o custo de corrigir é maior do que o tempo de ter feito bem desde o início.

​

Não tenhas medo de tocar em código. A fronteira entre Design e engenharia está a esbater-se. Não precisas de ser engenheiro. Mas precisas de perceber como o teu stack funciona, o que é um context window, como os ficheiros estão estruturados, e o que acontece entre o componente no Figma e o componente em produção. Ferramentas como o Cursor, o Claude Code e o Vibe Coding estão a tornar isto acessível. A barreira já não é técnica. É de conforto.

​

Desenvolve opinião sobre qualidade. Num mundo onde toda a gente consegue gerar interfaces, a diferenciação está em quem consegue distinguir o aceitável do excelente. Isso constrói-se com exposição: analisa produtos que funcionam bem, reconstrói interfaces que admiras, compara decisões e percebe os trade-offs. A Inteligência Artificial gera com base em padrões e probabilidades. Não sabe se o resultado é coerente com a direção do produto. Esse julgamento continua a ser teu.

​

Aponta com cuidado

​

O agente monta. Não questiona.

​

Não pergunta se aquele componente devia existir, se a sombra é demasiado pesada, ou se o espaço entre elementos comunica calma ou ansiedade. Recebe instruções e constrói, fielmente e depressa.

​

Isso não é uma limitação. É a condição do acordo. E é um bom acordo, se quem aponta tiver realmente pensado.

​

O risco não é que a Inteligência Artificial substitua Product Designers. O risco é mais subtil: que a gravidade da montagem eficiente substitua gradualmente as condições que tornam a montagem interessante. Que nos tornemos muito bons a nomear coisas eficientemente e acabemos com interfaces que ninguém reconhece como suas.

​

O trabalho do Product Designer sempre foi manter o todo na cabeça antes de qualquer peça existir. Isso não mudou. O que mudou é que as consequências são maiores. A máquina é rápida. Vai exatamente para onde a apontas.

​

Aponta com cuidado.

​

Referências

​

¹ Melissa Perri, Escaping the Build Trap: How Effective Product Management Creates Real Value, O'Reilly Media, 2018.

​

² John Maeda, "Design in Tech Report 2026: From UX to AX", apresentado no SXSW, Março 2026. designintech.report

​

³ Paul Graham, "Taste for Makers", Fevereiro 2002. paulgraham.com/taste.html

​

⁴ Anthropic, "Demystifying evals for AI agents", Janeiro 2026. anthropic.com/engineering/demystifying-evals-for-ai-agents

​

⁵ Figma, "Design Systems And AI: Why MCP Servers Are The Unlock", Outubro 2025. figma.com/blog/design-systems-ai-mcp