De pantallas individuales a sistemas reutilizables.
La IA no cambió mi forma de pensar el producto. Cambió dónde invierto mi tiempo: dejé de producir pantallas a mano para construir sistemas reutilizables que me permiten explorar, validar y lanzar más rápido, sin bajar el nivel de exigencia en la evidencia.
Esto no es un escaparate de herramientas o prompts. Es un registro de trabajo real de un cambio que he hecho en cómo ejerzo el diseño de producto: por qué cambió, cómo trabajo ahora realmente, y hacia dónde creo que se dirige — todavía en evolución, y basado en proyectos reales, no en demos.
El descubrimiento y la investigación nunca fueron el problema. La producción era la parte cara.
El diseño de producto tradicional sigue dependiendo en gran medida de la producción manual: reconstruir layouts, rellenar datos ficticios, rehacer patrones comunes y preparar artefactos de entrega antes de que ingeniería pueda siquiera empezar. Nada de eso es pensar. Es carga operativa. El diagrama de abajo no trata de sustituir Figma, ni a los diseñadores, ni el código: trata de dónde recae el peso del trabajo.
Descubrimiento, investigación y pensamiento de producto ya ocupaban la mayor parte de mi tiempo. Producción era, sencillamente, la parte más cara del proceso.
↔ Desliza para ver todas las etapasDescubrimiento e investigación reciben ahora más tiempo, no menos: el pensamiento se expande hacia el espacio que antes ocupaba la producción. Producción cuesta una fracción de lo que costaba, así que prototipado y validación crecen para ocupar lo que queda.
La IA no cambió mi proceso de diseño. Cambió su economía.
Con más detalle, así es como se enruta realmente ese trabajo:
- Problema u oportunidad
- ¿Cuánta incertidumbre existe? Entender y evaluar
-
Alta incertidumbre Descubrimiento e investigación Reduce la incertidumbre antes de invertir.Baja incertidumbre Reutilización y exploración asistida por IA Reutiliza patrones probados. Acelera con confianza.
- Prototipado Explora, valida y refina ideas con rapidez usando sistemas reutilizables y asistencia de IA.
- Valida y refina Prueba con usuarios, reúne evidencia y genera confianza antes de entregar.
- Ingeniería Entrega soluciones listas para desarrollo con claridad y confianza.
No aplico el mismo proceso a todos los problemas. Antes que nada, evalúo cuánta incertidumbre existe. Los problemas genuinamente inciertos siguen empezando con descubrimiento, investigación y síntesis. Los problemas bien entendidos pueden avanzar más rápido mediante patrones reutilizables y exploración asistida por IA. Ambas rutas se reconectan en el Playground, donde prototipo, valido y refino ideas con rapidez antes de entregar a ingeniería con mayor confianza. Para los ajustes más simples y de menor riesgo, esa misma evaluación puede enviar el trabajo directamente a ingeniería, saltándose por completo el diseño y el descubrimiento. La IA no ha cambiado cómo tomo las decisiones de diseño. Ha cambiado la rapidez con la que puedo convertir esas decisiones en algo real.
Los componentes reutilizables se convirtieron en inteligencia reutilizable.
Sistema de diseño, editor de código, prototipo y documentación son un único sistema conectado, no cuatro herramientas separadas reconstruidas a mano cada vez. Curo una interfaz a partir de lo que ya existe (add bar-chart-tile, no una captura de pantalla de uno), dirigiendo a Claude Code y OpenAI Codex en VS Code, con GitHub Copilot en línea, contra una librería de componentes compartida y un conjunto de reglas en Markdown, de modo que el resultado coincide con el sistema por construcción. Que dos agentes lean las mismas reglas documentadas también funciona como una verificación cruzada: cuando discrepan, normalmente es la documentación la que necesita afinarse, no el código.
Sistema de diseño, editor de código, prototipo y documentación solían vivir en herramientas separadas, cada una reconstruida a mano en cada proyecto. Dentro del Playground son un único sistema conectado: componentes, tokens, reglas de accesibilidad y patrones de interacción ya existen, así que en lugar de describir una interfaz desde cero, la curo — nombrando el componente exacto que quiero (add bar-chart-tile, no una captura de pantalla de uno), de modo que el resultado coincide con el sistema por construcción, no por casualidad.
Los agentes que componen son Claude Code y OpenAI Codex, ambos ejecutándose dentro de VS Code y ambos leyendo la misma librería de componentes y las mismas reglas en Markdown, con GitHub Copilot encargándose de las sugerencias en línea mientras escribo. ChatGPT se usa aparte para el pensamiento que ocurre fuera del editor: enmarcar un problema, trabajar los datos, redactar la documentación que después leen los agentes. Dos agentes sobre un mismo sistema documentado también es una verificación cruzada útil; cuando discrepan, suele ser la documentación la que necesita afinarse, no el código.
Un cambio importó más de lo que esperaba: los datos realistas. En lugar de rellenar pantallas con lorem ipsum, construí conjuntos de datos ficticios y reutilizables (minoristas, productos y clientes inventados, modelados sobre patrones operativos reales) que pueblan los prototipos automáticamente. Un concepto promocional probado con una campaña ficticia de Mundial de fútbol y productos inventados resultó tan real para los participantes como un producto en producción, sin que un solo dato comercial saliera del edificio.
Esos datos ficticios son lo bastante buenos para diseñar y probar con ellos, no para lanzar. El prototipo y la funcionalidad en producción comparten los mismos componentes y la misma forma de datos; solo cambia la fuente: los registros inventados se sustituyen por un feed real y con los permisos correspondientes en la integración, de modo que la interfaz se comporta igual en cuanto los datos detrás son reales.
Aquí también hay un argumento comercial, no solo de oficio. Adivinar una interfaz desde cero cuesta más que componerla: más generaciones, más ciclos de corrección, más tokens gastados para llegar al mismo sitio. Reutilizar un sistema probado llega ahí en menos pasos, lo que significa una factura de IA más baja para el mismo resultado, no solo más rápido.
El trabajo de mantenimiento y ponerse al día con un competidor son ambos motivos legítimos para construir algo, pero la versión que quiero ver más es la tercera: algo que un usuario no sabía que necesitaba hasta que lo usó. Sigo sopesando eso frente a esfuerzo contra recompensa, un método de puntuación antiguo y simple, porque en el fondo siempre es una cuestión de qué retorno merece la inversión en una pieza de trabajo. Una vez lanzado, se aplica la misma disciplina de mi trasfondo en CRO: las pruebas cualitativas y cuantitativas deciden si se ganó su lugar, no el hecho de haberse lanzado.
- Lo que lo origina Una hoja de ruta basada en datos e investigación, que alinea las necesidades del negocio y del cliente.
- ¿Qué necesita esto? Patrón, funcionalidad o algo nuevo — la ruta depende de la respuesta.
- Ya en el sistema de diseño Directo a construcción VS Code — Claude Code y OpenAI Codex como agentes (construyendo con lo que ya existe), GitHub Copilot sugiriendo en línea. Sin necesidad de pasar por diseño.
-
Nuevo o incierto
Descubrimiento y entrega, en bucle
Se alterna entre ellos en cualquier orden, sin secuencia fija:
FigJam · Lucid — blueprints de servicio y flujos, primero. Figma — un prototipo rápido para probar, o diseño detallado cuando el patrón aún no existe. VS Code — Claude Code, OpenAI Codex y GitHub Copilot, con la entrega avanzando mientras el descubrimiento aclara la forma.
- Verificación de sensatez UX, accesibilidad y pautas de contenido — los archivos MD — detectando cualquier solapamiento o efecto colateral antes del lanzamiento.
-
Lanzamiento
Un repositorio de GitHub, con una base de datos conectada según se necesite.
Despliegue en Vercel Proyectos personales, lanzados directamente.Entrega a ingeniería Brambles y equipos de cliente — repo, código front-end y un prototipo funcionando.
La ruta depende de lo que necesite el trabajo, no de una secuencia fija: un cambio pequeño que usa patrones ya presentes en el sistema de diseño va directo a construcción, sin necesidad de pasar por diseño. Algo genuinamente nuevo o incierto entra en cambio en un bucle de descubrimiento y entrega — blueprints de servicio, prototipos o trabajo detallado en Figma, alternando entre VS Code y Figma en el orden que exija el problema. Ambas rutas pasan una verificación de sensatez contra las mismas pautas de UX, accesibilidad y contenido antes de lanzarse — directo a producción para mis propios proyectos, o entregado a ingeniería con un prototipo funcionando para Brambles y equipos de cliente.
- En código Componentes Construidos una vez, reutilizables — un bar-chart-tile, un date-picker, ya presentes en la librería.
- En MD y tokens Reglas Variantes, estados y espaciado, más pautas de UX, accesibilidad y contenido, ya escritas.
- Juntos Claude Code, OpenAI Codex y GitHub Copilot Componen solo a partir de lo nombrado y ya permitido — no un prompt en blanco.
Ninguna fuente basta por sí sola: los componentes sin reglas se usan mal, las reglas sin componentes se quedan en lo teórico. Juntas son lo que significa “Lee: archivos MD” en el diagrama de arriba.
Algunos artefactos de dentro del propio Playground — se añaden más a medida que la práctica sigue evolucionando:
Dónde ocurrió esto realmente.
Datos complejos, explorados como algo real y no como algo descrito.
Los dashboards de clientes empezaron como bocetos y flujos, y después pasaron al Playground como prototipos interactivos basados en gráficos. Los componentes de gráficos reutilizables y los tokens de diseño hicieron que los stakeholders reaccionaran ante algo que realmente podían usar, no ante una maqueta estática.
Ver más →Dos ejemplos más, Mapa de la página de inicio y Promociones minoristas, están en la versión completa.
Escalar una experiencia de mapas sin tener que rediseñarla a mano.
Una experiencia de página de inicio basada en ubicación necesitaba funcionar en varios productos y regiones. La exploración inicial empezó en Figma; una vez validado el modelo de interacción, el Playground me permitió reconstruirla como un patrón de mapas reutilizable y funcional, de modo que escalarla a un segundo producto significó reutilizar el patrón, no rediseñarlo.
Ver más →Lo bastante realista para probar, lo bastante seguro para compartir.
Un concepto de promociones minoristas explorado casi por completo dentro del Playground, con muy poco trabajo estático en Figma. Los componentes reutilizables y los conjuntos de datos ficticios y dinámicos (minoristas inventados, productos inventados, una campaña promocional ficticia del Mundial de fútbol) hicieron que el prototipo se sintiera real en las pruebas de usabilidad sin exponer un solo dato comercial.
Ver más →Cada resultado se convierte en la siguiente entrada.
Nada de esto se reinicia con cada tarea nueva. Los mismos archivos markdown de trabajo — decisiones, evidencia, reglas del sistema de diseño — se trasladan de una sesión asistida por IA a la siguiente, de modo que cada una empieza más adelantada que la anterior, en lugar de reexplicar el mismo contexto desde cero. Es el mismo principio basado en evidencia que sustenta el propio trabajo: cuanto más captura el sistema de los sistemas de diseño, los insights de usuario, los patrones de UX y la investigación, más tiene con lo que razonar, y mejor se vuelve su criterio con el tiempo.
El mismo principio de reutilización del Playground. Aplicado al conocimiento, no a los componentes.
El mismo principio, en otras manos.
Un diseñador al que hago de mentor, Dmytro Ivanchenko, llevó el mismo principio más lejos: componiendo un agente de IA directamente a partir de los componentes existentes de nuestro sistema de diseño y sus reglas de uso documentadas, y construyendo por separado un plugin que convierte un diseño entre breakpoints automáticamente.
Componer a partir de un sistema probado se traslada bien: otras personas pueden retomarlo y avanzar con él.
Lo que he aprendido
La IA no ha sustituido mi criterio. Ha cambiado dónde invierto mi tiempo.
- Menos tiempo reproduciendo pantallas, más tiempo entendiendo problemas.
- La reutilización se acumula: cada componente construido una vez se amortiza muchas veces.
- Los datos realistas importan tanto como las interfaces realistas.
- Los prototipos que funcionan invitan a un feedback más agudo que los prototipos que simplemente parecen acabados.
- La brecha entre “diseñado” y “construible” se estrecha cuando diseño e ingeniería comparten los mismos componentes.
El oficio del diseño no ha desaparecido: se ha desplazado, de producir pantallas individuales a orquestar los sistemas, la evidencia y la reutilización que hay detrás.
Hacia dónde va esto, y cómo pienso adaptarme.
Las cifras de más arriba en esta página — producción a la baja, descubrimiento y validación al alza — son un boceto aproximado de algo que ocurre a mayor escala: algo cercano al 60% del trabajo mecánico de diseño recae ahora en la IA, y el 40% restante — refinamiento, criterio, saber qué exige realmente un contexto — es hacia donde se ha desplazado el valor, no de donde ha desaparecido. Prefiero seguir esa proporción de forma deliberada, y planificar según hacia dónde se dirige, que darme cuenta un año tarde. Aquí está la versión honesta de ese plan:
- Ahora · 2026 ~60% IA, 40% criterio La IA redacta flujos, layouts y primeras versiones. Yo verifico: las reglas de los archivos MD, la revisión cruzada entre agentes, la verificación de sensatez antes de lanzar nada.
- Próximos 12 meses ~65% IA, 35% criterio Dirigiendo varios flujos de trabajo de IA a la vez, evaluando lo que producen en lugar de redactarlo yo mismo.
- Dos años ~70% IA, 30% criterio Menos revisarlo todo con la misma intensidad. Más triaje: decidir de antemano qué necesita realmente una verificación exhaustiva.
- Cinco años y más allá Brújula, no previsión Menos manos a la obra con una sola herramienta. Más definir los problemas con la precisión suficiente para verificar rápido el resultado de un agente frente a ellos.
Una línea de tiempo honesta, no un discurso de ventas: las paradas más cercanas se basan en lo que ya está cambiando, con las propias cifras de esta página; la más lejana es una brújula, no una previsión — prefiero decirlo con claridad antes que fingir una precisión que no tengo.
El razonamiento detrás de cada parada, y lo que permanece constante aunque cambie la proporción, está en la versión completa.
Por eso mismo la verificación de sensatez, los archivos MD y la revisión cruzada entre agentes me importan tanto como los diagramas que generan el trabajo en primer lugar. A medida que se delega más de la capa mecánica, lo que no se automatiza es que alguien sea responsable de que una decisión con consecuencias sea correcta. Es la misma disciplina detrás de la Gobernanza UX y el Design QA en otras partes de este sitio, aplicada a un conjunto de resultados que se mueve más rápido, no una habilidad nueva que estoy aprendiendo desde cero.
Más allá de generar interfaces, cada vez me interesa más cómo la IA puede hacer que el conocimiento de producto validado y la investigación sean más fáciles de descubrir, reutilizar y aplicar a lo largo del desarrollo de producto.
Un área que he estado explorando con nuestro equipo de investigación es cómo esto podría integrarse en el propio Playground, no para sustituir la investigación, sino para reducir el tiempo dedicado a buscar evidencia, de modo que los equipos puedan construir sobre lo que ya saben en lugar de empezar de cero.
Ve la misma disciplina basada en evidencia aplicada a una dirección de producto validada.