IA gera a interface certa, mas não sabe qual momento merece confete

O confete que não sabe o que está comemorando

Imagine pedir a uma IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → uma tela de sucesso: checkmark, frase simpática, confete. Os componentes batem com o design system↳Design system5 conteúdosComo desenvolvemos o novo Design System do AsaasProduto & UX · jul 2024UX e Código: Por que designers que conhecem programação têm uma vantagem estratégicaProduto & UX · abr 2025A importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Ver tudo em Produto & UX →, o espaçamento está certo, a animação é bonita.

Agora troque o contexto. Numa tela, alguém acabou de lançar um negócio que levava meses tentando tirar do papel. Na outra, um administrador terminou de atualizar o quadragésimo sétimo registro da manhã.

O componente é idêntico. A experiência deveria ser diferente. Essa é a observação que abre o ensaio de Dolphia Arnstein no UX Collective, publicado em 4 de novembro de 2026, e é o ponto de partida que eu quero defender aqui: nada no confete explica qual momento merece ser celebrado. Essa decisão depende de quem fez o quê, com que frequência, e se a pessoa quer que o produto faça ocasião daquilo.

Consistência deixou de ser garantia de qualidade

A documentação do agente do Figma explica como componentes, guidelines e contexto de tarefa ajudam a IA a gerar telas fiéis ao sistema de uma equipe. Isso é progresso real: reduz retrabalho e evita que cada tela reinvente decisões já tomadas.

Mas uma renderização fiel ao sistema ainda pode ser uma resposta emocionalmente errada. Uma mensagem de sucesso pode estar tecnicamente correta e soar condescendente. Uma ilustração pode bater com a marca e ocupar o espaço que a pessoa precisava para trabalhar.

Esse tipo de falha não aparece inspecionando o componente isolado. Ela só existe na relação entre o componente e quem está na tela naquele instante, o que significa que nenhuma checklist de design system vai capturá-la sozinha.

Prazer tem categorias, e a IA ainda não distingue nenhuma

Don Norman já separava design emocional em três camadas: a aparência, a experiência de uso e o significado que a pessoa atribui ao objeto. Therese Fessenden, do Nielsen Norman Group, vai além e distingue delight de superfície e delight profundo: um detalhe divertido cria um momento de prazer; um fluxo bem pensado produz uma satisfação mais discreta que dura o percurso inteiro da tarefa.

Uma categoria não invalida a outra. Um produto pode ser confiável e também ter uma ilustração peculiar só porque alguém se importou em torná-lo agradável, sem precisar justificar isso com três segundos de economia de tempo.

O problema é que "delight" virou um rótulo genérico demais para aplicar antes de saber qual das três coisas aconteceu de fato: a cor deixou a tela mais convidativa sem exigir nenhum passo extra, a celebração exigiu atenção, a piada exigiu repertório cultural, a transição fez esperar.

Duolingo mostra a ilustração que sobrava

O exemplo mais prático do texto vem do próprio relato da equipe de design do Duolingo sobre o redesenho das abas principais do app. Ao testar cabeçalhos ilustrados em todas as abas, a equipe encontrou uma tensão concreta: a uniformidade visual ficava boa, mas algumas ilustrações ocupavam espaço sem comunicar nada relevante.

A solução não foi abandonar a expressividade, foi dosá-la: tamanhos de cabeçalho diferentes para propósitos diferentes, com os títulos mantidos em posições consistentes. É uma lição mais útil do que "deixe toda tela divertida", porque mostra que até uma marca expressiva precisa perguntar onde a ilustração realmente ganha o próprio espaço.

Isso importa duplamente quando aquela tela vira referência para uma IA reproduzir. Se a tela de exemplo tem uma ilustração grande, a próxima herda isso como regra, como possibilidade ou como resposta a uma situação específica? Uma ferramenta reproduz a resposta visível; o motivo por trás dela não viaja junto.

Tom muda, voz não: a lição do Mailchimp

