Prompts per a disseny UX/UI: com parlar amb la IA perquè sigui realment útil

Durant els últims mesos he vist molts prompts que prometen resultats extraordinaris. Plantilles universals, llistes amb cent ordres imprescindibles i estructures que suposadament converteixen qualsevol petició en una resposta perfecta. La meva experiència és bastant menys espectacular.
No crec que existeixi el prompt definitiu. Tampoc crec que aprendre com crear prompts per a IA consisteixi a descobrir una combinació secreta de paraules. En disseny, els prompts per a UX/UI funcionen millor quan expliquen amb claredat el problema, el context del projecte i els criteris que utilitzarem per revisar el resultat. Un bon prompt no és un encanteri. És una manera d’explicar un problema amb prou claredat perquè l’eina pugui treballar sobre una base útil.
Això implica saber què volem aconseguir, per a qui estem dissenyant, quina informació tenim, quins límits hem de respectar i com valorarem la resposta.
Quan tot això no està clar, la IA no resol el problema. Omple els buits. I acostuma a omplir-los amb solucions plausibles, correctes i molt semblants a les que podria donar a qualsevol altra persona. La qualitat d’un prompt no depèn de com sona. Depèn de la qualitat de les decisions que conté.

Parlar amb la IA també és una feina de disseny

Quan preparo un prompt, estic fent una part del mateix exercici que faria abans de començar una interfície.
He d’entendre el context. He de separar les necessitats reals de les suposicions. He de decidir què és prioritari i què és secundari. He de detectar contradiccions i explicar quin resultat espero obtenir. Per això, construir un bon prompt s’assembla més a preparar un briefing que a escriure una ordre. La pregunta no és només què vull que generi, sinó:

Aquest plantejament coincideix amb les recomanacions de documentació professional com la d’OpenAI sobre bones pràctiques de prompting, que insisteix a donar instruccions clares, específiques i ben estructurades. Anthropic també recomana començar definint criteris d’èxit abans d’intentar perfeccionar una instrucció: si no sabem què significa obtenir un bon resultat, difícilment podrem dirigir o avaluar el model.
En disseny UX/UI això és especialment important. Una proposta visual pot semblar convincent sense resoldre correctament la jerarquia, la navegació, l’accessibilitat o l’objectiu de conversió. La facilitat per generar una pantalla no elimina la necessitat de justificar-la.

Com construeixo un prompt de disseny UX/UI

No utilitzo sempre la mateixa plantilla. Els prompts per a disseny UX/UI s’han d’adaptar a la tasca concreta: una anàlisi d’arquitectura de continguts no necessita les mateixes instruccions que una proposta de microcopy, un prototip visual o una revisió d’accessibilitat. Per això, quan explico com escriure un bon prompt, no parteixo d’una fórmula tancada, sinó d’una estructura flexible que obliga a definir les decisions importants. Tot i això, acostumo a preparar els prompts a partir d’una estructura estable:

Aquesta estructura també és útil per als dissenyadors que comencen a incorporar la IA a la seva feina. Els prompts per a dissenyadors no s’haurien de limitar a descriure una pantalla o un estil visual: han d’aportar la informació necessària perquè l’eina entengui quina decisió estem intentant prendre i quines condicions ha de respectar.
No cal que tots els blocs siguin llargs. Han de ser prou concrets per evitar que les decisions importants quedin obertes.

On som i per què estem treballant

La IA no coneix el projecte pel fet que nosaltres hi portem setmanes pensant. Quan obro una conversa nova, intento contextualitzar i explicar el tipus de producte, el sector, l’estat del projecte i la situació des de la qual treballarem. No és el mateix analitzar una web que encara no existeix que revisar un e-commerce amb milers de productes, una arquitectura consolidada i dades reals de comportament. Un context útil podria ser:

Estem redissenyant el web d’un fabricant B2B de materials tècnics. El web actual té una arquitectura complexa, molts productes similars i usuaris amb nivells de coneixement molt diferents. No volem simplificar eliminant informació tècnica, sinó facilitar que cada perfil trobi el producte adequat.

Aquest text no diu encara quina tasca ha de dur a terme la IA. Primer situa el problema.

Què no està funcionant

«Vull millorar aquesta pàgina» és una petició massa oberta. Millorar-la podria significar fer-la més clara, més visual, més ràpida o més accessible, però també augmentar la conversió o reduir les consultes comercials. Per això intento formular el problema de manera observable.

