Com mais de 250 compromissos com clientes, tanto em agências quanto em funções internas, Vitalii Khomenko viu as equipes de produto por dentro de uma forma que poucos designers fizeram. Aqui ele defende um novo tipo de fluxo de trabalho de design criado para a era da IA e explica por que a janela de adaptação é mais estreita do que a maioria dos fundadores pensa.
Na última década, toda conversa de startup sobre velocidade acabou se tornando uma conversa sobre engenharia. Contratar mais desenvolvedores, reduzir escopo, escolher uma pilha mais simples, quase sempre era um problema do lado do desenvolvedor. Vitalii Khomenkodesigner principal da Orizon Design e fundador da Fluente LLC, argumenta que isso não é mais verdade. E ele tem uma visão específica sobre o que as equipes deveriam fazer.
O que faz com que a perspectiva de Khomenko valha a pena ser levada a sério não é apenas a antiguidade. É a forma específica de sua experiência. Ao longo de uma carreira que abrange mais de 250 contratos com clientes, ele trabalhou tanto como especialista externo contratado para entregar quanto como designer incorporado que se tornou o único fio condutor entre produto, marca e execução. Esse duplo ponto de vista é raro. A maioria dos designers vive de um lado dessa linha. Khomenko operou extensivamente em ambos, o que lhe dá uma leitura invulgarmente clara sobre onde o atrito realmente se origina dentro das equipes de produto e onde não.
Seu trabalho abrange startups em estágio inicial que encontram sua primeira linguagem visual e marcas estabelecidas que gerenciam sistemas de design complexos e multidisciplinares. Nessa faixa, certos padrões se repetem. E o padrão que começou a se tornar impossível de ignorar este ano levou-o a uma conclusão que está remodelando a forma como ele acha que um fluxo de trabalho de design moderno deveria realmente ser estruturado.
O gargalo não desapareceu. Ele se moveu. E o fluxo de trabalho precisa acompanhar isso.
O problema de como as equipes de design estão trabalhando atualmente
Quando o código de envio era lento, o fluxo de trabalho de design existente fazia sentido. Várias rodadas de revisão, testes de usuário, iteração, tudo isso se encaixa naturalmente na janela enquanto a engenharia se atualiza. Essa janela desapareceu e a maioria dos fluxos de trabalho de design nunca foi atualizada para refleti-la.
“Os fundadores estão pedindo às equipes de design que se movam na mesma velocidade de um pipeline de desenvolvimento assistido por IA, e o design não é compactado da mesma forma que o código”, diz Khomenko. O resultado é um fluxo de trabalho construído em torno de uma restrição que não existe mais, aplicado a um pipeline que mudou fundamentalmente em torno dela.
A escolha forçada entre polimento e velocidade que as equipes de produto estão enfrentando agora não é um conceito novo. A novidade é como isso se tornou rígido e como isso remonta diretamente a um problema de fluxo de trabalho, e não a um problema pessoal. “Como o desenvolvimento é barato e rápido agora, há uma pressão constante para lançar o próximo produto imediatamente”, explica ele. “Mas os produtos que realmente retêm os usuários ainda são aqueles em que os detalhes foram considerados cuidadosamente. Menos rodadas de revisão não são uma melhoria do processo se isso significar o envio de atritos evitáveis”.
Khomenko observou isso acontecer em equipes suficientes, em estágios suficientes, para ser específico sobre onde o fluxo de trabalho existente falha. A questão não é o julgamento do design. É onde fica esse julgamento no processo e qual formato se espera que ele produza no final.
Por que as transferências do Figma são agora o gargalo
Para entender a correção proposta por Khomenko, é útil entender exatamente onde o fluxo de trabalho atual para. Para a maioria das equipes de produto, o final do processo de design é assim: um designer produz telas polidas e prontas para desenvolvimento dentro do Figma e entrega esse arquivo à engenharia. A engenharia então interpreta essas telas, traduz as decisões visuais em código e constrói a partir daí.
Essa etapa de tradução, arquivo Figma para código funcional, é onde o pipeline agora falha. A engenharia assistida por IA tornou a parte da construção dramaticamente mais rápida. Mas a etapa de tradução não mudou. Um engenheiro ainda precisa ler um arquivo Figma, interpretar o espaçamento, extrair ativos, fazer julgamentos sobre a estrutura do componente e escrever a implementação do zero. Esse processo leva o mesmo tempo de sempre.
“O fluxo de trabalho manual dentro do Figma simplesmente não acompanha a engenharia impulsionada pela IA”, diz Khomenko. “A transferência do design está silenciosamente se tornando aquilo que todos esperam.”
O resultado é um pipeline onde tudo em torno da transferência foi acelerado e a transferência em si se tornou o único ponto de arrasto. O Figma, em outras palavras, foi construído para um mundo onde a engenharia era a parte lenta. Ele não foi projetado para alimentar um pipeline onde a engenharia se move na velocidade da IA.
A correção: entrega final em código, não em Figma
Este é o cerne do que Khomenko propõe e é uma mudança estrutural mais significativa do que pode parecer à primeira vista.
Em seu fluxo de trabalho, Figma não desaparece. Ele se move. Em vez de servir tanto como ambiente de exploração quanto como artefato de entrega final, Figma se torna exclusivamente a camada de exploração visual: o local onde a identidade da marca é estabelecida, a lógica do layout é trabalhada e a direção do design é validada. Continua sendo a ferramenta certa para descobrir como algo deve ser e como deve ser.
Mas a entrega final, o artefato que realmente vai para a engenharia, é o código. Especificamente, componentes integrados em bibliotecas preparadas nas quais a engenharia pode trabalhar e escalar diretamente, sem qualquer etapa de tradução entre eles.
A diferença na velocidade de implementação é o ponto. Quando um designer entrega uma biblioteca de componentes codificados em vez de um arquivo Figma, a engenharia não precisa interpretar nada. As decisões já estão expressas na linguagem em que estão sendo construídas. O que antes exigia que um engenheiro lesse, interpretasse e recriasse a partir de uma referência visual agora chega pronto para uso. Em um pipeline executado em desenvolvimento assistido por IA, essa diferença aumenta rapidamente.
“Figma ainda é o lugar certo para explorar a aparência e a sensação de algo”, diz Khomenko. “Mas entregar um arquivo Figma e pedir à engenharia para implementá-lo agora é o caminho mais lento. Entregar o código é o caminho mais rápido. Essa é a mudança.”
O designer que isso requer
A execução desse fluxo de trabalho requer um tipo diferente de designer, e Khomenko é direto quanto a isso. O UI/UX designer tornar-se Engenheiro de Design não é, na sua avaliação, uma possibilidade distante. É uma questão de tempo, e as equipes que tratam isso como uma consideração futura, em vez de uma realidade presente, são as que têm maior probabilidade de ficarem presas na transferência.
Mas Khomenko é igualmente claro sobre o que esta mudança não significa. Entregar código é uma parte da função, não a totalidade dela. O ciclo completo de design não vai a lugar nenhum. Aplicar branding a imagens, produzir animações, construir materiais de marketing, estas continuam a ser tarefas criativas essenciais que requerem um kit de ferramentas amplo e variado, muito além do código. “O designer do futuro próximo não está apenas gerando código”, diz ele. “Eles estão percorrendo todo o ciclo, marca, movimento, marketing, produto, com a engenharia de design como uma parte importante e crescente dessa pilha, e não como um substituto para ela”.
O que muda é que a entrega pronta para código se torna uma expectativa central nessa pilha. O designer que consegue passar com fluidez da exploração visual no Figma até a entrega de componentes no código, ao mesmo tempo que carrega o pensamento da marca, o movimento e a criatividade de marketing que diferencia os produtos no nível superficial que os usuários realmente experimentam, é o perfil que o novo fluxo de trabalho exige.
Uma nota honesta sobre a situação atual
Khomenko é sincero ao dizer que nenhuma versão desse fluxo de trabalho foi totalmente padronizada ainda. Cada equipe está descobrindo isso de maneira diferente. As ferramentas estão evoluindo, as expectativas de transferência estão mudando e os processos que as equipes estão construindo em torno de tudo isso variam consideravelmente. Não existe um manual pronto para uso.
Mas é precisamente aqui que os seus mais de 250 compromissos se tornam mais do que uma credencial. Eles são um conjunto de dados. Tendo observado equipes suficientes, em estágios suficientes, através de ciclos suficientes de troca de ferramentas, Khomenko pode ver através do ruído da variação individual e identificar o que é direcionalmente verdadeiro, mesmo quando as especificidades ainda estão em fluxo. “O fluxo de trabalho de cada equipe é realmente personalizado nesta fase”, diz ele. “Mas alguns padrões gerais de como isso será no futuro próximo já são visíveis”.
Esses padrões apontam consistentemente na mesma direção: o julgamento do design avançando mais cedo, a entrega final movendo-se para o código e o papel do designer expandindo-se em alcance técnico enquanto permanece amplo no escopo criativo. As ferramentas e sequências exatas continuarão mudando. A lógica subjacente ao fluxo de trabalho que Khomenko descreve já está tomando forma nas equipes que prestam mais atenção.
O que os fundadores devem fazer agora
Para fundadores e líderes de produtos, o fluxo de trabalho que Khomenko descreve tem implicações diretas na forma como as equipes são formadas, orçamentadas e estruturadas.
Julgamento de projeto de carregamento frontal. A maior vantagem no novo fluxo de trabalho não é a execução mais rápida, mas sim a melhor definição do problema antes do início da geração. Traga o design thinking sênior mais cedo, quando ele puder moldar o que é construído, em vez de aprimorar o que já está feito.
Exploração separada da entrega. Figma e a fase de exploração visual têm um propósito distinto da camada de entrega final. Trate-os como estágios separados com expectativas distintas, em vez de reduzi-los em uma única etapa que deverá produzir tudo.
Mude a expectativa de entrega para o código. Quer isso signifique contratar a linha de engenheiros de design, desenvolvê-la internamente ou reestruturar as transferências, o fim do pipeline de design precisa chegar de uma forma que a engenharia possa trabalhar diretamente. A etapa da tradução é onde o tempo morre e agora é a parte mais evitável do processo.
Proteja toda a pilha de criativos. A engenharia de design é mais importante do que nunca. Contudo, não é todo o trabalho. As equipes que reduzem o design à geração de código perderão o pensamento da marca, o movimento e a criatividade de marketing que diferenciam os produtos no nível superficial que os usuários realmente experimentam.
Mantenha-se flexível. O fluxo de trabalho ainda está se formando. As equipes que incorporarem rigidez em seus processos agora se verão refazendo esse trabalho dentro de um ano. As equipes que acertam são aquelas que criam adaptabilidade suficiente em suas estruturas para absorver o que ainda está por vir.
“A transferência do Figma fazia sentido quando a engenharia era a parte lenta”, diz Khomenko. “A engenharia não é mais a parte lenta. A entrega em código não é o futuro do fluxo de trabalho de design. Para as equipes que estão prestando atenção, já é o presente.”
Source link
