Del “diseñador que entregaba pantallas” al diseñador que recupera control.
David Martín, Product Designer y Co-fundador de Velada.app arranca situando el cambio como algo histórico, no una moda puntual: “creo que ahora con el Vibe Coding estamos volviendo a este punto… donde los diseñadores teníamos el control total o prácticamente total del producto”.
Lo potente de esa afirmación no es la nostalgia: es la consecuencia práctica. Si el diseñador vuelve a tocar “lo real” (producto funcionando), cambia el ritmo, el criterio y hasta el tipo de decisiones que puede tomar: “podemos diseñar mientras construimos”.
Aprendizajes que nos llevamos
- Si puedes “diseñar mientras construyes”, el handoff deja de ser el cuello de botella.
- Recuperar control no significa hacerlo todo: significa poder validar antes y mejor “sin necesidad de esperar a equipos de desarrollo”.
La vuelta a Dreamweaver: por qué el déjà vu importa (y mucho)
Para explicar el momento actual, David se va al origen: “Dreamweaver y Flash” como símbolos de una era donde “muchas veces el mismo diseñador era el desarrollador”.
Luego describe la “pérdida de control” cuando la industria se profesionaliza y el diseño se separa del desarrollo: “diseñábamos páginas web… con Photoshop” y había que crear documentos extra con “padding… márgenes… tamaños de texto” manualmente.
Aprendizajes que nos llevamos
- La historia se repite: cada salto de herramientas redefine el rol; hoy “estamos volviendo a este punto” de control ampliado.
- Si tu proceso aún depende de “especificar a mano”, estás operando con un modelo mental pre-IA (“eso no era nada eficiente”).
“El gran momento” del producto digital
David lo formula sin rodeos: “estamos en el gran momento para el producto digital”.
¿Sus tres razones? Menos fricción para crear, más velocidad y más autonomía: “se están reduciendo los costes y las barreras de entrada”, “los ciclos de diseño se acortan” y “el diseñador… vuelve a ganar la autonomía real”.
Aprendizajes que nos llevamos
- Tu ventaja competitiva ya no es “hacer pantallas”, sino aprender más rápido gracias a ciclos más cortos (“reducirlo a semanas o días”).
- Autonomía no es independencia absoluta: es poder mover el producto con menos dependencias (“sin necesidad de esperar a equipos de desarrollo”).
Una advertencia: el proceso sigue importando
David frena el hype con una idea clave: “el proceso de diseño sigue siendo importante”.
No es “prompt → app → éxito”. Él insiste en el ciclo completo: “investigación… ideación… prototipado… testeo” y en que “sin el proceso no vamos a llegar a ningún lado”.
Aprendizajes que nos llevamos
- Vibe Coding acelera, pero no sustituye discovery (“siguen siendo súper importantes”).
- Si tu equipo elimina investigación por velocidad, estás comprando deuda de producto (“sin el proceso…”).
Qué es exactamente el “Vibe Coding”
David lo resume así: “el Vibe Coding es construir productos a través de una conversación”.
La parte disruptiva no es “usar IA”, sino el desplazamiento de foco: “dejaba de importarle el código… simplemente quería que el producto funcionase”, incluso ante errores: “cogía una captura del error… ‘resuélvelo’”.
Aprendizajes que nos llevamos
- Pasas de diseñar “representaciones” a manipular comportamiento real (“conversando” en lugar de maquetar).
- El nuevo “flujo” se parece más a dirigir que a ejecutar: “quiero cambiar esta acción…” y ajustar iterativamente.
El nuevo proceso de diseño
El proceso de diseño “se reordena”: implementación antes, aprendizaje antes
David pone un ejemplo directo: como ahora “los tiempos son tan cortos”, quizá “podemos reordenarlo” y usar implementación como motor de ideación.
Más tarde lo reafirma en Q&A: quizá ya “no te da sentido hacer todas las fases estas previas hasta lanzar” porque puedes “hacer una versión muy simple… lanzarlo, testearlo… y luego volver a la ideación”.
Aprendizajes que nos llevamos
- Si el coste de “probar” cae, tu proceso puede pivotar a aprendizaje por prototipo (“lanzarlo, testearlo…”).
- Lo relevante es acortar tiempo hasta insight, no “cumplir fases” (“intercambiarlas porque ahora ya no hay tanta barrera”).
Diseñar mientras construyes: el caso de Lovable Prompts
Aquí David es muy concreto: “cuanto mejor es el prompt inicial… mejor es el resultado”.
En lugar de pasar primero por Figma, fue a ejecución: “no pasé por Figma. Directamente… construí un MVP… y funcionaba”. Luego, cuando ya había validación, sí: “me voy a Figma… le doy un poco de chapa y pintura”.
Aprendizajes que nos llevamos
- Si puedes construir rápido, Figma se convierte en refinamiento post-validación (“chapa y pintura”), no en punto de partida obligatorio.
- Un buen prompt es diseño estratégico: “muy detallados… funciones… look and feel…” es, en la práctica, especificación de producto.
La herramienta, creada por el, Lovable Prompts genera prompts optimizados para proyectos de vibe coding y lo hace de una forma optima. Aquí una comparación de lo que obtienes de una idea básica vs un prompt optimizado:
Para que pruebes Lovable Prompts, David nos regala un código del 40% de descuento, digita INTERACTIUS directamente en el checkout, ¡y disfrutalo!
Diseñar con datos: cuando el diseñador accede a SQL sin saber SQL
David señala una realidad incómoda: muchas veces “acabas diseñando sin esos datos y por intuición”.
Su punto es que ahora cambia el acceso: “no tenemos que saber SQL… porque podemos acceder… solo chateando”. Y da un ejemplo real: preguntó cuáles eran los casos de uso más frecuentes y acabó decidiendo el ejemplo de la landing con evidencia: “Dashboard… es el… más repetido”.
Aprendizajes que nos llevamos
- Si tu barrera era “no sé pedir datos”, ahora tu barrera es “no sé decidir qué medir”.
- El diseñador puede empujar decisiones data-informed sin depender de colas de otros equipos (“esto no podía haberlo hecho… tendría que pedir al equipo de desarrollo”).
Prototipos 100% funcionales: del “click dummy” a flujos reales con APIs
David distingue claramente: antes “podíamos hacer prototipos funcionales… pero nunca son como el producto final”.
Ahora, dice, sí: “podemos construir prototipos 100% funcionales”, con “login… recuperar contraseña… información real… APIs”. Su caso más potente es el de la fintech: “en unas dos semanas… construir un producto… con sus datos reales”.
Aprendizajes que nos llevamos
- Cuando el prototipo tiene datos reales, el test cambia de categoría (mejor comprensión, feedback más accionable): “si usamos los datos reales del usuario, los resultados… son mucho mejores”.
- “Prototipo” deja de significar “simulación”: puede ser un entorno controlado validable (“iba a ser un entorno controlado”).
Por qué “Figma to Code” no es el mejor camino
David no lo descarta por imposible, sino por limitado: “eso ya sí se puede hacer… pero… estamos perdiendo todo este proceso”.
Su crítica es de enfoque: si reduces la IA a convertir UI en código, renuncias a las ventajas clave del nuevo paradigma: velocidad de aprendizaje, prototipos reales, acceso a datos y decisión continua. “no es solo coger mi diseño y pasármelo a código”.
Aprendizajes que nos llevamos
- La oportunidad no es automatizar el handoff: es rediseñar el sistema de trabajo (“estamos perdiendo muchísimas partes interesantes”).
- Deja “lo aburrido” a la máquina: “replicar mil pantallas… estados vacíos…” y usa tu tiempo para “resolver problemas”.
El nuevo rol: de diseñador de interfaces a diseñador de decisiones
Aquí aparece la tesis central: con interfaces generativas, “va a llegar un momento en el que ya no tenemos que diseñar interfaces, sino diseñar procesos”.
Por eso David sentencia el giro: “va a pasar de diseñador de interfaces a diseñador de decisiones”. Y concreta el tipo de decisiones: “cuándo se muestran… cómo se muestran… qué implicaciones tienen”.
Aprendizajes que nos llevamos
- Tu valor sube cuando tu producto se vuelve adaptable: decisiones de reglas, contexto, personalización y presentación.
- Diseñar “decisiones” exige pensar en escenarios: “dar muchos escenarios… funcionalidades…” (esto ya es diseño de comportamiento).
La habilidad más difícil: abrazar la imperfección sin perder calidad
David toca un nervio sensible en diseño: “sé que a todos nos gusta ser pixel perfect”.
Pero lo redefine como una trampa: “no es tan relevante como nosotros nos creemos” y, además, la IA obliga a trabajar con incertidumbre: “es una caja negra… no sabemos qué pasa entre medias”.
Aprendizajes que nos llevamos
- Cambia el estándar: “suficientemente útil” antes que “perfecto” (“al menos útiles… lo mínimo necesario”).
- La obsesión por el pixel perfecto puede frenar el aprendizaje: “eso puede frenar el proceso”.
No todo es magia: seguridad, límites y por qué seguirás necesitando developers
David lo dice explícitamente: “vamos a seguir necesitando desarrolladores. Y creo que, en algunos casos, más que nunca”.
Y avisa de dos riesgos concretos. Uno: robustez si no tienes base técnica (“si no tienes ni idea de código es muy difícil… hacer algo robusto”). Dos: seguridad (“muchísimos problemas de seguridad… vulnerabilidades…”), incluso con experiencia personal: “dos productos… me los han hackeado”.
Aprendizajes que nos llevamos
- Para producción, revisiones técnicas son obligatorias: “yo preguntaría a alguien experto… que lo revise”.
- Aprender “algo” de código vuelve a ser palanca de calidad: “igual nos viene bien empezar a aprender algo de código… superficial”.
Herramientas y stack mental: de copilotos a entornos de construcción
David comparte su caja de herramientas sin postureo: “uso mucho ChatGPT… Claude y Gemini” y explica casos (copies, probar algoritmos, artefactos, imágenes).
En Vibe Coding, su rutina es incremental: “Lovable la uso para empezar… cuando el producto… más complejo, me voy a Cursor”. Y deja una señal importante para UX Leads: la barrera de entrada sigue siendo un factor: “Cloud Code… se usa en la terminal… hay más barrera de entrada”.
Aprendizajes que nos llevamos
- Piensa en herramientas por fase (inicio rápido vs escalado): “empiezo ahí… me voy a Cursor”.
- La adopción depende de ergonomía: “UI muy amigable… no tienes que saber nada de programación” acelera experimentación.
- En el video encontrarás un listado de herramientas para cada momento, seguro te sorprenderá con alguna que no conocías.
3 insights clave
- El cambio no es “hacer UI más rápido”: es volver a tocar el producto real, porque “podemos diseñar mientras construimos”.
- El rol evoluciona hacia criterio y estructura: “de diseñador de interfaces a diseñador de decisiones”.
- La velocidad no perdona atajos: “el proceso de diseño sigue siendo importante” y la seguridad es un riesgo real (“muchísimos problemas de seguridad”).
Si quieres ver el contexto completo, los ejemplos y el Q&A, te dejamos aquí el vídeo íntegro.