Els usuaris no entenen la diferència entre les tres famílies de productes i accedeixen repetidament a fitxes que no corresponen a la seva aplicació.

A partir d’aquí, la IA pot proposar hipòtesis o estructures relacionades amb una dificultat concreta. Sense aquesta informació, probablement suggerirà canviar el titular, afegir icones i crear tres targetes. Potser quedarà bé. Però no sabrem si respon al problema real.

Evitar la persona genèrica

Un dels riscos més freqüents és dissenyar per a un usuari abstracte que ho entén tot, té temps, llegeix cada text i actua exactament com esperem. Quan treballo amb IA, intento descriure la situació de l’usuari, no només la seva edat o professió. També m’interessa saber què intenta aconseguir, què sap abans d’arribar, què no entén, quines objeccions pot tenir, en quin dispositiu o situació consulta la informació, què pot fer-lo abandonar o impedir que continuï el procés. Per exemple:

L’usuari principal és un responsable de compres que coneix l’aplicació final, però no domina la composició tècnica dels materials. Necessita comparar opcions i justificar internament la decisió. Consulta el web des d’un ordinador durant la jornada laboral i valora poder descarregar documentació tècnica.

Aquesta descripció condiciona l’arquitectura, el llenguatge, les comparacions, els CTA i la documentació que hauria d’aparèixer.

Objectius

Un prompt professional no hauria de confondre l’objectiu del negoci amb el de la persona usuària. El negoci pot voler aconseguir contactes comercials. L’usuari, en canvi, pot voler saber si un producte suporta una determinada temperatura.
La solució ha de connectar els dos objectius sense convertir l’experiència en una successió de formularis i botons comercials. Així que, si hi ha més d’un objectiu, els escric per separat:

Aquesta separació ajuda la IA, però sobretot m’obliga a mi a no donar per fet que les dues necessitats són la mateixa.

Treballar amb informació real

Quan existeixen continguts, dades, captures, entrevistes, analítica, requisits o documentació, els incorporo. Demanar una arquitectura sense facilitar el contingut real acostuma a produir estructures aparentment ordenades, però desconnectades del volum, la complexitat i les relacions que tindrà el projecte.
També aprofito per indicar a la IA que utilitzi únicament la informació proporcionada i que, quan falti una dada necessària, l’assenyali com a informació pendent. Li demano que no inventi funcionalitats, mètriques, testimonis ni necessitats d’usuari. Aquesta instrucció no elimina completament els errors, però deixa clar que prefereixo un buit visible abans que una resposta aparentment completa.

Dir-li què ha de fer no és suficient

Una instrucció com «analitza aquesta pàgina» descriu una acció, però no defineix l’abast ni el nivell de profunditat. Quan encarrego una tasca, intento concretar des de quina perspectiva s’ha de treballar:

Analitza la pàgina des del punt de vista de jerarquia visual, comprensió del contingut, navegació, accessibilitat i continuïtat entre l’objectiu de l’usuari i el CTA principal.

Aquest nivell de precisió és especialment important en els prompts per crear interfícies. Demanar una pantalla, una landing o un flux no és suficient si no indiquem quin problema ha de resoldre, quina informació ha de prioritzar i quin comportament esperem de cada element. La IA pot generar una composició visual coherent, però necessita criteris perquè aquesta composició també sigui funcional. També especifico què vull rebre:

Per a cada problema detectat, indica: què has observat, per què pot perjudicar l’experiència, quin principi o criteri utilitzes per valorar-ho, quina millora proposes i quin risc o inconvenient podria tenir la proposta.

Aquest últim punt és important. Si només demanem solucions, la IA tendeix a presentar-les amb molta seguretat. Quan també li demanem riscos, objeccions o alternatives, obtenim una resposta menys complaent i més fàcil de revisar.

El format també forma part del prompt

No demano una taula perquè sí, sinó quan necessito comparar informació de manera clara. Tampoc demano sempre una resposta breu, perquè el format ha de respondre a la decisió que hauré de prendre després i facilitar el treball posterior.
Segons la tasca, puc necessitar una auditoria prioritzada per impacte i esforç, diverses arquitectures alternatives amb els seus avantatges i inconvenients, un flux explicat pas a pas o una primera proposta seguida d’una autocrítica. En altres casos, em pot resultar més útil obtenir un inventari de components, separar les hipòtesis dels fets confirmats, identificar les preguntes pendents abans de continuar o rebre una resposta preparada per convertir-se en documentació.
La documentació de Google sobre l’ús de models de llenguatge en escriptura tècnica mostra precisament que una instrucció detallada i orientada al resultat evita que el model hagi d’endevinar la intenció de l’usuari. No es tracta de controlar cada frase, sinó de donar forma a la resposta perquè sigui més fàcil de revisar, comparar, documentar i compartir amb la resta de l’equip. Aquesta claredat també és essencial per aconseguir una bona comunicació entre dissenyadors i desenvolupadors.

