A diferença entre executar um prompt e trabalhar como Design Engineer

O método começa antes do primeiro prompt

O primeiro erro de muita gente ao usar IA é achar que o trabalho começa quando se abre o chat. Na prática, começa antes.

Neste projeto, tudo começou em uma reunião com o time responsável pelo sistema. Eles apresentaram o contexto, as tecnologias envolvidas, os termos técnicos, o fluxo principal do usuário, o que esperavam valorizar e também o que ainda estava em aberto.

Nem sempre o briefing vem com todas as respostas. Muitas vezes ele vem com boas intenções, algumas certezas técnicas e várias zonas de dúvida: como explicar melhor o valor do sistema, como deixar a experiência mais clara, como transformar uma funcionalidade core em algo que pareça tão diferenciado quanto realmente é.

Durante a conversa, fui perguntando o básico, que às vezes, não é básico: existe design system? já existe alguma direção visual mínima? o que vocês esperam como entrega? estamos falando de Figma, protótipo navegável, código ou outra coisa? quais partes do fluxo precisam ficar mais claras? quais decisões de usabilidade ainda estão indefinidas?

A resposta apontava para algo relativamente contido: melhorar o Figma existente e organizar uma direção mais clara de interface e experiência. Inclusive, recebi um arquivo de Figma (Wireframe) como ponto de partida. Na prática, usei pouco esse arquivo.

A decisão foi focar menos na evolução direta das telas existentes e mais na estrutura da experiência: o fluxo, os estados, a narrativa do produto e a forma como a funcionalidade principal deveria ser percebida.

Depois da reunião, veio uma etapa decisiva: transformar entendimento solto em briefing estruturado.

Eu uso um roteiro próprio de perguntas para isso. Não é um formulário rígido. É mais como uma trilha de raciocínio. Vou lendo as perguntas, respondendo em voz alta e organizando o pensamento enquanto falo. Esse áudio vira texto com uma ferramenta local de voz para texto que desenvolvi, chamada flow-st8 (nada original).

A vantagem desse processo é que ele mantém a naturalidade da fala, mas não deixa o briefing virar improviso. Existe uma estrutura por trás: navegação, comportamento, estados, restrições, expectativas, riscos, dúvidas, critérios de validação.

O briefing estruturado em markdown ficou equivalente a um documento de 8 páginas.

Em paralelo, também montei um guia visual inicial: cores, fontes, referências visuais, tom da interface e alguns princípios para orientar a primeira execução. Isso é importante porque o primeiro prompt não foi apenas uma instrução jogada na IDE. Ele apontava para um conjunto de arquivos: briefing, guia visual e documentos iniciais. A primeira tarefa da IA não era "comece a codar". Era combinar esses insumos, demonstrar entendimento e transformar o material em um primeiro entregável estruturado: o frame.

Ou seja, o prompt inicial não nasce de uma frase digitada às pressas. Ele nasce de uma conversa, passa por um roteiro de perguntas, ganha uma camada visual e vira uma especificação em Markdown dentro do próprio projeto. Esse detalhe muda tudo. Porque IA não adivinha intenção. Ela executa a partir do contexto que recebe. Prompt vago costuma gerar resultado genérico. Briefing estruturado cria direção.

Do frame ao produto

Depois disso, o material foi condensado em um frame simples: qual problema estamos resolvendo; qual resultado precisa existir ao final. Sem esse enquadramento, qualquer execução parece avanço.

Com ele, cada decisão pode ser avaliada: isso aproxima ou afasta o produto do resultado esperado?

No projeto, o briefing inicial não foi direto para execução. Ele virou uma sequência comprimida de produto, design e desenvolvimento (front end).

Frame e shaping ficam mais próximos de produto, negócio e design estratégico. Breadboard e slicing já começam a encostar mais em decisões que uma equipe de desenvolvimento normalmente faria: como quebrar o trabalho, como validar fluxos, como transformar intenção em partes construíveis.

Frame — definiu o problema e o resultado esperado.

Shaping — transformou esse problema em escopo: o que entra, o que fica fora, quais decisões de experiência precisam ser tomadas e qual é a forma geral da solução.

Breadboard — detalhou as interações: quais lugares existem na aplicação, quais ações o usuário pode tomar, quais estados aparecem e como as partes se conectam.

Slicing — organizou a execução em entregáveis funcionais e demonstráveis ("o pedaço de bolo").

Mas a IA só ajuda a comprimir etapas. Ela não elimina a necessidade de pensar cada uma delas.

Para mim, esse é um dos pontos centrais do trabalho como Design Engineer: criar continuidade entre intenção de produto, desenho de experiência e materialização técnica (do frontend). Parte da lógica foi inspirada no Shape Up, metodologia criada por Ryan Singer na Basecamp. Não como aplicação pura, nem como ritual metodológico. Usei como referência para estruturar pensamento: sair do problema, moldar a solução, detalhar interação e organizar entregáveis funcionais.

O que saiu do outro lado

O que inicialmente parecia um entregável de referência visual virou uma SPA (Single Page Application) funcional, com fluxos navegáveis e estados simulados.

O produto entregue tinha: 5 fluxos completos de ponta a ponta — login, intake inicial, conversão, perfil e histórico; autenticação mock com persistência local; motor de simulação para representar o processo de conversão; estados de loading, erro e sucesso tratados em modais e overlays; design system próprio documentado no Storybook; três cenários de mock para validação; um painel de apoio para testes internos simulando entrada de dados, caminho feliz e fluxos de erros; animações e transições; readme completo para onboarding, ASCII header em cada página e componente, documentação downstream/upstream, happy path e error flows.

Ou seja: o time não recebeu apenas uma ideia de interface. Recebeu algo que podia ser rodado, testado, reaproveitado, discutido e usado como referência concreta para a próxima etapa técnica.

