Talvez a gente já esteja um pouco cansado de ouvir sobre como a inteligência artificial vai mudar os processos de design aqui e ali.

E vamos combinar que, por um bom tempo, isso causou (e ainda causa) um certo medo na gente, né?

Então quer dizer que tudo o que aprendi até hoje não vale mais nada? Vou ter que mudar completamente minha forma de trabalhar? Preciso aprender a criar prompts, dominar dez ferramentas novas e descobrir como usar as novas funcionalidades de IA que o Figma lançou até o final da semana, senão vou ser substituída?

Com o tempo, fomos acalmando os ânimos. Saímos do “a IA vai me substituir” para o “isso foi a IA que fez? Eu faço muito melhor!”.

E, no meio desses dois extremos, talvez tenhamos percebido que não precisava daquele pânico todo. Mas também não precisamos ir para o outro lado e assumir uma postura anti-IA.

Na verdade, quanto mais incorporo essas ferramentas ao meu trabalho, mais percebo que os desafios que elas trazem para nós, designers, são muito mais empolgantes do que assustadores.

Afinal, toda profissão exige que a gente se reinvente de tempos em tempos. Repensar processos, aprender novas habilidades, encontrar maneiras de trabalhar com mais agilidade, qualidade e eficiência sempre fez parte da nossa evolução profissional.

A chegada da IA não muda esse fato. O que muda é a maneira como vamos fazer isso.

Mas, para não ficar só no campo das ideias, quero trazer um exemplo prático: o handoff.

Antes, uma pequena história

Sou técnica em Desenvolvimento de Sistemas e passei boa parte da minha graduação estudando Computação.

Quando comecei a trabalhar como designer, confesso que às vezes me lamentava por não ter escolhido um curso de Design desde o início. Especialmente quando escutava coisas como: “mas você é designer e estuda computação?”

Mesmo assim, sempre tentei fazer do limão uma limonada.

Busquei aproveitar o que sabia sobre desenvolvimento no meu dia a dia como designer. Entender melhor as limitações técnicas, conversar com desenvolvedores, pensar em como os componentes seriam implementados e não apenas em como apareceriam nas telas.

Com o tempo, descobri que aquilo que eu enxergava como uma fraqueza era, na verdade, uma habilidade muito valiosa.

E hoje acredito que ter uma base de conhecimento em desenvolvimento está deixando de ser apenas um diferencial para se tornar uma competência cada vez mais necessária para designers de produtos digitais.

Não estou dizendo que todo designer precisa virar desenvolvedor. Mas entender como aquilo que projetamos se transforma em um produto funcional nos permite tomar decisões melhores e, principalmente, diminuir as barreiras entre design e desenvolvimento.

E isso fica ainda mais evidente quando falamos de handoff.

Durante muito tempo, tratamos o handoff como uma espécie de passagem de bastão.

Como se ainda estivéssemos presos à lógica fordista de produção: o time de design termina sua parte, entrega as telas e agora é a vez do desenvolvimento.

Mas handoff nunca foi apenas sobre entregar telas no Figma.

É sobre compartilhar contexto, decisões, comportamentos, critérios e tudo aquilo que permite transformar uma solução projetada em uma experiência funcional.

Na prática, é claro que nem sempre conseguimos documentar absolutamente tudo. E muitas vezes isso funciona porque existe uma relação próxima entre designers e desenvolvedores.

Se um componente não está suficientemente explicado, a gente conversa. Se um comportamento gera dúvida, marca uma call. Se algo não faz sentido na implementação, sentamos juntos e encontramos uma solução.

Mas e quando quem recebe essas especificações é um agente de IA?

Não dá para simplesmente chamar o agente para aquela conversa informal em que explicamos o que queríamos dizer com um componente. Podemos até interagir com ele, fornecer mais contexto e corrigir suas interpretações, mas isso também exige que saibamos expressar nossas intenções com clareza.

E aqui está uma das mudanças que mais me interessam.