Com aconseguir respostes més útils

Explicar el criteri, no només el resultat

En lloc d’utilitzar prompts genèrics per dissenyar webs, com ara «crea una landing minimalista», prefereixo explicar què significa la simplicitat en aquell projecte i quines decisions m’ha d’ajudar a resoldre la proposta:

Proposa una landing amb una jerarquia visual clara i un nombre reduït de decisions simultànies. La simplicitat ha de provenir de l’ordre i la priorització, no d’eliminar informació necessària.

Donar referències interpretades

Les referències són útils quan explico què m’interessa de cadascuna.

De la primera referència m’interessa la manera de presentar les categories. De la segona, el ritme visual i la relació entre text i imatge. No vull reproduir-ne la tipografia, els colors ni l’estructura exacta.

Això ajuda a separar principis, estil i contingut. Una referència sense comentaris pot ser interpretada com una petició d’imitació. Una referència explicada funciona com una decisió de direcció creativa.

Proporcionar exemples

Quan necessito un format o un nivell de qualitat concret, acostumo a incloure un exemple breu.
OpenAI i Anthropic recomanen utilitzar exemples quan la forma esperada de la resposta no és evident. Nielsen Norman Group ho resumeix amb l’estructura CARE (context, ask, rules, and examples): context, petició, regles i exemples. Un exemple no només ensenya què volem. També ajuda a mostrar què considerem una bona resposta.

Dividir problemes complexos

No acostumo a demanar en una sola instrucció que la IA investigui, defineixi l’arquitectura, redacti tots els continguts, dissenyi la interfície i generi el codi final. Quan concentrem massa decisions en un mateix prompt, qualsevol interpretació incorrecta al principi pot condicionar tota la resta del resultat. Prefereixo dividir el procés en fases que pugui revisar: primer entendre i resumir el context, després detectar la informació que falta, formular hipòtesis, proposar estructures, comparar alternatives i, només quan la direcció és clara, desenvolupar-la i revisar-ne la coherència i l’accessibilitat. Això em permet intervenir abans que una suposició errònia es converteixi en la base de tota la proposta.

Quan un prompt recurrent es pot convertir en una skill

Dividir un procés en fases també té una altra conseqüència interessant: algunes instruccions deixen de ser prompts puntuals i es converteixen en maneres de treballar que repetim projecte rere projecte.
Figma està portant aquesta idea directament al seu agent amb les Custom Skills, que permeten empaquetar workflows recurrents en conjunts reutilitzables d’instruccions. Això evita haver d’explicar cada vegada els mateixos passos, convencions o criteris i obre la porta a convertir en skill processos com una revisió d’accessibilitat, una crítica de disseny o la comprovació d’una interfície segons les regles del design system de l’equip.
Això no elimina la necessitat d’escriure bons prompts. El que canvia és que una part del context i de les instruccions pot deixar d’estar dins de cada petició i passar a formar part d’un procés reutilitzable. Per mi, aquest és un pas important: passar de saber donar una bona instrucció a saber definir una bona manera de treballar amb la IA.

Què intento no dir-li

«Fes-ho modern»

Modern no descriu una necessitat ni defineix una estètica concreta. Pot significar utilitzar una tipografia sans serif de grans dimensions, animacions, degradats, formes tridimensionals o qualsevol patró visual que el model associï amb les tendències actuals. Prefereixo explicar què ha de transmetre la interfície, quin tipus de relació ha d’establir amb el contingut i quina percepció volem generar en l’usuari.

«Fes-ho més UX»

L’UX no és una capa que es pugui afegir al final d’un disseny. Puc demanar que es redueixi la càrrega cognitiva, que l’estat del sistema sigui més visible, que es faciliti la recuperació davant d’un error o que es prioritzin millor les tasques principals. En canvi, demanar que una proposta sigui «més UX» no aporta cap criteri concret que pugui analitzar, aplicar o contrastar.

«Sorprèn-me»

De vegades deixo espai per explorar. Però sorprendre no hauria de ser l’únic objectiu d’una experiència. Si utilitzo aquesta indicació, la limito:

