Hi ha una frase que comença a circular amb força: la interfície d’usuari va cap a la mort.
L’argument sembla evident. Si puc dir a l’ordinador “revisa aquests correus, creua les reclamacions amb el CRM, prepara una resposta per a cada client i avisa’m abans d’enviar”, per què hauria d’obrir quatre aplicacions, aprendre’n els menús i executar cada pas amb el ratolí?
La conclusió, però, confon dues coses diferents: que disminueixi la interacció manual i que desaparegui l’experiència d’usuari.
No estem deixant de dissenyar interfícies. Estem canviant què governa la interfície.
Durant dècades, els productes digitals han assumit que una persona havia de traduir la seva intenció en una seqüència d’accions: obrir, cercar, seleccionar, omplir, comparar, confirmar. Els agents alteren aquesta relació perquè permeten expressar un resultat i delegar una part del recorregut. Però com més feina executa el sistema, més necessitem comprendre’n l’abast, les decisions operatives, els permisos, l’evidència i la capacitat de recuperació.
La interfície deixa de ser únicament el lloc on fem la feina. Es converteix en el lloc on definim, autoritzem, supervisem, verifiquem i, quan cal, desfem la feina que realitza un agent.
En resum
L’UX/UI no mor. Perd el monopoli de l’execució directa.
La veu serà una entrada excel·lent per expressar intenció, interrompre i coordinar. La pantalla continuarà sent superior per comparar opcions, revisar grans volums d’evidència, editar detalls, detectar anomalies i comprendre conseqüències.
El futur més probable no és una experiència voice-only, sinó una arquitectura híbrida:
- Voice-first quan parlar sigui la manera més ràpida de declarar un objectiu, afegir context o canviar de direcció.
- Visual-first quan verificar, comparar o autoritzar exigeixi precisió.
- API-first per a l’agent quan existeixi una eina estructurada i fiable.
- GUI o intervenció humana quan la capacitat no estigui disponible, el context sigui ambigu o el risc exigeixi control directe.
I sí: dissenyarem UX per a agents. Però això no significa dibuixar pantalles que “agradin” a una IA. Significa dissenyar una superfície semàntica que l’agent pugui descobrir i utilitzar de manera fiable: eines amb noms inequívocs, paràmetres tipats, resultats estructurats, permisos mínims, errors accionables, estats consultables i operacions reversibles.
El lliurable estratègic ja no serà només un wireframe o un flux. Serà un contracte de delegació.
La veu canvia el punt d’entrada, no elimina la interfície
A 5 d’agost de 2026, la documentació oficial d’OpenAI descriu una experiència en què ChatGPT Voice es pot utilitzar amb Work i Codex per iniciar tasques, comprovar-ne el progrés, prioritzar, interrompre, redirigir i coordinar diversos agents des d’una conversa. GPT-Live hi afegeix una arquitectura full-duplex: pot escoltar i parlar alhora i mantenir la conversa mentre delega feina més complexa.
Això redueix dràsticament el cost d’expressar intenció. Ja no cal saber per endavant on viu cada funció. Podem dir en llenguatge natural què volem aconseguir.
Però parlar no equival a concedir control il·limitat.
Veu utilitza les eines i els permisos disponibles en l’experiència seleccionada. El context de l’ordinador pot requerir accés al micròfon, gravació de pantalla i àudio, accessibilitat, fitxers locals o aplicacions concretes. Un workspace pot activar o restringir funcions. Una eina pot llegir dades sense poder-les modificar, crear esborranys sense poder-los enviar o preparar un canvi sense poder-lo desplegar.
La veu fa que la interacció sembli contínua. Els permisos, els límits i els estats continuen sent discrets.
Per això una bona experiència ha de separar, verbalment i visualment, almenys tres missatges:
“T’he sentit.”
“He acceptat la nova instrucció.”
“La instrucció ja s’ha aplicat a les tasques actives.”
No són equivalents. En un sistema amb diverses tasques en paral·lel, una correcció pot afectar només una branca, arribar massa tard per a una acció ja executada o quedar pendent d’aprovació. La fluïdesa conversacional no pot ocultar aquesta realitat operativa.
L’agent és un androide sense cos
La metàfora més útil no és “un chatbot més intel·ligent”. És un androide sense cos.
Pot parlar amb nosaltres, escoltar mentre pensem, observar parts de l’entorn digital i utilitzar les “mans” que li presten les eines, APIs, connectors, terminals i permisos del sistema. També pot mantenir context, coordinar subtasques i reaccionar a esdeveniments.
| Capacitat metafòrica | Implementació digital |
|---|---|
| Veu | Conversa speech-to-speech, transcripció i síntesi |
| Orelles | Micròfon, detecció d’activitat i àudio compartit |
| Ulls | Captures, navegador, fitxers i dades estructurades |
| Mans | APIs, eines MCP, terminal, connectors i automatitzacions |
| Memòria | Context de conversa, fitxers i instruccions autoritzades |
| Sistema nerviós | Orquestració, esdeveniments, estats i crides a eines |
| Consciència dels límits | Policies, sandbox, permisos, schemas i checkpoints humans |
El punt decisiu és que no té mans universals. Li prestem mans específiques.
Pot llegir correu si existeix una eina autoritzada per llegir-lo. Pot redactar si l’eina permet crear esborranys. Només pot enviar si hi ha una acció d’enviament i l’autoritat concedida inclou aquell verb, aquell destinatari i aquell volum. Pot analitzar transaccions sense tenir permís per cancel·lar una subscripció. Pot preparar un rollback sense poder-lo executar en producció.
Cada verb addicional — llegir, modificar, publicar, enviar, esborrar, pagar — augmenta el radi d’impacte.
Això explica per què la interfície no desapareix. Quan el sistema només suggereix, el cost d’un error pot ser una mala resposta. Quan actua, l’error es pot propagar fora del xat. El disseny ha de fer visible la diferència entre capacitat i autoritat.
Del disseny de pantalles al disseny de col·laboració
L’UX tradicional organitza possibilitats: menús, botons, jerarquies i recorreguts. L’UX agèntica ha d’organitzar responsabilitats.
Abans dissenyàvem una acció: “Enviar”. Ara hem de dissenyar una delegació completa:
“Identifica els clients afectats, redacta una resposta utilitzant aquesta política, no prometis compensacions superiors a 100 euros, crea esborranys però no enviïs res i avisa’m quan trobis un cas ambigu.”
El producte ha de convertir aquesta frase en un estat operatiu verificable. Ha de distingir:
- El resultat buscat.
- Les fonts autoritzades i les excloses.
- Les accions permeses i prohibides.
- Els límits de diners, volum, temps i abast.
- Els criteris d’èxit.
- Els punts que requereixen intervenció humana.
- L’evidència que demostrarà que la feina s’ha fet bé.
- La manera de corregir o revertir el resultat.
Això canvia la unitat mínima del disseny. Ja no és només el clic. És la relació de treball entre una persona, un o diversos agents i els sistemes sobre els quals actuen.
Magentic-UI explora aquesta relació mitjançant coplanificació, cotreball, multitasca, guardes d’acció i memòria. La idea important no és una interfície concreta, sinó que la col·laboració admet graus: supervisió distant, control proper, resolució conjunta o presa de control completa. L’usuari ha de poder canviar de nivell sense reiniciar tota la tasca.
Un pla, per exemple, no hauria de ser una llista decorativa generada pel model. Ha de ser un objecte manipulable: reordenar passos, cancel·lar una branca, canviar una font, reduir l’abast o afegir un checkpoint obligatori.
Dissenyarem UX/UI per a agents?
Sí, però convé separar dues disciplines que compartiran el mateix producte.
| UX per a persones que col·laboren amb agents | Experiència per a agents que utilitzen sistemes |
|---|---|
| Llenguatge comprensible | Noms d’eines inequívocs |
| Resum abans del detall | Schemas estrictes d’entrada i sortida |
| Comparació visual | Dades estructurades i tipades |
| Explicació contextual | Descripcions operatives precises |
| Confirmació proporcional al risc | Senyals d’impacte i reversibilitat |
| Pausa, redirecció i presa de control | Estats de tasca consultables |
| Evidència i procedència | Identificadors estables i referències |
| Undo i recuperació | Operacions idempotents o compensatòries |
| Accessibilitat multimodal | Errors llegibles per màquina |
| Responsabilitat organitzativa | Logs i traces auditables |
Per a una persona, una capacitat es pot representar amb text, una targeta, un botó, una comparació o una conversa. Per a un agent, la mateixa capacitat necessita una representació estructurada.
El Model Context Protocol formalitza una part d’aquesta segona superfície. Una eina pot declarar un nom, una descripció, un inputSchema, un outputSchema i resultats estructurats. Això permet que un agent descobreixi què existeix, validi paràmetres i rebi una sortida sense dependre d’interpretar una pantalla.
Però un protocol no substitueix el disseny. Una funció anomenada processItem continua sent ambigua. Una eina anomenada create_refund_draft, que exigeix order_id, reason, maximum_amount i requires_human_approval, comunica molt millor la intenció, els límits i el risc.
La nova responsabilitat de producte és dissenyar la superfície semàntica de les eines.
La recerca AXIS ofereix un senyal útil: les seqüències llargues de clics visuals poden introduir latència i menys fiabilitat, mentre que un enfocament API-first pot completar tasques amb menys passos. Els resultats es van obtenir a Microsoft Word i no s’han de generalitzar sense cura, però il·lustren una direcció clara: les aplicacions preparades per a agents necessitaran capacitats estructurades, a més de pantalles per a persones.
El nou lliurable: un contracte de delegació
Un contracte de delegació no és necessàriament un document legal ni una única pantalla. És el conjunt observable de condicions que determina quin resultat es persegueix, què pot fer l’agent i com se’n comprovarà la feina.
Es pot organitzar en vuit capes.
| Capa | Pregunta de disseny | Affordance necessària |
|---|---|---|
| Intenció | Quin resultat ha entès el sistema? | Resum editable: “He entès que…” |
| Context | Quines fonts, períodes i exclusions utilitzarà? | Panell de fonts i actualitat |
| Capacitat | Quines eines existeixen i estan connectades? | Inventari de capacitats i estat |
| Autoritat | Què pot llegir, modificar, enviar o esborrar? | Permisos per verb, objecte i impacte |
| Pla | Com es descompon la tasca i on es decideix? | Timeline editable i checkpoints |
| Execució | Què s’està executant, què està bloquejat i què ha canviat? | Estat observable, pausa i takeover |
| Evidència | Què demostra que el resultat és correcte? | Diffs, fonts, tests i procedència |
| Recuperació | Com es corregeix, reverteix o escala? | Undo, rollback i accions compensatòries |
Intenció
“Neteja’m la safata d’entrada” és ambigu. “Arxiva newsletters de fa més de 90 dies, etiqueta factures i no esborris missatges” defineix un resultat i uns límits. Abans d’iniciar una tasca àmplia, la interpretació s’ha de poder editar.
Context
L’usuari necessita saber quines dades entren i quines queden fora. Una anàlisi de comptes ha d’indicar bancs, períodes, monedes i actualitat. “No he trobat la dada” no és el mateix que “no tinc permís”, “la font no està connectada” o “l’eina ha fallat”.
Capacitat i autoritat
Tenir una eina no implica permís per utilitzar totes les seves accions. Llegir no és modificar. Modificar no és publicar. Publicar no és esborrar. L’autoritat s’hauria de concedir per verb, objecte, període, volum i nivell d’impacte.
Pla i execució
El pla ha d’admetre canvis sense reiniciar la feina. L’execució ha de mostrar quines branques continuen actives, quina instrucció utilitza cadascuna i quines accions ja no es poden desfer.
Evidència
Una resposta convincent no és suficient. L’agent ha de vincular afirmacions i canvis amb fonts, operacions, diffs, tests o captures. Codex ja mostra part d’aquest patró quan retorna canvis revisables, resultats de terminal i evidència de validació.
Recuperació
Cada acció amb efectes hauria de declarar si és reversible, parcialment reversible o irreversible. Quan no hi ha undo tècnic, el producte necessita una acció compensatòria: restaurar una versió, enviar una correcció, crear un tiquet o escalar a una persona responsable.
Patrons concrets per a una interfície agèntica
La teoria esdevé útil quan es tradueix en components de producte.
Capçalera de missió
Ha de mostrar l’objectiu actual, l’agent responsable, l’entorn d’execució, el temps transcorregut, l’estat i el nivell d’autoritat. Estats com preparant, esperant aprovació, executant, bloquejat, verificant, completat, fallit i revertit són més informatius que una animació genèrica de “pensant”.
Resum del resultat
Un tancament útil hauria de respondre sis preguntes:
| Camp | Contingut |
|---|---|
| Resultat | Què s’ha aconseguit |
| Abast | Quines fonts, comptes o fitxers s’han processat |
| Canvis | Què s’ha modificat fora del xat |
| Excepcions | Què ha quedat incomplet i per què |
| Riscos | Quins supòsits o incerteses es mantenen |
| Acció següent | Què convé fer ara |
Timeline d’activitat
No ha d’exposar raonaments privats ni una transcripció interminable. Ha de registrar accions observables: eina utilitzada, objecte afectat, hora, resultat, evidència generada i reversibilitat.
Targeta d’aprovació
“Necessito permís” és insuficient. L’aprovació ha de descriure una acció concreta:
Acció: enviar 14 respostes
Destinataris: llista revisable
Font del contingut: política de suport v3.2
Dades incloses: nom, comanda i proposta de compensació
Impacte: comunicació externa
Reversibilitat: irreversible després de l’enviament
Alternatives: desar esborranys / enviar 2 casos de prova
Aprovació vàlida durant: 10 minuts
Procedència i incertesa
Cada afirmació o gràfic important ha d’enllaçar amb la font, la data, l’eina i la transformació. Un “92% de confiança” aïllat diu ben poc. És millor explicar-ne la causa: “falten dos extractes”, “tres documents contradiuen la política vigent” o “la classificació utilitza una coincidència aproximada”.
Centre de recuperació
El botó no hauria de dir només “Desfer”. Hauria d’explicar què restaurarà i quin serà el radi d’impacte: “Restaurar 18 etiquetes de correu a l’estat de les 10:42”.
La seguretat també és una decisió d’UX
Un agent que llegeix pàgines, correus o documents pot trobar instruccions malicioses incrustades en aquests materials. Si, a més, té eines amb permisos amplis, una entrada no fiable es pot convertir en una acció real.
OWASP utilitza el correu com a exemple d’agència excessiva: un assistent que només necessita llegir missatges rep també capacitat d’enviament, i una injecció indirecta intenta fer-li reenviar informació sensible. La mitigació no consisteix només a escriure un prompt millor. Consisteix a eliminar funcions innecessàries, utilitzar credencials de només lectura, exigir revisió abans de l’enviament i limitar el volum.
La resposta d’UX tampoc no pot ser demanar confirmació per a cada microacció. Això genera fatiga i ensenya a aprovar sense llegir. El disseny ha de combinar:
- Privilegi mínim per defecte.
- Aprovacions en moments d’impacte significatiu.
- Separació entre lectura, escriptura, publicació i esborrament.
- Límits de volum, diners, temps i destinataris.
- Estat visible i capacitat d’aturada.
- Evidència posterior i registre auditable.
- Recuperació tècnica o compensatòria.
La governança travessa tot el producte. El NIST AI RMF organitza la gestió del risc al voltant de Govern, Map, Measure i Manage. Per al disseny, això implica definir rols, responsables, criteris d’avaluació i procediments d’incident abans que una demostració es converteixi en infraestructura crítica.
Quina feina disminuirà i quina creixerà
La part incòmoda és que no totes les tasques actuals conservaran el mateix valor.
És raonable esperar menys demanda per a feina centrada exclusivament a produir moltes variacions de pantalles, documentar recorreguts deterministes o convertir requisits estables en components previsibles. Els agents ja poden accelerar una part d’aquesta producció i el llenguatge natural reduirà alguns passos intermedis.
Però creixeran altres responsabilitats:
- Modelar com una intenció oberta es converteix en un objectiu verificable.
- Dissenyar transicions entre autonomia, col·laboració i presa de control humana.
- Definir permisos i aprovacions proporcionals al risc.
- Dissenyar estats per a tasques paral·leles i de llarga durada.
- Crear eines i APIs llegibles per agents.
- Representar procedència, incertesa i cobertura d’evidència.
- Dissenyar undo, rollback i accions compensatòries.
- Avaluar comportament, no només pantalles.
- Treballar amb seguretat, legal, operacions i negoci en governança.
- Mantenir l’accessibilitat entre veu, text, imatge, teclat i control directe.
El dissenyador deixa de ser només qui ordena controls en una superfície. Passa a participar en la definició de qui pot fer què, en nom de qui, amb quina informació, sota quins límits i amb quina responsabilitat.
Què hauria de fer avui un equip de disseny
No cal esperar que tota l’organització tingui agents autònoms. Es pot començar amb sis preguntes aplicades a qualsevol flux existent:
- Quin resultat intenta aconseguir la persona? No quin botó prem, sinó quin canvi vol produir al món.
- Quines parts es poden delegar de manera segura? Separar investigació, preparació, modificació i publicació.
- Quina evidència permetria verificar el resultat? Fonts, diffs, tests, mostres o mètriques.
- On ha d’intervenir una persona? Ambigüitat, impacte extern, diners, dades sensibles o irreversibilitat.
- Com es recupera el sistema d’un error? Undo, snapshot, rollback o acció compensatòria.
- Com s’exposa la mateixa capacitat a persones i agents? Una representació comprensible i una d’estructurada.
També convé canviar els lliurables. Al costat del journey map o del prototip, un equip hauria de documentar:
- Matriu d’autoritat per acció.
- Model d’estats i esdeveniments.
- Inventari d’eines.
- Schemas i errors esperats.
- Checkpoints humans.
- Pla d’evidència i procedència.
- Estratègia de recuperació.
- Mètriques de qualitat de la col·laboració.
La pròxima gran interfície no serà una pantalla
La interfície gràfica no desapareix. Deixa de ser el centre exclusiu de l’experiència.
Continuarem necessitant botons, formularis, taules, gràfics i editors. Però la seva funció canvia. En molts casos ja no seran l’instrument amb què executem cada pas, sinó la superfície on comprenem la missió, delimitem l’autoritat, observem el progrés, revisem l’evidència i decidim si acceptem, corregim o revertim.
La veu fa visible aquest canvi perquè ens permet expressar intenció sense recórrer manualment el programari. Codex i altres agents el converteixen en una realitat operativa perquè poden utilitzar eines, actuar en paral·lel i produir canvis revisables. Aquesta combinació no mata l’UX/UI. L’obliga a madurar.
Passem de dissenyar instruments que una persona opera directament a dissenyar relacions de treball amb un androide sense cos: un sistema que escolta, observa, executa, s’equivoca i necessita límits comprensibles.
La pròxima gran interfície no serà només una pantalla.
Serà un contracte.
Preguntes freqüents
- La veu substituirà les interfícies gràfiques?
- No. La veu redueix el cost d’expressar intenció, iniciar feina i interrompre una tasca. Les interfícies visuals continuen sent millors per comparar alternatives, revisar evidència, editar amb precisió, comprendre estats complexos i confirmar accions de risc.
- Hi haurà menys feina per als dissenyadors UX/UI?
- Probablement hi haurà menys feina centrada exclusivament a produir variacions de pantalles i fluxos deterministes. Creixerà la feina sobre models d’interacció, permisos, observabilitat, comportament, avaluació, accessibilitat multimodal, recuperació i governança.
- Què significa dissenyar UX per a agents?
- Significa crear capacitats que un agent pugui descobrir i invocar de manera fiable: noms d’eines clars, schemas estrictes, resultats estructurats, permisos mínims, errors accionables, estats consultables i operacions reversibles.
- Què és un contracte de delegació?
- És l’especificació observable que connecta el resultat demanat amb el context autoritzat, les eines disponibles, els límits d’autoritat, el pla, els checkpoints, l’evidència, la responsabilitat i les opcions de recuperació.
- Quan ha de demanar aprovació un agent?
- Quan una acció produeix un efecte extern significatiu, exposa dades sensibles, augmenta privilegis, implica diners, afecta tercers, supera l’abast concedit o és difícil de revertir. L’aprovació ha de ser proporcional al risc, no una interrupció per a cada microacció.
- Com es mesura una bona experiència humà-agent?
- A més de l’èxit i la velocitat, convé mesurar correccions necessàries, intervencions evitables, temps per detectar errors, cobertura d’evidència, compliment de l’abast, qualitat de recuperació, confiança calibrada i percentatge d’accions reversibles.