El flujo de trabajo de diseño está roto. Así cree Vitalii Jomenko que se debería solucionar el problema

Con lo que cuenta como más de 250 compromisos con clientes en agencias y roles internos integrados, Vitalii Khomenko ha visto equipos de producto desde el interior. Aquí defiende un nuevo tipo de flujo de trabajo de diseño creado para la era de la IA y explica por qué la ventana para adaptarse es más estrecha de lo que la mayoría de los fundadores piensan.

Durante la última década, cada conversación de startups sobre velocidad eventualmente se convirtió en una conversación sobre ingeniería. Contratar más desarrolladores, reducir el alcance, elegir una pila más simple, casi siempre fue un problema del lado del desarrollador. Vitalii Khomenko, diseñador principal de Orizon Design y fundador de Fluente LLC, sostiene que eso ya no es cierto. Y tiene una visión específica sobre lo que deberían hacer los equipos.

La opinión de Jomenko surge de la forma de su experiencia. Ha trabajado como especialista externo contratado para realizar entregas y como diseñador integrado que conecta el producto, la marca y la ejecución, lo que, según él, le muestra dónde se origina realmente la fricción dentro de los equipos de producto y dónde no.

Su trabajo abarca las primeras etapas nuevas empresas encontrar su primer lenguaje visual y marcas establecidas gestionando proyectos complejos y multidisciplinarios. sistemas de diseño. A lo largo de ese rango, ciertos patrones se repiten. Y el patrón que comenzó a volverse imposible de ignorar este año lo llevó a una conclusión que está cambiando la forma en que cree que debería estructurarse un flujo de trabajo de diseño moderno.

El cuello de botella no desapareció. Se movió. Y el flujo de trabajo debe avanzar con él.

El problema con la forma en que trabajan actualmente los equipos de diseño

Cuando el código de envío era lento, el flujo de trabajo de diseño existente tenía sentido. Múltiples rondas de revisión, pruebas de usuarioiteración, todo eso encaja naturalmente en la ventana mientras la ingeniería se pone al día. Esa ventana ya no existe y la mayoría de los flujos de trabajo de diseño nunca se actualizaron para reflejarla.

“Los fundadores están pidiendo a los equipos de diseño que se muevan a la misma velocidad que un Canal de desarrollo asistido por IAy el diseño no se comprime de la misma manera que lo hace el código,«, dice Khomenko. El resultado es un flujo de trabajo que se construyó en torno a una restricción que ya no existe, aplicado a un oleoducto que ha cambiado fundamentalmente a su alrededor.

La elección forzada entre pulido y velocidad que ahora enfrentan los equipos de producto no es un concepto nuevo. Lo nuevo es cuán crudo se ha vuelto y cuán directamente se remonta a un problema de flujo de trabajo en lugar de un problema de personas. “Debido a que el desarrollo es barato y rápido ahora, hay una presión constante para enviar lo siguiente de inmediato.«, explica.»Pero los productos que realmente retienen a los usuarios siguen siendo aquellos cuyos detalles se consideraron cuidadosamente. Menos rondas de revisión no son una mejora del proceso si eso significa eliminar fricciones evitables.«

Khomenko ha observado cómo se desarrolla esto en suficientes equipos, en suficientes etapas, para ser específico sobre dónde se rompe el flujo de trabajo existente. La cuestión no es el juicio de diseño. Es dónde reside ese juicio en el proceso y qué formato se espera que produzca al final.

Por qué las transferencias de Figma son ahora el cuello de botella

Para comprender la solución propuesta por Khomenko, es útil comprender exactamente dónde se estanca el flujo de trabajo actual. Para la mayoría de los equipos de producto, el final del proceso de diseño se ve así: un diseñador produce pantallas pulidas y listas para desarrollo dentro de Figma y entrega ese archivo a ingeniería. Luego, la ingeniería interpreta esas pantallas, traduce las decisiones visuales en código y construye a partir de ahí.

Ese paso de traducción, el archivo Figma al código de trabajo, es donde ahora se rompe el proceso. La ingeniería asistida por IA ha hecho que la construcción sea mucho más rápida. Pero el paso de traducción no ha cambiado. Un ingeniero todavía tiene que leer un archivo Figma, interpretar el espaciado, extraer activos, tomar decisiones sobre la estructura de los componentes y escribir la implementación desde cero. Ese proceso lleva la misma cantidad de tiempo que siempre.

“El flujo de trabajo manual dentro de Figma simplemente no está a la altura de la ingeniería impulsada por la IA.«, dice Khomenko. «El traspaso del diseño se está convirtiendo silenciosamente en lo que todos esperan.«

El resultado es un proceso en el que todo lo relacionado con el traspaso se ha acelerado y el traspaso en sí se ha convertido en el único punto de arrastre. En otras palabras, Figma fue construida para un mundo donde la ingeniería era la parte lenta. No fue diseñado para alimentar un proceso donde la ingeniería avanza a la velocidad de la IA.

La solución: entrega final en código, no en Figma

Este es el núcleo de lo que propone Khomenko, y es un cambio estructural más significativo de lo que podría parecer a primera vista.

En su flujo de trabajo, Figma no desaparece. Se mueve. En lugar de servir como entorno de exploración y artefacto de entrega final, Figma se convierte exclusivamente en la capa de exploración visual: el lugar donde se establece la identidad de la marca, se trabaja con la lógica del diseño y se valida la dirección del diseño. Sigue siendo la herramienta adecuada para descubrir cómo debería verse y sentirse algo.

Pero la entrega final, el artefacto que realmente llega a la ingeniería, es el código. Específicamente, componentes integrados en bibliotecas preparadas desde las cuales la ingeniería puede trabajar y escalar directamente, sin ningún paso de traducción intermedio.