Explora una alternativa menys convencional, però mantén visibles les accions principals, respecta els patrons d’interacció necessaris i explica quin valor aporta cada desviació.

La innovació sense justificació pot convertir-se ràpidament en fricció.

«Actua com el millor dissenyador del món»

Assignar un rol pot ajudar a situar una perspectiva, però no substitueix el context. Dir-li que actuï com un dissenyador UX sènior no explica el projecte, l’usuari ni els criteris de qualitat. Pot influir en el vocabulari i en el to de la resposta, però no aporta la informació necessària per prendre bones decisions. Quan utilitzo un rol, intento concretar la responsabilitat que ha d’assumir: per exemple, revisar una proposta abans de presentar-la al client, diferenciar els problemes observables de les hipòtesis i no validar una decisió únicament perquè sembla visualment coherent. El valor del rol no consisteix a atribuir una autoritat fictícia a la IA, sinó a definir des de quin punt de vista ha d’analitzar la tasca.

«No t’equivoquis» o «no inventis res»

Puc indicar-ho, però no ho considero una garantia. Els models generatius construeixen respostes plausibles a partir del context disponible i poden oferir informació incorrecta o presentar una inferència com si fos un fet. Per això, en lloc de confiar només en una prohibició, prefereixo establir mecanismes de control i demanar que separi els fets proporcionats, les inferències i les recomanacions, i que indiqui quines afirmacions necessiten verificació externa. La revisió continua sent responsabilitat meva.

Un prompt no és una conversa tancada

Un dels errors que cometia al principi era intentar preparar una instrucció tan completa que no fos necessari continuar parlant amb l’eina. Ara prefereixo entendre el prompt com l’inici d’un procés. La primera resposta em serveix per comprovar què ha entès la IA, quines suposicions ha fet i com ha interpretat les prioritats. A partir d’aquí puc corregir, aprofundir o canviar de direcció.
Durant aquesta fase acostumo a demanar-li que resumeixi què ha entès abans de proposar solucions, que assenyali les contradiccions i que identifiqui la informació que necessita per evitar una resposta genèrica. També em resulta útil fer visibles les suposicions principals de la proposta, demanar una alternativa que contradigui la primera direcció o revisar la solució des de la perspectiva d’un usuari amb poc coneixement tècnic. Altres vegades li demano que valori què eliminaria per simplificar l’experiència o que no continuï desenvolupant la proposta fins que l’estructura estigui validada. Aquesta manera de treballar em permet dirigir l’eina sense delegar-hi tot el procés.

Demanar crítica és millor que demanar validació

Les eines conversacionals tendeixen a seguir la direcció que els plantegem. Si presento una idea i simplement pregunto si és bona, és fàcil obtenir una justificació convincent que reforci la meva proposta inicial. Per això intento formular preguntes que permetin qüestionar-la i que obliguin a buscar els punts febles.
Puc demanar quins motius farien que una estructura fracassés, quines necessitats d’usuari quedarien mal resoltes, quines parts depenen d’una suposició no validada o quina seria l’alternativa més simple. També puc preguntar què podria entendre malament una persona que arriba per primera vegada o quines decisions visuals encara no tenen una justificació funcional. No busco que la IA tingui l’última paraula, sinó que m’ajudi a ampliar el nombre i la qualitat de les preguntes que soc capaç de plantejar-me.

No tots els errors es resolen millorant el prompt

De vegades una resposta no funciona perquè la instrucció és ambigua, però també pot fallar perquè falta informació, perquè el model no és adequat per a aquella tasca o perquè estem intentant automatitzar una decisió que necessita investigació real. La documentació d’Anthropic adverteix que no tots els problemes de rendiment es resolen mitjançant el prompt engineering. Abans de reescriure indefinidament una instrucció, convé comprovar si disposem de bons criteris d’èxit, proves i dades suficients.
Si vull saber per què els usuaris abandonen un procés de compra, puc utilitzar la IA per analitzar entrevistes, agrupar incidències o formular hipòtesis. El que no puc fer és substituir aquestes entrevistes per una descripció inventada d’un usuari i esperar obtenir una conclusió fiable. Un prompt pot ordenar el coneixement disponible. No pot fabricar l’evidència que no hem recollit.

Provar un prompt també és fer recerca

