La inteligencia artificial no enseña a los diseñadores a codificar. Les devuelve la decisión que originalmente les correspondía.
He estado pensando en un tipo particular de frustración que la mayoría de los diseñadores que conozco han experimentado al menos una vez y probablemente varias veces. Ha completado un componente. Has tenido en cuenta cada estado, cada transición y el peso exacto cuando se resuelve la animación. Entra en la etapa de desarrollo. Ha vuelto. Algo anda mal. No está dañado, sólo ligeramente oscurecido. La curva flexible está cerca, pero no es correcta. Al estado de desplazamiento le falta un marco en alguna parte. El espaciado se redondea a la marca más cercana.
Dejas un comentario. La próxima vez anotarás los archivos Figma con más cuidado. Estás tratando de transmitir un sentimiento a través de un archivo estático, lo cual es un poco como intentar describir una canción escribiendo la partitura y esperando que alguien escuche lo que tú escuchas.
La mayoría de los diseñadores han aprendido a asimilar esto. Se convierte en parte del ritmo: diseño, traspaso, aproximación, iteración. Pague impuestos sobre cada componente, cada sprint, durante toda la vida útil del producto. Lo suficientemente pequeño como para ignorarlo cualquier martes. En general, es lo suficientemente grande como para explicar por qué tantos productos parecen estar diseñados para capturas de pantalla en lugar de experiencias.
Lo que está cambiando (y por qué es más importante que la antigua conversación de que “los diseñadores deberían codificar”) es que las razones estructurales de este impuesto están desapareciendo.
diálogo equivocado
Durante más de una década, la industria ha estado preguntando a los diseñadores si deberían codificar. Ésta es siempre la pregunta equivocada, o al menos el marco equivocado. Implica que el obstáculo es técnico: al diseñador le falta algo fundamental, algo que requiere años de estudio para adquirirlo. Aprenda mecanografiado. Comprenda el DOM. Intenta cruzar el abismo.
Eso no es un obstáculo.
cuando leo El relato de Anna Lefort. ¿Qué pasó con el diseñador de chándales? Ella Morán Saltando directamente a Claude Code y omitiendo Figma por completo, no es la hazaña técnica lo que me impresiona. Parece tan normal. No hay grandes saltos ni puntos de inflexión. Es simplemente la ruta más rápida.
Y en allen, Iniciativa “Todos podemos construir” Una historia similar se cuenta a mayor escala. Durante dos trimestres, los diseñadores, los PM y los equipos de operaciones enviaron 283 solicitudes de extracción directamente al repositorio, cada una junto con una referencia de ingeniería responsable de la fusión final. Comenzó con algo pequeño: el color de un botón tardó semanas en entregarse, no porque fuera complejo sino porque la persona que descubrió el problema no pudo resolverlo por sí misma.
La puerta está abierta. Sólo hace falta la estructura adecuada para que caminar se sienta normal.
Estas herramientas no proporcionan conocimientos de codificación. Lo primero que eliminaron fue la justificación organizacional para mantener fuera a los diseñadores.
Siempre pierdes algo cuando cambias
El desarrollador que implementa el componente no ignorará los detalles que ingrese. Están resolviendo diferentes problemas: arquitectura, lógica, rendimiento y las partes de la pila que están lejos de la superficie. La curva de flexibilización no es su principal preocupación. En la mayoría de los sprints, ni siquiera está entre las diez principales preocupaciones. Entonces se vuelve aproximado. No maliciosamente. Simplemente despriorizar, cuando hay más trabajo que tiempo, todo se desprioriza.
Éste siempre ha sido un problema estructural del modelo de cambio: requiere que personas con diferentes prioridades representen fielmente intenciones que no generaron. El resultado es un producto que funciona, pero se siente menos considerado, porque la consideración está separada del medio.
Lo que es digno de mención es cuán invisible es este costo. No aparecerá en los informes de errores. Los usuarios no envían tickets porque dicen que la animación no es convincente. Una vez que se lanza un producto, funciona, y en algún lugar entre el diseño y la construcción existe una versión del producto que nadie llega a experimentar.
Los diseñadores siempre lo han sabido. El problema nunca ha sido la conciencia. Este es el acceso.
Autoría, no derechos de acceso
Una versión de este argumento se refiere simplemente a la eficiencia: menos ciclos de revisión, menos gastos generales de anotación, iteraciones más rápidas. Esta versión es correcta, pero subestima lo que realmente está en juego.
Las microinteracciones que se resuelven en el momento adecuado llevan un mensaje. Le dice al usuario que el sistema registró su acción y algo está respondiendo. Cuando se aproxima ese tiempo en la traducción, el producto pierde una pequeña parte de su confiabilidad. El usuario no lo indicó explícitamente. Simplemente crean una vaga sensación de que el producto es un poco menos confiable de lo que debería ser. Multiplique eso por un sistema de diseño completo y, después de un año de lanzamientos, obtendrá la deriva acumulativa que separa los productos que parecen sofisticados de aquellos que son meramente funcionales.
Lo que devuelven las herramientas de IA es la autoría a nivel superficial: las partes con las que los usuarios realmente interactúan. Los diseñadores ahora pueden abrir la biblioteca de códigos, ajustar el comportamiento de los elementos, cambiar la sensación de las transiciones y validar instantáneamente el resultado según su intención. La curva en espiral la establece la persona que determina la sensación de la curva en espiral. Los estados de desplazamiento están definidos por personas que piensan en su importancia. El trabajo ya no requiere un intérprete.
Para los ingenieros de front-end, este cambio desbloquea algo real. Las decisiones que consumen el poder del sprint (cómo se ve el anillo de enfoque, cómo se animan las descripciones emergentes, si los estados deshabilitados son legibles) ahora tienen dueños naturales. Los ingenieros pueden centrar su atención en las decisiones arquitectónicas que realmente requieren su experiencia: rendimiento, integridad del sistema, decisiones de juicio para determinar si una base de código aún será mantenible dentro de dos años.
Cambiando roles
Sería más fácil saltarse esta parte… Esta versión de la historia es en su mayor parte precisa y todos se benefician, los diseñadores obtienen nuevas herramientas y los ingenieros se centran en problemas más difíciles. Pero pasa por alto algo que merece un nombre directo.
Los desarrolladores front-end, cuyo trabajo principal es traducir la intención del diseño en código, se encuentran en una posición muy diferente a la de hace dos años. No porque el trabajo carezca de valor, sino porque la capa de traducción se está comprimiendo. La inteligencia artificial maneja suficientes cosas y es lo suficientemente consistente como para que la economía del rol esté cambiando. Aunque resulte incómodo decirlo, es verdad.
Lo que no se comprime es el juicio de hacer que la base del código sea mantenible en el tiempo. Evaluar las contribuciones a la integridad a largo plazo de una arquitectura, comprender los modos de falla de un sistema, hacer cumplir estándares que solo tienen sentido si se ve que un sistema diseñado falla en producción: este es un trabajo que, en el mejor de los casos, requiere la experiencia y el estado de la IA para ayudar en el borde.
El papel que emerge se parece menos a un puente entre disciplinas y más a una función de calidad del sistema. Su trabajo es garantizar la integridad de todo lo que fluye hacia el código base, independientemente de la fuente. Este personaje tiene un impacto real. Simplemente es diferente de lo que reemplaza, y vale la pena ser honesto acerca de esa diferencia en lugar de pretender que la transición es puramente acumulativa.
¿Qué requiere esto realmente?
Ninguno de estos se aplica a los equipos de forma predeterminada. Las condiciones que lo hacen funcionar son específicas y la mayoría de las organizaciones aún no las han creado.
El sistema de diseño que sólo existe en Figma no fue creado para esto. Los equipos donde los diseñadores aportan código real y fusionable (Chándal, Alan y otros que avanzan en la misma dirección) han invertido en sistemas de diseño como contexto estructurado y legible por máquina. Archivos de token, API de componentes, convenciones de nomenclatura claras, especificaciones de comportamiento. Cuando esta estructura está presente, la inteligencia artificial puede producir resultados que respeten el sistema en lugar de aproximarse a él. De lo contrario, las herramientas de inteligencia artificial simplemente crearán inconsistencias más rápidamente.
Las condiciones organizativas son tan importantes como las condiciones técnicas. Los diseñadores que contribuyen de manera más efectiva en este modelo trabajan con ingeniería, dentro de los mismos estándares de calidad, y revisan el contenido fusionado con ingenieros responsables de la integridad del sistema. Esta relación hace que la contribución del diseñador sea auténtica y sostenible.
El marco “los diseñadores deben codificar” establece una estructura binaria que siempre se centra más en el dominio que en la habilidad: aprenda todo el stack o permanezca en su carril. El alcance real de la apertura es más limitado y práctico que esto. Los diseñadores con amplios conocimientos de sistemas de diseño, que trabajan en un entorno estructurado asistido por inteligencia artificial y revisión de ingeniería, pueden tomar el control de la implementación de su trabajo. La disciplina no ha desaparecido. Los intérpretes sí.
Este es un cambio significativo para los diseñadores que han pasado años viendo cómo su oficio se aproxima al otro lado de la transición. La puerta nunca estuvo cerrada. Sólo necesitamos las herramientas para hacerlo obvio.
Si está explorando cómo se combinan el diseño, la inteligencia artificial y la ejecución real del producto, nos llevaremos muy bien.
Comparto perspectivas sobre la estrategia de experiencia del usuario, los sistemas de diseño, los flujos de trabajo de las agencias y cómo convertir ideas en productos construyebles. Si esto es relevante para lo que estás haciendo, no dudes en ponerte en contacto o continuar la conversación.
🔗 LinkedIn: https://www.linkedin.com/in/daniel-mitev
🌐 Sitio web: https://www.danielmitev.com
Los diseñadores finalmente tienen voz y voto en los productos que diseñan. Publicado originalmente en colectivo de experiencia de usuario En Medium, la gente continúa la conversación destacando y respondiendo a esta historia.
