Del "dissenyador que lliurava pantalles" al dissenyador que recupera el control.
David Martín, Product Designer i Co-fundador de Velada.app comença situant el canvi com quelcom històric, no una moda puntual: "crec que ara amb el Vibe Coding estem tornant a aquest punt… on els dissenyadors teníem el control total o pràcticament total del producte".
El que té de potent aquesta afirmació no és la nostàlgia: és la conseqüència pràctica. Si el dissenyador torna a tocar "allò real" (producte funcionant), canvia el ritme, el criteri i fins i tot el tipus de decisions que pot prendre: "podem dissenyar mentre construïm".
Aprenentatges que ens emportem
- Si pots "dissenyar mentre construeixes", el handoff deixa de ser el coll d'ampolla.
- Recuperar el control no significa fer-ho tot: significa poder validar abans i millor "sense necessitat d'esperar els equips de desenvolupament".
La tornada a Dreamweaver: per què el déjà vu importa (i molt)
Per explicar el moment actual, David torna a l'origen: "Dreamweaver i Flash" com a símbols d'una era on "moltes vegades el mateix dissenyador era el desenvolupador".
Després descriu la "pèrdua de control" quan la indústria es professionalitza i el disseny se separa del desenvolupament: "dissenyàvem pàgines web… amb Photoshop" i calia crear documents addicionals amb "padding… marges… mides de text" manualment.
Aprenentatges que ens emportem
- La història es repeteix: cada salt d'eines redefinieix el rol; avui "estem tornant a aquest punt" de control ampliat.
- Si el teu procés encara depèn d'"especificar a mà", estàs operant amb un model mental pre-IA ("això no era gens eficient").
"El gran moment" del producte digital
David ho formula sense embuts: "estem en el gran moment per al producte digital".
Quines són les seves tres raons? Menys fricció per crear, més velocitat i més autonomia: "s'estan reduint els costos i les barreres d'entrada", "els cicles de disseny s'escurcen" i "el dissenyador… torna a guanyar l'autonomia real".
Aprenentatges que ens emportem
- El teu avantatge competitiu ja no és "fer pantalles", sinó aprendre més ràpid gràcies a cicles més curts ("reduir-ho a setmanes o dies").
- Autonomia no és independència absoluta: és poder moure el producte amb menys dependències ("sense necessitat d'esperar els equips de desenvolupament").
Un advertiment: el procés continua important
David frena l'hype amb una idea clau: "el procés de disseny continua sent important".
No és "prompt → app → èxit". Ell insisteix en el cicle complet: "recerca… ideació… prototipat… testatge" i en que "sense el procés no arribarem enlloc".
Aprenentatges que ens emportem
- Vibe Coding accelera, però no substitueix el discovery ("continuen sent súper importants").
- Si el teu equip elimina la recerca per velocitat, estàs acumulant deute de producte ("sense el procés…").
Què és exactament el "Vibe Coding"
David ho resumeix així: "el Vibe Coding és construir productes a través d'una conversa".
La part disruptiva no és "usar IA", sinó el desplaçament de focus: "deixava d'importar-li el codi… simplement volia que el producte funcionés", fins i tot davant d'errors: "agafava una captura de l'error… 'resol-ho'".
Aprenentatges que ens emportem
- Passes de dissenyar "representacions" a manipular comportament real ("conversant" en lloc de maquetant).
- El nou "flux" s'assembla més a dirigir que a executar: "vull canviar aquesta acció…" i ajustar iterativament.
El nou procés de disseny
El procés de disseny "es reordena": implementació abans, aprenentatge abans
David posa un exemple directe: com ara "els temps són tan curts", potser "podem reordenar-ho" i usar la implementació com a motor d'ideació.
Més endavant ho reafirma al Q&A: potser ja "no té sentit fer totes aquestes fases prèvies fins a llançar" perquè pots "fer una versió molt simple… llançar-la, testar-la… i tornar a la ideació".
Aprenentatges que ens emportem
- Si el cost de "provar" cau, el teu procés pot pivotar cap a l'aprenentatge per prototip ("llançar-ho, testar-ho…").
- El rellevant és escurçar el temps fins a l'insight, no "complir fases" ("intercanviar-les perquè ara ja no hi ha tanta barrera").
Dissenyar mentre construeixes: el cas de Lovable Prompts
Aquí David és molt concret: "com millor és el prompt inicial… millor és el resultat".
En lloc de passar primer per Figma, va anar a l'execució: "no vaig passar per Figma. Directament… vaig construir un MVP… i funcionava". Després, quan ja hi havia validació, sí: "vaig a Figma… li dono una mica de mà de pintura".
Aprenentatges que ens emportem
- Si pots construir ràpid, Figma es converteix en refinament post-validació ("mà de pintura"), no en punt de partida obligatori.
- Un bon prompt és disseny estratègic: "molt detallats… funcions… look and feel…" és, en la pràctica, especificació de producte.
L'eina, creada per ell, Lovable Prompts genera prompts optimitzats per a projectes de vibe coding i ho fa d'una forma òptima. Aquí una comparació del que obtens d'una idea bàsica vs un prompt optimitzat:

Perquè puguis provar Lovable Prompts, David ens regala un codi del 40% de descompte; escriu INTERACTIUS directament al checkout, i gaudeix-ne!
Dissenyar amb dades: quan el dissenyador accedeix a SQL sense saber SQL
David assenyala una realitat incòmoda: moltes vegades "acabes dissenyant sense aquestes dades i per intuïció".
El seu punt és que ara canvia l'accés: "no hem de saber SQL… perquè podem accedir… simplement xatejant". I posa un exemple real: va preguntar quins eren els casos d'ús més freqüents i va acabar decidint l'exemple de la landing amb evidència: "Dashboard… és el… més repetit".
Aprenentatges que ens emportem
- Si la teva barrera era "no sé demanar dades", ara la teva barrera és "no sé decidir què mesurar".
- El dissenyador pot impulsar decisions data-informed sense dependre de les cues d'altres equips ("això no ho podria haver fet… hauria de demanar-ho a l'equip de desenvolupament").
Prototips 100% funcionals: del "click dummy" a fluxos reals amb APIs
David distingeix clarament: abans "podíem fer prototips funcionals… però mai són com el producte final".
Ara, diu, sí: "podem construir prototips 100% funcionals", amb "login… recuperar contrasenya… informació real… APIs". El seu cas més potent és el de la fintech: "en unes dues setmanes… construir un producte… amb les seves dades reals".
Aprenentatges que ens emportem
- Quan el prototip té dades reals, el test canvia de categoria (millor comprensió, feedback més accionable): "si usem les dades reals de l'usuari, els resultats… són molt millors".
- "Prototip" deixa de significar "simulació": pot ser un entorn controlat validable ("anava a ser un entorn controlat").
Per què "Figma to Code" no és el millor camí
David no ho descarta per impossible, sinó per limitat: "això ja sí es pot fer… però… estem perdent tot aquest procés".
La seva crítica és d'enfocament: si redueixes la IA a convertir UI en codi, renunces als avantatges clau del nou paradigma: velocitat d'aprenentatge, prototips reals, accés a dades i decisió contínua. "no és només agafar el meu disseny i passar-lo a codi".
Aprenentatges que ens emportem
- L'oportunitat no és automatitzar el handoff: és redissenyar el sistema de treball ("estem perdent moltíssimes parts interessants").
- Deixa "l'avorrit" a la màquina: "replicar mil pantalles… estats buits…" i usa el teu temps per "resoldre problemes".
El nou rol: de dissenyador d'interfícies a dissenyador de decisions
Aquí apareix la tesi central: amb interfícies generatives, "arribarà un moment en què ja no haurem de dissenyar interfícies, sinó dissenyar processos".
Per això David sentencia el gir: "passarà de dissenyador d'interfícies a dissenyador de decisions". I concreta el tipus de decisions: "quan es mostren… com es mostren… quines implicacions tenen".
Aprenentatges que ens emportem
- El teu valor augmenta quan el teu producte es torna adaptable: decisions de regles, context, personalització i presentació.
- Dissenyar "decisions" exigeix pensar en escenaris: "donar molts escenaris… funcionalitats…" (això ja és disseny de comportament).
L'habilitat més difícil: abraçar la imperfecció sense perdre qualitat
David toca un nervi sensible en disseny: "sé que a tots ens agrada ser pixel perfect".
Però ho redefinieix com una trampa: "no és tan rellevant com ens creiem" i, a més, la IA obliga a treballar amb incertesa: "és una caixa negra… no sabem què passa entremig".
Aprenentatges que ens emportem
- Canvia l'estàndard: "prou útil" abans que "perfecte" ("almenys útils… el mínim necessari").
- L'obsessió pel pixel perfect pot frenar l'aprenentatge: "això pot frenar el procés".
No tot és màgia: seguretat, límits i per què continuaràs necessitant developers
David ho diu explícitament: "continuarem necessitant desenvolupadors. I crec que, en alguns casos, més que mai".
I avisa de dos riscos concrets. Un: robustesa si no tens base tècnica ("si no tens ni idea de codi és molt difícil… fer alguna cosa robusta"). Dos: seguretat ("moltíssims problemes de seguretat… vulnerabilitats…"), fins i tot amb experiència personal: "dos productes… me'ls han hackejat".
Aprenentatges que ens emportem
- Per a producció, les revisions tècniques són obligatòries: "jo preguntaria a algú expert… que ho revisi".
- Aprendre "alguna cosa" de codi torna a ser una palanca de qualitat: "potser ens ve bé començar a aprendre alguna cosa de codi… superficial".
Eines i stack mental: de copilotos a entorns de construcció
David comparteix la seva caixa d'eines sense pretensions: "faig servir molt ChatGPT… Claude i Gemini" i explica casos d'ús (copies, provar algorismes, artefactes, imatges).
En Vibe Coding, la seva rutina és incremental: "Lovable la faig servir per començar… quan el producte… és més complex, vaig a Cursor". I deixa un senyal important per a UX Leads: la barrera d'entrada continua sent un factor: "Cloud Code… s'usa a la terminal… hi ha més barrera d'entrada".
Aprenentatges que ens emportem
- Pensa en eines per fase (inici ràpid vs escalat): "començo allà… vaig a Cursor".
- L'adopció depèn de l'ergonomia: "UI molt amigable… no has de saber res de programació" accelera l'experimentació.
- Al vídeo trobaràs un llistat d'eines per a cada moment; segur que et sorprendrà alguna que no coneixies.
3 insights clau
- El canvi no és "fer UI més ràpid": és tornar a tocar el producte real, perquè "podem dissenyar mentre construïm".
- El rol evoluciona cap al criteri i l'estructura: "de dissenyador d'interfícies a dissenyador de decisions".
- La velocitat no perdona dreceres: "el procés de disseny continua sent important" i la seguretat és un risc real ("moltíssims problemes de seguretat").
Si vols veure el context complet, els exemples i el Q&A, et deixem aquí el vídeo íntegre.