O guia de voz e tom do Mailchimp separa duas coisas que o prompt para IA costuma misturar: a voz, que é fixa, e o tom, que responde à circunstância do leitor. O guia dá espaço para humor, mas coloca clareza na frente, e pede para quem escreve considerar se a pessoa acabou de concluir uma campanha ou está confusa buscando ajuda.

Isso tem implicação direta em como se instrui uma IA. "Deixe amigável e divertido" não resolve nada: amigável para quem, divertido em que ponto, o que acabou de acontecer?

Uma instrução mais útil descreve a situação: o trabalho da pessoa está salvo, ela precisa entender por que a ação falhou, evite humor, deixe o caminho de recuperação óbvio. Ainda cabe boa escrita dentro dessas restrições, mas as restrições é que definem o que a escrita deve à pessoa.

Expressivo pode esclarecer, ou pode atrapalhar

Vale desmontar a ideia de que design expressivo e design usável estão sempre em lados opostos. A pesquisa do Google sobre o Material 3 Expressive testou uma interface de e-mail em que o botão de enviar ficou maior, mais próximo do teclado e mais destacado: participantes o localizaram mais rápido. O ganho não veio da decoração, veio da mudança de hierarquia.

O mesmo relatório traz o contraponto: uma lista de reprodução trocou linhas familiares por um arranjo disperso de capas de álbum. Participantes acharam visualmente empolgante, e a usabilidade piorou.

As duas descobertas pertencem a desenhos testados pelo próprio Google, não a uma regra universal de estilo. Juntas, mostram que a pergunta certa nunca é "isso é expressivo?", é "o que continua legível depois que a expressividade entra?".

Quando o mesmo detalhe vira ruído

A Asana introduziu, em 2016, personagens animados que aparecem após concluir uma tarefa, com a opção de desativar nas configurações. Dois anos depois, uma discussão no fórum da comunidade mostra um cliente pedindo para desligar unicórnios e monstros porque os achava intrusivos.

Esse post isolado não prova que a maioria odeia a celebração. Prova algo mais incômodo: o mesmo detalhe pode ser bem-vindo para uma pessoa e indesejado para outra, e dar controle sobre isso faz parte de desenhar a experiência, não é um extra de acessibilidade.

Para movimento, a régua é ainda mais objetiva: o critério de nível AAA do WCAG sobre animação disparada por interação existe porque movimento não essencial pode causar sintomas vestibulares reais em parte do público. Toda experiência expressiva precisa de uma versão com movimento reduzido que preserve feedback e hierarquia.

O contra-argumento: isso é over-engineering para um checkmark

A objeção óbvia é que nem toda equipe tem orçamento de pesquisa para testar o tom de um toast de confirmação em três cenários diferentes. É verdade, e seria desonesto fingir que todo time tem a maturidade de pesquisa do Google ou a escala da Asana para justificar esse nível de cuidado.

Mas a alternativa não é ignorar o problema, é reduzir o escopo dele. Nem todo momento pede pesquisa qualitativa; pede uma pergunta simples antes de aprovar o componente generativo: esta é uma ação repetida ou um marco? A pessoa está apressada ou explorando? Documentar essa resposta junto ao componente já evita boa parte do erro, mesmo sem laboratório de usabilidade.

O que eu documentaria antes de liberar pro design system

A proposta mais concreta do texto original é uma regra de trabalho, não uma regra universal: reconhecimento mais completo para a primeira conquista significativa; feedback breve para ações repetidas e rotineiras; linguagem direta e contida para desfechos sensíveis. Ela não vai servir para todo produto do jeito que está, mas dá algo concreto para questionar.

Na prática, isso significa que a documentação de um componente expressivo precisa registrar três coisas além do visual: a circunstância que ele serve, quando reduzir a intensidade e um caso em que ele não deveria ser usado. Sem isso, tanto um designer júnior quanto uma IA vão aplicar o padrão onde for mais fácil copiar, não onde ele faz sentido.

O diferencial de quem desenha produto não está mais em desenhar o botão, a IA já faz isso bem o suficiente. Está em decidir, caso a caso, se aquele momento pede celebração, discrição ou simplesmente que o produto saia do caminho.

Fonte: UX Collective