No dono per bo un prompt perquè hagi funcionat una vegada. Quan una instrucció formarà part d’un procés recurrent, intento provar-la amb situacions diferents i observar en quins punts varia el resultat, quines ambigüitats apareixen i quines parts depenen massa de la interpretació del model.
Nielsen Norman Group defensa que les eines d’IA s’han de provar amb escenaris reals de disseny i que els resultats s’han d’avaluar amb una metodologia explícita, en lloc de basar-se únicament en demostracions atractives. En un entorn professional això significa comprovar com respon el prompt en un cas senzill i ben documentat, però també davant d’informació incompleta, requisits contradictoris, un volum de contingut superior a l’habitual, necessitats específiques d’accessibilitat o dades poc fiables. Aquestes proves permeten descobrir si la instrucció és realment útil o si només funciona en el cas ideal per al qual l’hem preparada.

Els prompts també es poden convertir en part del sistema de treball

Aquest canvi és especialment interessant quan treballem en equip. El 13 d’agost de 2026, Figma va anunciar a les seves Release Notes que les Agent Skills s’obrien a la Community, amb més de 50 skills orientades a diferents processos i la possibilitat de crear-ne de noves a partir del context d’un fitxer.
Això permet imaginar processos en què una part dels criteris que fins ara vivien en documentació, reunions o prompts personals es poden convertir en recursos compartits. Una revisió de components, una comprovació abans del handoff o unes directrius específiques del design system podrien deixar de dependre exclusivament que cada dissenyador recordi i reescrigui totes les instruccions.
Però automatitzar un criteri no el converteix automàticament en un bon criteri. Si una skill parteix d’un procés mal definit, simplement aconseguirem repetir-lo amb més rapidesa. La responsabilitat continua estant en decidir què val la pena sistematitzar, quines regles ha de seguir i quan necessitem revisar el resultat.

Una estructura pràctica per començar

Quan necessito preparar una primera versió, utilitzo una estructura com aquesta:

No és una fórmula obligatòria. És un punt de partida per no oblidar les decisions que més condicionen el resultat.

Exemple: d’un prompt genèric a una instrucció útil

Prompt massa obert

Dissenya una home moderna per a una marca de bicicletes elèctriques.

És probable que el resultat incorpori una imatge gran, un titular emocional, targetes de producte i diversos CTA. Pot semblar una web real, però la IA haurà decidit gairebé tot: públic, posicionament, arquitectura, contingut, estil i prioritat comercial.

Prompt treballat

Estem redissenyant la pàgina d’inici d’una marca europea de bicicletes elèctriques urbanes. La marca vol transmetre lleugeresa, tecnologia accessible i confiança, evitant una estètica agressiva o excessivament esportiva.

L’usuari principal compara models i necessita identificar ràpidament quina bicicleta encaixa amb la seva alçada, el tipus de trajecte i la seva experiència de conducció. La dificultat actual és que els models semblen massa similars i les diferències tècniques no ajuden a decidir.

Proposa l’arquitectura de continguts de la home. Prioritza l’orientació entre models abans de mostrar totes les especificacions. Inclou els continguts necessaris, l’objectiu de cada secció i la transició entre una secció i la següent.

No redactis encara el copy final ni defineixis l’estil visual. No inventis característiques de producte. Quan necessitis una dada que no està disponible, marca-la entre claudàtors.

Presenta dues alternatives:

1. Una estructura guiada per necessitats d’usuari.
2. Una estructura guiada per famílies de producte.

Compara els avantatges, riscos i tipus d’usuari que resol millor cada alternativa. Acaba recomanant quina opció investigaries primer, però no la presentis com una decisió validada.

Aquest prompt no garanteix una bona arquitectura. Però fa visibles les decisions, limita les invencions i produeix un resultat que puc analitzar.

La IA respon. Jo continuo sent responsable

Puc millorar molt la manera de parlar amb una intel·ligència artificial. Puc aportar més context, exemples, restriccions i criteris. Puc dividir una tasca, revisar-ne les suposicions i provar el prompt amb situacions diferents. Tot això redueix l’ambigüitat, però no elimina la necessitat de pensar.
Com a dissenyadora UX/UI, continuo sent responsable de comprovar si la proposta respon a una necessitat real, si deixa fora algun perfil, si respecta l’accessibilitat, si simplifica l’experiència i si encaixa amb els objectius del projecte. La IA no coneix automàticament les converses amb el client, els matisos de la marca, les limitacions internes ni les contradiccions que hem anat descobrint durant el procés. Només pot treballar amb allò que li proporcionem i amb els patrons que ha après.
Per això no considero que saber escriure prompts sigui una competència separada del disseny. És una extensió de capacitats que ja necessitàvem: investigar, sintetitzar, formular problemes, explicar decisions, donar feedback i reconèixer quan una proposta no és prou bona.
Un bon prompt no resol per si sol un projecte de disseny. És una part més d’un procés en què continuem havent d’entendre el problema, observar l’usuari i valorar críticament cada proposta. Aquesta és també la idea que desenvolupem quan parlem de com integrar la IA en el procés de disseny UX/UI sense perdre creativitat, criteri ni visió d’usuari.

