Saltar al contingut principal
El nou rol del Product Designer en l'era del "Vibe Coding"
Lucho
Lucho, 12 de febrer del 2026

El nou rol del Product Designer en l'era del "Vibe Coding"

9 min. lectura
iaInnovacióProduct Design

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 ChatGPTClaude 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.

Cómo documentar el Motion Design en un Design System

Alexandra, 16 de juliol del 2024

El nou rol del Product Designer en l'era del "Vibe Coding" | Interactius