Para não transformar isso em promessa matemática, prefiro olhar como esforço equivalente: quanto uma esteira tradicional provavelmente envolveria para chegar em um artefato com escopo parecido.

O ponto não é "olha como foi rápido". O ponto é: foi rápido porque havia coerência entre as etapas. Cada artefato alimentou o próximo. Sem essa linha de continuidade, IA vira uma máquina de gerar retrabalho em alta velocidade. Com método, ela vira uma extensão real da capacidade de execução.

A primeira resposta quase sempre tem "cara de IA"

Existe uma parte desse processo que não aparece em prints bonitos nem em métricas de produtividade. A distância entre o primeiro resultado e o produto final. Essa distância é onde mora o trabalho.

O primeiro output da IA, mesmo com um bom prompt, costuma ser competente. Mas competência não é a mesma coisa que intenção. Ele funciona. Mas muitas vezes tem cara de IA. Visual correto, mas genérico. Texto correto, mas sem voz. Interação correta, mas sem personalidade — tudo com "cara de IA".

E é justamente aí que começa o trabalho de design. Não no sentido superficial de "deixar bonito". Mas no sentido mais importante: refinar intenção, percepção, hierarquia, ritmo, emoção e coerência.

No caso da home desse projeto, a mudança não foi apenas trocar componentes ou escolher uma composição mais bonita. A tela precisava deixar de parecer uma área preenchida por widgets e passar a comunicar um conceito. Precisava ter respiro, hierarquia, ritmo e uma direção mais clara para o que o produto queria transmitir.

Outro exemplo foi o uso de animação de text scramble em mensagens da interface. Não surgiu do nada. Veio de uma pesquisa sobre termos do domínio e da decisão de transformar esse vocabulário em uma camada de voz e personalidade para o produto. Enquanto processava, frases divertidas dentro do contexto eram apresentadas.

A IA executa isso bem quando é direcionada. Mas ela não acorda inspirada e decide que o produto precisa de personalidade.

O ciclo real de interação com IA é menos mágico e mais trabalhoso: gerar, avaliar, redirecionar, repetir.

Esse ciclo parece simples. E é. Mas simples não significa fácil. Porque avaliar exige repertório. Redirecionar exige clareza. Repetir exige critério para saber quando insistir, quando mudar e quando parar.

O papel dos fundamentos

Muita coisa que descrevi até aqui pode parecer básica. E, honestamente, é básica mesmo. Briefing bem feito. Perguntas certas. Clareza de problema. Entendimento de usuário. Hierarquia visual. Fluxo. Estado. Feedback. Handoff. Validação. Critério. Nada disso nasceu com IA. E talvez por isso mesmo seja tão importante agora.

Quanto mais a execução fica rápida, mais os fundamentos aparecem. Ou melhor: mais a falta deles aparece.

Quando uma IA gera uma interface em segundos, o diferencial deixa de ser conseguir produzir uma tela. Isso ficou barato. O diferencial passa a ser saber avaliar se aquela tela faz sentido. Ela resolve o problema? Ela explica bem o valor? Ela orienta o usuário? Ela comunica a sensação certa? Ela parece produto ou parece template? Ela respeita o contexto daquele momento, daquele domínio, daquela conversa, daquela empresa?

Fundamentos são o que permitem fazer essas perguntas. Senso crítico é o que permite não aceitar a primeira resposta só porque ela parece pronta.

No design, ainda existe uma camada mais difícil de automatizar: sentimento, percepção e contexto. Uma interface não transmite apenas função. Ela transmite segurança, sofisticação, urgência, calma, confiança, estranhamento, familiaridade. Às vezes transmite tudo isso sem uma palavra. A IA trabalha muito bem com padrões. Mas produto bom nem sempre nasce só de padrão. Às vezes nasce de perceber que o padrão certo, naquele contexto, é justamente o que precisa ser quebrado.

Design Engineer não é "designer que sabe codar"

Design Engineer não é só alguém que abre o Figma e depois escreve React. Também não é um desenvolvedor que "tem bom gosto visual".

Para mim, o papel está mais perto de uma ponte operacional entre intenção de produto, desenho de experiência e materialização técnica.

É alguém capaz de perguntar: qual problema estamos tentando resolver? Qual experiência comprova que a solução faz sentido? Qual é o menor produto demonstrável que permite discussão real? Quais decisões precisam ser tomadas agora? Quais decisões devem ficar para depois? Onde a IA pode acelerar sem criar dívida, risco ou confusão?

No caso deste projeto, o foco não era substituir o trabalho futuro de engenharia. Era criar um handoff muito mais forte para ele. Um frontend funcional, documentado, com fluxos simulados, estados previstos, componentes organizados e cenários de teste dá ao time técnico uma base concreta para discutir backend, APIs, arquitetura e integração real.

No fim, o ganho de tempo só importa se melhora a decisão

O ganho de velocidade foi grande. Algo que poderia consumir semanas de uma esteira tradicional foi comprimido em dezenas de horas de direção, revisão e execução assistida.

Mas essa não é a parte mais interessante. O que importa é o que o tempo recuperado permite fazer melhor: revisar mais, testar alternativas, discutir produto com mais clareza, perceber ruídos de experiência e decidir com mais critério o que deve ou não avançar.

A IA acelera a execução. Mas fundamentos continuam decidindo a qualidade. Quanto mais fácil fica produzir, mais valioso fica saber avaliar. Quanto mais rápido fica gerar, mais importante fica saber direcionar.

Quanto mais a IA entrega respostas convincentes, mais necessário fica ter critério para não confundir aparência de produto com produto de verdade.

Sem método, você ganha código. Com método, começa a aparecer produto. Com fundamentos, esse produto começa a ter intenção.