La diferencia en la velocidad de implementación es el punto. Cuando un diseñador entrega una biblioteca de componentes codificados en lugar de un archivo Figma, la ingeniería no necesita interpretar nada. Las decisiones ya se expresan en el lenguaje en el que se están construyendo. Lo que antes requería que un ingeniero leyera, interpretara y recreara a partir de una referencia visual ahora llega listo para usar. En un proceso que se basa en el desarrollo asistido por IA, esa diferencia se agrava rápidamente.

“Figma sigue siendo el lugar adecuado para explorar cómo debería verse y sentirse algo.«, dice Khomenko. «Pero entregar un archivo Figma y pedirle a ingeniería que lo implemente ahora es el camino lento. Entregar en código es el camino rápido. Ese es el cambio.«

El diseñador que esto requiere

Ejecutar este flujo de trabajo requiere un tipo diferente de diseñador, y Khomenko es directo al respecto. Que un diseñador UI/UX se convierta en ingeniero de diseño no es, en su opinión, una posibilidad lejana. Es una cuestión de tiempo, y los equipos que lo tratan como una consideración futura en lugar de una realidad presente son los que tienen más probabilidades de quedarse atrapados en el traspaso.

Pero Jomenko es igualmente claro acerca de lo que no significa este cambio. Entregar código es una parte de la función, no la totalidad. El ciclo de diseño completo no va a ninguna parte. Aplicar la marca a las imágenes, producir animaciones y crear materiales de marketing siguen siendo tareas creativas esenciales que requieren un conjunto de herramientas amplio y variado que va mucho más allá del código. “El diseñador del futuro cercano no se limita a generar código,«, dice.»Se están moviendo a lo largo de todo el ciclo: marca, movimiento, marketing y producto, con la ingeniería de diseño como una parte importante y creciente de ese conjunto, no como un reemplazo.«

Lo que cambia es que la entrega del código listo se convierte en una expectativa central dentro de esa pila. El diseñador que puede pasar con fluidez de la exploración visual en Figma a la entrega de componentes en código, y al mismo tiempo llevar el pensamiento de marca, el movimiento y la creatividad de marketing que diferencia los productos en el nivel superficial que los usuarios realmente experimentan, es el perfil que exige el nuevo flujo de trabajo.

Una nota honesta sobre la situación actual

Khomenko es sincero en cuanto a que todavía no se ha estandarizado completamente ninguna versión de este flujo de trabajo. Cada equipo lo está resolviendo de manera diferente. Las herramientas están evolucionando, las expectativas de transferencia están cambiando y los procesos que los equipos están construyendo en torno a todo esto varían considerablemente. No existe un manual de estrategias disponible en el mercado.

Habiendo trabajado con muchos equipos, en diferentes etapas y a lo largo de varios ciclos de cambio de herramientas, Khomenko dice que algunos patrones ya están claros incluso cuando los detalles aún están cambiando. “El flujo de trabajo de cada equipo es realmente personalizado en esta etapa,«, dice.»Pero ya son visibles algunos patrones generales de cómo se verá esto en el futuro cercano.«

Esos patrones apuntan consistentemente en la misma dirección: el juicio de diseño avanza antes, la entrega final pasa al código y el rol del diseñador se expande en rango técnico sin dejar de ser amplio en alcance creativo. Las herramientas y secuencias exactas seguirán cambiando. La lógica subyacente del flujo de trabajo que describe Khomenko ya está tomando forma cuando los equipos prestan mayor atención.

Qué deberían hacer los fundadores ahora

Para los fundadores y líderes de productos, el flujo de trabajo que Khomenko describe tiene implicaciones directas sobre cómo se dota de personal, se presupuesta y se estructura a los equipos.

Juicio de diseño de carga frontal. La mayor ventaja del nuevo flujo de trabajo no es una ejecución más rápida, sino una mejor definición del problema antes de que comience la generación. Incorporar el pensamiento de diseño senior antes, cuando puede dar forma a lo que se construye en lugar de pulir lo que ya está hecho.

Separe la exploración de la entrega. Figma y la fase de exploración visual tienen un propósito distinto al de la capa de entrega final. Trátelos como etapas separadas con expectativas separadas, en lugar de colapsarlos en un solo paso que se espera que lo produzca todo.

Cambie la expectativa de entrega al código. Ya sea que eso signifique contratar ingenieros de diseño, desarrollarlos internamente o reestructurar traspasos, el final del proceso de diseño debe llegar en una forma en la que la ingeniería pueda trabajar directamente. El paso de traducción es donde el tiempo muere y ahora es la parte más evitable del proceso.

Proteja toda la pila creativa. La ingeniería de diseño importa más que nunca. Sin embargo, no es todo el trabajo. Los equipos que reducen el diseño a la generación de código perderán el pensamiento de marca, el movimiento y la creatividad de marketing que diferencian los productos en el nivel superficial que los usuarios realmente experimentan.

Manténgase flexible. El flujo de trabajo aún se está formando. Los equipos que ahora incorporan rigidez a su proceso se verán obligados a rehacer ese trabajo dentro de un año. Los equipos que hacen esto bien son los que construyen suficiente adaptabilidad en sus estructuras para absorber lo que está por venir.

“La transferencia de Figma tenía sentido cuando la ingeniería era la parte lenta,«, dice Khomenko. «La ingeniería ya no es la parte lenta. Entregar en código no es el futuro del flujo de trabajo de diseño. Para los equipos que prestan atención, ya es el presente.«

Vitalii Khomenko es diseñador principal de Orizon Design y fundador de Fluente LLC. Ha trabajado con nuevas empresas en etapa inicial y marcas establecidas, tanto como agencia especializada externa como diseñador interno integrado.