Quan la IA també pot utilitzar les nostres eines

Els prompts tampoc estan quedant limitats a una conversa amb un model. Les eines de disseny comencen a connectar els agents amb l’entorn real de treball.
Figma explicava l’11 d’agost de 2026 a les seves Release Notes que el seu servidor MCP ampliava la integració amb agents externs perquè poguessin executar eines creades amb Figma Weave des de clients com ChatGPT, Claude o Cursor. Això permet que l’agent identifiqui l’eina adequada, la faci servir i retorni el resultat mantenint el context de la conversa.
Això pot reduir una fricció molt habitual: haver d’anar traslladant manualment el context entre la conversa amb la IA, les referències i l’eina de disseny. Però també introdueix una diferència important. Quan la IA deixa de limitar-se a proposar i pot començar a executar accions, definir bé les restriccions, els punts de revisió i què pot fer sense la nostra intervenció es torna encara més rellevant.
Un bon prompt ja no només ha d’explicar què volem obtenir. Cada vegada més, també haurà de deixar clar què pot fer l’agent, amb quines eines i fins on pot arribar abans de tornar a nosaltres.

Quan parar

No utilitzo la intel·ligència artificial en totes les fases ni per a totes les decisions. De vegades necessito observar sense generar res, llegir una entrevista sense resumir-la immediatament, fer esbossos que no parteixin d’una proposta calculada o provar una idea sense convertir-la encara en una solució coherent.
També hi ha moments en què la velocitat de la IA pot jugar en contra. Quan produeix deu alternatives en pocs segons, és fàcil confondre varietat amb exploració. Moltes d’aquestes alternatives poden compartir la mateixa lògica i limitar-se a modificar-ne la forma. Explorar no és acumular respostes, sinó comprendre millor el problema.
Per això, abans d’escriure un prompt, intento preguntar-me si la IA és realment l’eina que necessito. Potser em convé parlar amb un usuari, revisar les dades, observar un procés o deixar reposar una idea. Saber dirigir la IA és important, però saber quan no utilitzar-la també forma part del criteri professional.

No necessitem prompts perfectes. Necessitem processos revisables

La conversa sobre prompting sovint se centra en com obtenir el millor resultat possible amb una única instrucció. A mi m’interessa més construir processos en què una resposta mediocre es pugui detectar, qüestionar i millorar abans de convertir-se en una decisió.

Un bon prompt ajuda, però no treballa sol. Necessita informació fiable, objectius clars, criteris de qualitat, contrast, proves i una persona que assumeixi la responsabilitat final.
Amb el temps, probablement deixarem de parlar tant de prompts. Les eines entendran millor el context, treballaran amb més informació i estaran més integrades en els nostres entorns. Però la necessitat d’explicar bé què volem aconseguir no desapareixerà. Continuarem havent de decidir quin problema estem resolent, per a qui ho fem, què considerem una bona experiència i quins límits no volem traspassar.

Aquesta evolució cap a skills, agents i eines connectades reforça encara més aquesta idea. La mateixa documentació de Custom Skills de Figma mostra com els workflows poden deixar de dependre d’una instrucció puntual i passar a formar part d’un sistema reutilitzable, mentre que les actualitzacions recents de Figma apunten cap a agents cada vegada més integrats amb el canvas i amb altres eines.

Probablement el futur no consistirà a escriure prompts cada vegada més llargs, sinó a combinar context, instruccions, processos reutilitzables, eines i criteris de revisió. El prompt continuarà sent una manera de comunicar una intenció, però deixarà de carregar tot el pes del procés.

Per això crec que saber treballar amb IA en disseny anirà cada vegada menys de trobar la formulació perfecta i més de saber construir el sistema adequat al seu voltant: quina informació necessita, quins criteris ha de respectar, què podem automatitzar i en quins moments necessitem intervenir.

La IA pot interpretar les nostres instruccions. El criteri per escriure-les, revisar-les i saber quan no són suficients continua sent nostre.