Do determinismo ao probabilismo no design

Quase tudo o que aprendi em design assume determinismo. Se o utilizador carrega no botão A, acontece X. Sempre. Os botões mostram-se, os formulários validam regras conhecidas, os ecrãs são desenháveis em Figma porque o que vão mostrar é previsível.

A IA quebra isto. O mesmo prompt pode dar respostas diferentes na mesma conversa. O mesmo agente pode escolher uma tool hoje e outra amanhã para a mesma tarefa. A nossa ferramenta favorita, o ecrã estático, deixa de descrever o que vai acontecer.

Este shift está no centro de quase tudo o que muda no trabalho de Product Design quando entra IA. Vale a pena ver o que isto pede de novo, e o que mantém.

Como era no determinismo

No mundo determinístico, o método é claro:

1. Identificar o problema do utilizador.
2. Mapear flows.
3. Desenhar mockups com texto exato e estados conhecidos.
4. Validar em prototipo.
5. Entregar specs com regras claras: input X gera output Y.

Tudo o que entra no ecrã, entrou intencional. Erros, estados vazios, validações: tudo enumerável. O Figma serve bem, porque o trabalho é coreografar o previsível.

Os métodos de research que usamos, do JTBD ao usability testing, assumem este enquadramento. Testas a interface contra a tarefa esperada. Se o botão está visível e legível, o teste passa.

O que muda com IA

Três coisas quebram em simultâneo.

Primeiro: o output deixa de ser fixo. Um agente que recomenda restaurantes pode hoje mostrar 5 opções, amanhã 8, na próxima semana fazer uma pergunta antes de mostrar. O texto que aparece também muda. Já não estás a desenhar uma resposta, estás a desenhar um espaço de respostas possíveis.

Segundo: o input deixa de ser estruturado. Antes, eram cliques e formulários. Agora é uma frase escrita à pressa, possivelmente com erros, ironia, ambiguidade. O que o utilizador digita raramente é o que ele queria dizer.

Terceiro: a interação deixa de ser turn-based no sentido tradicional. O agente pode interromper, fazer follow-up, agir em segundo plano, voltar com novidade. O paradigma do “input → output → input” desfaz-se.

Desenhar para o probabilismo

O que substitui as mockups fixas? Quatro práticas que vejo a aparecer.

1. Desenhar exemplos, não respostas finais. Em vez de definir o texto exato que vai aparecer, definimos 3 a 5 exemplos do que aceitamos como bom output. Esses exemplos são depois transferidos para o prompt como few-shot examples. O designer escreve aquilo que a IA deve replicar, não exatamente, mas no espírito.

2. Reverse engineering. Em vez de imaginar o prompt do zero, mockamos a mensagem ideal e construímos o prompt que a produz. Aprofunda-se em O prompt como trabalho de design.

3. Boundaries em vez de scripts. O que nunca pode acontecer é mais útil de definir do que o que deve acontecer. O exemplo clássico: numa descoberta de restaurantes com IA, a flexibilização de filtros para mostrar mais resultados pode acontecer (raio de 1 km vira 2 km). Mas filtros de alergia, como sem glúten ou sem amendoim, nunca podem ser flexibilizados. A boundary é a regra, não o script.

4. Service blueprints sobre wireframes. O foco move-se de “o que está no ecrã” para “como é que os agentes, tools, dados e o utilizador se conectam”. O entregável vai-se parecendo cada vez mais com um diagrama de fluxo de agentes, com tools mapeadas, do que com um Figma file.

O que continua a aplicar-se

Nem tudo se descarta. Heurísticas como visibility of system status, user control and freedom, help and documentation continuam a funcionar. Aplicam-se de forma diferente, mas o princípio mantém-se: o utilizador precisa de saber o que está a acontecer, precisa de poder pausar, precisa de ajuda quando se perde.

O que muda é a sofisticação com que tens de aplicá-las. A visibilidade do estado, num agente que está a executar 12 passos em segundo plano, é um problema mais complexo do que num formulário com um spinner.

A mudança de mindset que custa mais

A coisa que mais custa, na minha experiência, é deixar de confundir output específico com output desejado.

Designers passámos anos a defender o texto certo, o microcopy preciso, a regra de validação exacta. É o nosso trabalho. Quando entra IA, esse instinto traduz-se em pedir à data science para garantir que o output diga exatamente aquela frase. E isso não funciona em probabilismo.

A versão saudável do mesmo instinto é dizer: “queremos que o output cumpra estas três propriedades: tom amigável, não menciona preço, oferece sempre uma ação seguinte”. Estas três propriedades são especificáveis, testáveis, e podem viver dentro de um sistema probabilístico. A frase exata não.

Onde isto te apanha

Três sintomas de que ainda estás a desenhar como se fosse determinístico:

• Tentas escrever o copy final dentro do mockup do chatbot.
• Pedes “o output deve ser sempre assim” em vez de “deve cumprir estas propriedades”.
• O teu QA passa por verificar se a IA disse a frase prevista, não se cumpriu o objetivo.

Se algum destes te soa familiar, é sinal de que o método ainda não acompanhou a tecnologia. O ponto positivo é que quase ninguém está completo neste shift. O que vale é começar.

Mais sobre o pano de fundo no guia Design for AI. Sobre como colaborar com data science quando estás a escrever prompts, ver O prompt como trabalho de design.