Quanto mais autonomia damos à IA para construir interfaces, mais importante se torna a qualidade das informações que oferecemos a ela.

Uma tela visualmente bem resolvida não explica, sozinha, como um componente deve se comportar em diferentes estados, quais regras de negócio precisam ser respeitadas, como lidar com erros ou quais decisões de acessibilidade devem orientar a implementação.

Tudo isso precisa estar claro.

E não significa necessariamente produzir documentos enormes ou passar mais tempo escrevendo especificações. Significa construir uma documentação mais intencional, organizada, atualizada e útil para quem (ou para o que) vai utilizá-la.

Isso também muda a maneira como olhamos para nossos arquivos no Figma. A organização dos componentes, a consistência das nomenclaturas, o uso de variantes e a conexão com o design system deixam de ser apenas boas práticas de organização. Passam a ajudar diretamente na interpretação e implementação das interfaces.

Quando um agente consegue relacionar um componente do Figma a um componente real da aplicação, por exemplo, diminuímos o espaço para interpretações equivocadas e retrabalho.

Mas nada disso elimina a importância da colaboração entre pessoas.

Pelo contrário. Para que uma IA consiga trabalhar com boas especificações, designers e desenvolvedores precisam estar ainda mais alinhados sobre como os componentes funcionam, quais padrões devem ser seguidos e como as decisões são registradas.

No fim, a IA acaba evidenciando algo que já deveríamos valorizar, design e desenvolvimento precisam falar a mesma língua.

E onde fica o olhar crítico do designer?

Tem outra questão que considero importante nessa história.

Tenho usado IA em diferentes etapas do meu processo, desde pesquisas até a construção de wireframes para validar fluxos. E uma das maiores vantagens que percebo é conseguir reduzir o tempo gasto em algumas atividades operacionais e direcionar minha atenção para outras decisões.

Mas existe uma armadilha nisso.

É muito fácil perder o olhar crítico quando damos de cara com resultados que já parecem prontos.

A ferramenta apresenta cinco alternativas, todas visualmente interessantes, e de repente estamos tentando escolher a melhor entre elas, em vez de nos perguntar se alguma delas realmente resolve o problema.

Às vezes, a melhor decisão é não escolher nenhuma. É questionar, mudar a direção, experimentar outra abordagem.

E acho que esse é um cuidado que precisamos ter conforme essas ferramentas se tornam mais presentes no nosso trabalho.

Aprender a escrever bons prompts é importante. Entender novas ferramentas também. Mas nada disso deveria nos fazer abrir mão do repertório, da sensibilidade e da capacidade de questionar o que desenvolvemos ao longo da nossa trajetória.

A IA pode ajudar a materializar uma ideia muito mais rápido, mas ainda precisamos saber qual ideia vale a pena materializar e por quê.

Talvez não seja sobre começar do zero

Quando penso em tudo isso, volto àquela ansiedade do início: será que precisamos reaprender nossa profissão inteira?

Cada vez mais, acredito que não.

Talvez o desafio seja olhar com mais atenção para habilidades que já faziam parte do nosso trabalho, mas que agora ganham uma importância diferente.

Saber comunicar decisões. Entender o contexto técnico. Documentar com clareza. Colaborar com outras áreas. Ter repertório para avaliar soluções e segurança para questionar resultados, mesmo quando parecem prontos.

Não são habilidades que surgiram com a IA.

O que mudou foi o quanto precisamos exercitá-las e a maneira como podemos colocá-las em prática.

E, olhando para minha própria trajetória, acho curioso perceber que aquele conhecimento em desenvolvimento que um dia me fez questionar se estava seguindo o caminho certo hoje me ajuda a navegar por essas transformações.

Talvez seja justamente isso que mais me empolga, perceber que não precisamos abandonar tudo o que construímos até aqui para acompanhar as mudanças.

Precisamos aprender a usar o que já sabemos de novas maneiras.