IA, Design e Código: o que mostrámos no WordPress Meetup Faro

A 15 de julho estive no WordPress Meetup Faro, no UALG TEC Campus, com o Miguel Pires (AKQA), para uma conversa prática sobre como adotámos a IA no nosso processo diário. Nada de hype nem de promessas milagrosas: exemplos reais, do research ao deploy, e o que ainda não funciona.

A frase da noite

Há um ano, abrir um terminal era a última coisa que eu faria. Hoje o terminal trabalha comigo, enquanto continuo a fazer o meu trabalho de designer de UI/UX e mentor. Tudo o que mostrámos serviu uma ideia:

Um modelo mental: skills e MCP

Imagina que contratas um designer brilhante que não sabe nada da tua empresa. No primeiro dia dás-lhe duas coisas: conhecimento (as tuas regras, o teu critério) e capacidades (acesso às ferramentas onde o trabalho acontece). Com a IA é igual, e as duas coisas têm nome:

• Skills, o cérebro. Conhecimento que a IA carrega para o trabalho: heurísticas de auditoria, regras do grid, atomic design, boas práticas de Figma (autolayout, variables, components). Escritas uma vez, usadas sempre.
• MCP, as mãos. Acesso às ferramentas reais: o Figma, o browser, o terminal. Sem mãos, a IA só fala sobre o trabalho. Com mãos, faz o trabalho.

O meu processo diário, com a IA em cada etapa

1. Research. Sinais de mercado, concorrência, queixas reais de utilizadores. Recolho sinais, não inspiração, e chego ao Figma a saber onde a concorrência falha.
2. Pensar o produto. Problem statement, jobs to be done, user flows, MVP e edge cases, tudo em texto antes de desenhar um único ecrã. A IA não substitui o pensamento: obriga-te a pensar antes, porque tens de escrever o problema com clareza.
3. Design. Wireframes diretamente no Figma via MCP, com autolayout, variables e components desde o início. O ficheiro nasce organizado e pronto a escalar.
4. Audit. Ensinei a IA a auditar como eu faria, mas com mais olhos, mais rápido e sem fadiga: Norman, Nielsen, grid e acessibilidade numa só passagem. O critério continua a ser meu. Escrevi-o uma vez e aplica-se a todos os ecrãs.
5. Prototype. Do canvas a código que corre no browser, testável no próprio dia. O utilizador testa o produto, não a maquete.
6. Document e handoff. O handoff deixa de ser só anotações e diagramas e passa a ser documentação viva, que sincroniza com o Figma e com o código. Testo mais cedo, os gaps são menores e a conversa com o developer começa duas semanas antes.

A IA não desenha por mim. Ajuda-me a pensar e a executar melhor em cada etapa.

E depois do deploy?

A segunda parte foi do Miguel: um design system começa a desatualizar-se no dia em que é publicado, com documentação atrasada, componentes órfãos e tokens que ninguém sabe de onde vieram. Mantê-lo à mão não escala. Com IA, o design system pode documentar-se e auditar-se: comparar o Figma com o código, detetar desvios e avisar quando algo sai do padrão. E com tokens, uma mudança na base chega a várias marcas de uma vez.

Honestidade

Tudo o que a IA gera precisa de refinamento, e o refinamento somos nós. É por isso que ainda não nos substitui.

Não somos só nós

Designers doutros lados do mundo estão a chegar à mesma arquitetura, sem contacto connosco: skills como cérebro, MCP como mãos. Uma boa leitura para começar é A Designer’s Guide to Claude Code, da Katherine Yeh, no Medium.

A sala escolheu

No fim, a sala escolheu o que queria ver a acontecer: um UX audit ao vivo, wireframes desenhados pela IA no Figma, um design system em HTML ou Storybook e um protótipo a funcionar a partir do canvas.

Obrigado à Comunidade Portuguesa de WordPress, à Algarve Evolution, à AlgarveSTP Association e ao UALG TEC Campus pelo convite e pela organização, e a todos os que apareceram.

O anúncio do evento está no LinkedIn.