"O processo de design está morto." Essa frase circulou muito nos últimos meses. A reação foi previsível: metade do LinkedIn concordando efusivamente, a outra metade em pânico existencial.

Eu entendo de onde vem. O processo rígido e sequencial — discovery, wireframe, mockup, handoff, iteração — de fato não funciona mais quando a velocidade de implementação mudou de ordem de grandeza. Quando um engenheiro consegue prototipar em código mais rápido do que um designer consegue montar um mockup no Figma, o fluxo tradicional vira gargalo. Até aqui, concordo.

Mas declarar que o processo está morto é uma outra coisa. Porque pressupõe que ele existia de forma robusta. E na maioria dos times em que trabalhei, o processo de design nunca foi aquele modelo de livro didático. Era uma negociação constante, uma adaptação ao contexto, e muitas vezes uma luta para existir. Dizer que está morto é um luxo de quem trabalhava em empresas onde ele funcionava — e uma ignorância sobre os contextos onde ele nunca chegou a existir direito.

O que tenho visto na prática é mais bagunçado e mais interessante do que "o processo morreu." O que tenho visto é gente tentando usar IA para fazer o trabalho que não é delas — e descobrindo, depois, que o resultado não era bom.

Desenvolvedores e profissionais de engenharia de software usando IA generativa para criar interfaces visuais, por exemplo. O resultado é frequentemente o que descrevi no primeiro texto desta série: a mesma crise estética do WordArt, só que com ferramentas mais sofisticadas. Interfaces genéricas, não ancoradas em pesquisa com usuários, sem compreensão mais robusta do problema. Tudo com aquela cara de template que a IA produz quando ninguém orienta o output.

E o pior não é o resultado visual. O pior é o ciclo que se cria: alguém usa IA para gerar uma interface, acha que chegou no resultado final, avança para implementação — e semanas depois descobre que não era bom. Que precisava reescrever. Que o que parecia pronto estava construído em cima de premissas que ninguém validou. A IA não criou o problema da falta de pesquisa. Mas ela acelerou o ciclo de errar sem perceber.

Eu não sou profeta do processo. Não acho que todo time precisa seguir um fluxo rígido de discovery → design → dev. Mas quando são times que não falam a mesma linguagem e precisam trabalhar para um objetivo em comum, o processo é necessário. Não como ritual burocrático, mas como estrutura mínima para que cada pessoa entenda qual é o papel da sua contribuição no sistema todo. Sem isso, a IA vira uma ferramenta de aceleração sem direção — e aceleração sem direção não é eficiência, é desperdício mais rápido.

O que tenho feito como líder de design é tentar usar a IA como ponte entre os dois mundos, não como substituto de nenhum dos dois. Na prática, isso significa algumas coisas.

Já descrevi em textos anteriores desta série o que tenho feito na prática: guidelines de uso de IA, human-in-the-loop em artefatos-chave, gatekeeping antes de abrir código. Não vou repetir. O que quero destacar aqui é o princípio por trás: o processo como bússola para o uso da IA. Times que já passaram por ciclos suficientes de desenvolvimento de software e design sabem onde as coisas dão errado. Esse conhecimento acumulado é exatamente o que deveria estar curando como a IA é usada — não sendo descartado por ela. O objetivo é valorizar as pessoas, aprofundar a compreensão dos problemas e superar barreiras entre design e engenharia que existem há décadas.

O processo de design não está morto. Em muitos lugares, ele nunca nasceu. O que precisamos não é declarar óbito, é construir processos que façam sentido para times reais — times onde devs e designers falam linguagens diferentes mas precisam construir a mesma coisa. A IA pode ser a ponte. Mas pontes precisam de fundação dos dois lados.

"The design process is dead." This line has been making the rounds over the past few months. The reaction was predictable: half of LinkedIn agreeing enthusiastically, the other half in existential panic.

I understand where it comes from. The rigid, sequential process — discovery, wireframe, mockup, handoff, iteration — genuinely doesn't work when implementation speed has changed by an order of magnitude. When an engineer can prototype in code faster than a designer can assemble a mockup in Figma, the traditional flow becomes a bottleneck. I agree with that much.

But declaring that the process is dead is a different thing. Because it assumes the process existed in a robust form. And in most teams I've worked with, the design process was never that textbook model. It was a constant negotiation, an adaptation to context, and often a fight to exist at all. Saying it's dead is a luxury of those who worked at companies where it functioned — and an ignorance of the contexts where it never properly existed.

What I've been seeing in practice is messier and more interesting than "the process died." What I've been seeing is people trying to use AI to do work that isn't theirs — and discovering, afterwards, that the result wasn't good.

Developers and software engineering professionals using generative AI to create visual interfaces, for example. The result is frequently what I described in the first post in this series: the same aesthetic crisis as WordArt, only with more sophisticated tools. Generic interfaces, not grounded in user research, without a robust understanding of the problem. Everything with that template look the AI produces when nobody guides the output.

And the worst part isn't the visual result. The worst part is the cycle it creates: someone uses AI to generate an interface, thinks they've reached the final result, moves forward to implementation — and weeks later discovers it wasn't good. That they needed to rewrite. That what looked ready was built on assumptions nobody validated. AI didn't create the problem of missing research. But it accelerated the cycle of making mistakes without realising it.

I'm not a process prophet. I don't think every team needs to follow a rigid discovery → design → dev flow. But when teams don't speak the same language and need to work toward a common objective, process is necessary. Not as bureaucratic ritual, but as the minimum structure for each person to understand the role of their contribution in the whole system. Without that, AI becomes an acceleration tool without direction — and acceleration without direction isn't efficiency, it's faster waste.

What I've been doing as a design lead is trying to use AI as a bridge between the two worlds, not as a substitute for either. In practice, this means a few things.

I've already described in previous posts in this series what I've been doing in practice: AI usage guidelines, human-in-the-loop on key artefacts, gatekeeping before opening code. I won't repeat it here. What I want to highlight is the principle behind it: process as a compass for AI use. Teams that have been through enough software and design cycles know where things go wrong. That accumulated knowledge is exactly what should be curating how AI gets used — not being discarded by it. The goal is to value people, understand problems better, and overcome barriers between design and engineering that have existed for decades.

The design process isn't dead. In many places, it was never born. What we need isn't to declare it dead — it's to build processes that make sense for real teams. Teams where devs and designers speak different languages but need to build the same thing. AI can be the bridge. But bridges need foundations on both sides.