- Las herramientas de IA usan directamente los sistemas de diseño para generar UI, por lo que el rol del diseñador se está moviendo de la simple creación visual hacia un enfoque centrado en la estrategia y la coordinación
- Ahora la pregunta clave ya no es “quién le quitó el trabajo a quién”, sino cómo está cambiando el proceso
- El trabajo invisible como código, PRD y resúmenes es fácil de automatizar, pero en el trabajo visible como la UI y los flujos que el usuario ve y toca directamente, la brecha de calidad es mayor, por lo que la automatización del diseño todavía no avanza al ritmo de la ingeniería
- El mayor cuello de botella era el proceso de traducir un mockup de Figma a código, pero si el diseñador diseña directamente en un entorno de código, ese desperdicio de handoff puede eliminarse por completo
- En la era de la IA, el valor central del diseñador ya no está en mover píxeles, sino en la capacidad de orquestación: decidir qué construir, evaluar críticamente la salida de la IA y dirigir el trabajo
- Las empresas que inviertan en equipos pequeños empoderados y en sistemas de diseño legibles por máquina terminarán superando a las grandes organizaciones tipo feature factory
El contexto detrás del cambio en el diseño de producto
- Desde que creó su primer sitio web con Dreamweaver en 1999, el autor había trabajado diseñando con herramientas como Photoshop, Sketch y Figma, y luego entregando ese trabajo a los desarrolladores
- Recientemente conectó Claude Code al sistema de diseño de su empresa y logró generar una UI realmente funcional con solo tres prompts, saltándose la etapa tradicional de diseño visual
- A partir de esta experiencia, confirmó que el valor del diseñador se está desplazando de la capacidad de ejecución hacia el “gusto” y el criterio estratégico
- A medida que la IA implementa un flujo de “prompt → generación → despliegue” basado en sistemas de diseño, está en marcha una transformación fundamental del diseño de producto
El debate equivocado: no se trata del número de personas, sino del cambio en el proceso
- El discurso actual sobre la IA y los roles de producto sigue atrapado en disputas de territorio centradas en el número de personas, como “¿los diseñadores perderán sus empleos?” o “¿los ingenieros serán reemplazados?”
- La verdadera pregunta tiene que ver con el proceso: no se trata de que la IA elimine estas funciones, sino de quién las realiza, con qué rapidez y hacia dónde se desplazan los cuellos de botella
- El trabajo invisible como programar, redactar PRD o analizar datos se automatiza con facilidad porque la brecha de calidad queda oculta detrás de la UI
- Aunque el código sea desordenado, si la app funciona a nadie le importa; y aunque un PRD haya sido generado por IA, no importa mientras la definición del problema sea correcta
- En cambio, el trabajo visible como la interfaz de usuario, los flujos y la experiencia expone de inmediato cualquier diferencia de calidad, y el usuario la percibe al instante
- Cuando construir algo se vuelve rápido y barato, el problema más difícil deja de ser “cómo construirlo” y pasa a ser “qué vale la pena construir”
- La aceleración del diseño asistido por IA inevitablemente quedará rezagada frente a la ingeniería, y esta asimetría reconfigurará todo el proceso de desarrollo de producto y la forma de estructurar los equipos
Trabajo visible: el diseño no está detrás del muro, es el muro mismo
- La ingeniería puede compararse con la plomería: está oculta detrás de la pared, y si sale agua del grifo, la estructura interna deja de importar
- Boris Cherny opera 4 o 5 agentes de programación al mismo tiempo y ha logrado mejoras de velocidad superiores al 400%; los ingenieros de Silicon Valley están dejando de escribir código directamente para pasar a orquestar equipos de agentes
- El diseño de software, en cambio, es la pared misma, el grifo y la manija, así que aunque lo haya hecho una IA, los usuarios reaccionan con sensibilidad a su apariencia y a cómo se siente usarlo
- La IA puede seguir estándares y patrones presentes en los datos de entrenamiento, pero le cuesta procesar decisiones basadas en una enorme cantidad de investigación de usuarios —decenas de entrevistas, resultados de encuestas, análisis de uso y auditorías competitivas— porque el contexto es demasiado grande
- Existe un cuello de botella llamado problema de ingestión (ingestion problem): aunque la IA genere grandes cantidades de código o resúmenes de reuniones, los humanos todavía tienen que leerlos, interiorizarlos y evaluarlos críticamente para poder mantener conversaciones inteligentes y tomar decisiones
- La revisión de código ya se está convirtiendo en el verdadero cuello de botella, y eso está limitado por la velocidad humana, algo que ningún modelo puede evitar
- La IA destaca en la generación y el resumen de contenido, pero todavía no ha demostrado capacidad para crear algo verdaderamente nuevo ni para tener gusto (taste)
Diseñar en código, no en Figma
- El mayor cuello de botella del desarrollo de producto es el proceso de traducir mockups de Figma a código de producción, es decir, el handoff entre diseñador y desarrollador
- Se dibuja el software, se ajustan píxeles y luego se le entrega a ingeniería; después QA compara el código contra el mockup y rechaza PR por diferencias de tipografía o espaciado: una ineficiencia enorme
- La IA puede resolver este cuello de botella, pero solo cuando el diseñador diseña directamente dentro de un entorno de código
- Algunos diseñadores ya están cancelando sus suscripciones a Figma y pasándose a herramientas de IA; el argumento central es que el mockup no es el producto, sino un resultado paralelo que requiere traducción, revisión y ajuste
- Cada píxel empujado en Figma es una promesa que un ingeniero debe cumplir en un medio completamente distinto, y cuanto más lejos esté la herramienta de diseño del código de producción, mayor será el desperdicio que aparece en el handoff
- Un experimento con Claude Code, apuntándolo al repositorio del sistema de diseño, confirmó esto al generar una UI funcional con solo tres prompts
- Para lograr confiabilidad a escala se necesitan documentación sólida, reglas explícitas y orquestación de agentes, pero la base ya existe
- Caso del equipo de ingeniería de Monday.com: en el primer intento de pegar un enlace de Figma en Cursor, el código generado no usaba componentes del sistema de diseño, tenía colores hardcodeados y sobrescribía la tipografía predeterminada del sistema
- Como solución construyeron un MCP de sistema de diseño (Model Context Protocol): hicieron legibles por máquina los componentes, tokens, reglas de accesibilidad y patrones de uso, y estructuraron el contexto para el modelo con un flujo agéntico de 11 nodos
- El enfoque no consistía en que el agente escribiera código directamente, sino en construir una comprensión de cómo debía ser el código y luego entregársela al agente de programación del desarrollador: una aproximación de “orquestación, no magia”
- Diseñadores de Anthropic ya están enviando pull requests directamente con Claude Code y productos de consola, y desplegándolos en producción: para febrero de 2026, esto ya es una realidad
Lo que queda para los humanos: orquestación y criterio
- Si la IA puede generar código, redactar PRD, resumir investigación y prototipar interfaces, lo que queda para los humanos es la orquestación
- Los modelos ya son suficientemente capaces; el cuello de botella es la persona frente al teclado: saber qué pedir, cómo dividir el trabajo y cuándo rechazar el resultado del modelo es lo esencial
- Kyle Zantos, un diseñador que pasa el 70% de su jornada en la terminal, subraya que más importante que configuraciones concretas de herramientas es aprender la filosofía y el enfoque, porque incluso las recomendaciones de hace 4 meses ya quedaron obsoletas
- Arin Bhowmick, Chief Design Officer de SAP: una interfaz visualmente pulida puede ocultar problemas más profundos como salidas poco confiables, decisiones opacas y comportamiento frágil en edge cases
- Los líderes de diseño deben tratar la confianza, la claridad y la confiabilidad como resultados de diseño de primera categoría, no solo la calidad superficial
- Según Vlad Derdeicea, alrededor del 80% del tiempo de un design lead se consume en comunicación, alineación y justificación, y solo el 20% en trabajo práctico de diseño
- Toda decisión de diseño paga un “impuesto de justificación” (justification tax): el tiempo invertido en explicar, documentar y defender decisiones que en otras disciplinas podrían resolverse con una conversación breve
- La IA no debería apuntar al trabajo de mockups, sino a ese 80%: sintetizar actas de reuniones, redactar comunicaciones para stakeholders, resumir investigación y crear prototipos rápidos para resolver debates con datos en vez de opiniones
- El marco de Jan Tegze: no intentes hacer mejor el trabajo actual, sino identifica las restricciones del dominio que existen por los límites humanos y elimínalas con agentes; no se trata de acelerar tareas existentes, sino de hacer cosas que antes eran imposibles
- “No se trata de competir con los agentes, sino de crear nuevas capacidades que necesiten tanto a ti como a los agentes”
- Los diseñadores junior con menos de 5 años de experiencia están más expuestos al riesgo, porque les falta el criterio para evaluar salidas de IA y la experiencia para detectar errores del modelo; el piso de habilidades está subiendo
Equipos pequeños, gran apalancamiento
- La mayoría de las empresas de software tienen estructuras que ya no encajan con el momento actual: feature factories con exceso de PM, donde cada squad recibe un PM sin importar si realmente necesita apoyo de diseño dedicado
- Los PM crecieron durante la era de ZIRP porque están cerca de ingresos y porque su número tiende a expandirse con la complejidad organizacional
- Marty Cagan llama a esto “teatro de product management”: una sobreabundancia de PM ineficaces que no son muy distintos de project managers sobrepagados que hacen roadmaps y dirigen standups
- En Davos, Andrew Ng predijo que si la IA hace explotar la productividad en ingeniería, la proporción PM/ingeniero podría invertirse de 1:8 hacia 1:1
- Si los agentes de IA escriben la mayor parte del código de producción, la amplia base de ingeniería se reducirá y la especificación y el criterio se volverán recursos escasos
- Airbnb integró product management y product marketing en un solo rol “full-stack”
- Brian Chesky: “Si no sabes cómo hablar de un producto, no puedes construirlo”; con eso elevó el storytelling y la comunicación externa a elementos centrales del trabajo de PM
- También elevó a los diseñadores al rol de “arquitectos” que lideran el producto junto con los ingenieros, en lugar de ser un servicio subordinado que recibe tickets
- El trabajo de coordinación que antes inflaba la plantilla de PM se transfirió a program managers dedicados
- Esto se parece al modelo organizacional funcional de Apple: los especialistas lideran a especialistas, el CEO es el punto de integración y no existen PM como “mini CEO” a cargo de unidades de negocio
- En la era de la IA, el equipo ideal es un equipo pequeño y empoderado de 2 o 3 ingenieros, 1 PM y 1 diseñador
- El sistema de diseño se convierte en infraestructura central, y sin un sistema de diseño dentro del código y sin documentación, la IA tomará malas decisiones sobre la UI y la implementación
- Las empresas que inviertan en sistemas de diseño legibles por máquina y en equipos pequeños empoderados superarán a las que mantengan squads de 15 personas y aprobaciones en tres niveles
Efecto compuesto: la brecha entre el orquestador y el pixel pusher
- Tras el experimento de generar pantallas funcionales desde el sistema de diseño con Claude Code, el autor sigue mejorando continuamente con mejor documentación, reglas de componentes más estrictas y guías de composición más claras
- En cada ronda todo se vuelve más rápido y más cercano a producción, y la mejora del modelo, el refinamiento de habilidades y la capacidad de dirección se acumulan como interés compuesto
- La brecha entre el “diseñador que orquesta IA” y el “diseñador que mueve píxeles en Figma” se volverá enorme en los próximos 12 meses
- No porque el pixel pusher sea menos capaz, sino porque el orquestador opera a una velocidad y en un alcance fundamentalmente distintos: mientras otros siguen entregando mockups para reuniones de handoff, él ya está desplegando UI funcional
- El autor está enseñando este enfoque a su equipo, no porque la profesión vaya a desaparecer, sino porque se está convirtiendo en una profesión donde el gusto, el criterio y la capacidad de dirigir el trabajo importan más que la habilidad de dibujar pantallas
Aún no hay comentarios.