Dissenyar el permís

Durant anys, gran part del disseny d’interacció ha partit d’una premissa força simple: l’usuari decideix i el sistema respon.

Fem clic, triem una opció, confirmem una acció, enviem un formulari. Fins i tot quan el sistema automatitza una part del procés, acostuma a haver-hi un moment clar en què la persona inicia, valida o executa allò que està passant.

La intel·ligència artificial està començant a canviar aquesta relació.

Un sistema ja no s’ha de limitar a esperar una instrucció concreta. Pot interpretar una intenció, anticipar el pas següent, preparar una acció i fins i tot executar-la sense que l’usuari intervingui de nou a cada moment.

I aquí apareix una nova pregunta de disseny.

Ja no n’hi ha prou de preguntar-nos què pot fer tècnicament una IA. També hem de decidir què hauria de poder fer sense nosaltres.

Perquè capacitat i permís no són el mateix.

Que un sistema pugui redactar un correu no vol dir que l’hagi d’enviar. Que pugui reorganitzar una agenda no vol dir que hagi de moure qualsevol reunió. Que pugui trobar una alternativa més barata no vol dir que hagi de fer automàticament una compra.

En cadascun d’aquests casos, la tecnologia pot ser capaç de completar l’acció. El que canvia és el grau d’autonomia que estem disposats a concedir-li.

Per això, dissenyar productes amb IA implica començar a treballar amb una frontera que abans era molt més senzilla: fins on pot avançar el sistema abans de retornar la decisió a la persona.

Aquesta frontera no serà igual per a totes les accions, ni per a tots els usuaris, ni per a tots els contextos.

I probablement una de les decisions de disseny més importants dels pròxims anys no serà quines funcions incorporem a la IA, sinó quines pot executar sense tornar-nos-ho a preguntar.

Suggerir, preparar, confirmar i actuar són permisos diferents

Quan parlem d’autonomia en sistemes amb intel·ligència artificial, és fàcil caure en una simplificació: o la persona manté el control o la màquina actua de manera automàtica.

Però entre tots dos extrems hi ha moltes possibilitats.

Una IA pot limitar-se a suggerir una acció, preparar el pas següent i deixar-lo a punt, demanar una confirmació abans d’executar-lo o actuar directament quan el context ho permet.

La diferència entre una opció i una altra no rau necessàriament en la capacitat tècnica del sistema, sinó en el permís que té per avançar.

Un assistent pot recomanar diversos horaris lliures per a una reunió. També pot redactar la invitació i seleccionar els assistents. Pot deixar-ho tot preparat i demanar una confirmació final o, si ja existeixen unes condicions definides, enviar directament la convocatòria.

La tecnologia pot ser pràcticament la mateixa. El que canvia és el punt en què la persona deixa d’intervenir.

I aquest punt no ha de ser fix.

La mateixa IA pot actuar amb molta autonomia en una tasca rutinària i, pocs segons després, demanar confirmació per a una altra acció amb conseqüències més grans. Pot reorganitzar una llista sense preguntar, preparar una resposta sense enviar-la i aturar-se abans de fer una compra.

Per això, parlar de sistemes “autònoms” com una categoria única pot resultar enganyós.

El més important no és decidir si una IA és autònoma o no, sinó quin grau d’autonomia té en cada acció concreta.

Dissenyar aquesta diferència permet que l’automatització no sigui una propietat general del producte, sinó una decisió d’interacció que es pot adaptar al context, al risc i a les expectatives de l’usuari.

El permís hauria de dependre de l’acció, no de l’agent

Parlar d’una IA com a “autònoma” pot resultar útil per descriure una capacitat general, però és una categoria massa àmplia quan arriba el moment de dissenyar l’experiència.

Un mateix sistema pot comportar-se de maneres molt diferents segons el que estigui fent.

Pot reorganitzar automàticament una llista, preparar una resposta que encara necessita revisió, suggerir una alternativa o aturar-se abans d’executar una acció amb conseqüències més grans.

Per això, potser la pregunta no hauria de ser quin control té l’agent en termes generals, sinó quin permís té per a cada acció concreta.

Aquesta diferència és important perquè no totes les accions tenen el mateix pes.

Canviar l’ordre d’uns elements, modificar una reserva, enviar un missatge o fer un pagament poden formar part del mateix flux, però no haurien de compartir necessàriament el mateix nivell d’autonomia.

Dissenyar des de l’acció obliga a mirar amb més detall què passa en cada moment: què canvia, qui se’n pot veure afectat, quines conseqüències pot tenir i quin marge hi ha per corregir-ho després.

També evita una idea perillosa: que, un cop concedida una certa autonomia al sistema, aquesta autonomia s’hagi d’aplicar igual a tot el que fa.

El permís pot ser granular.

Una persona pot sentir-se còmoda deixant que la IA resolgui determinades tasques sense intervenció i, alhora, voler mantenir la decisió final en d’altres.

Per això, la unitat real de disseny no és l’agent en abstracte, sinó l’acció, el seu context i les seves conseqüències.

Quan introduir fricció

Durant anys, una part important del disseny digital ha intentat reduir la fricció: menys passos, menys clics, menys interrupcions.

Però quan un sistema pot actuar per nosaltres, eliminar la fricció no sempre millora l’experiència.

De vegades, aturar-se forma part del bon disseny.

La qüestió no és afegir confirmacions per precaució, sinó entendre quin tipus d’acció està a punt de dur-se a terme i quines conseqüències pot tenir.

Hi ha accions en què el cost d’equivocar-se és pràcticament irrellevant. En d’altres, una decisió pot implicar diners, comprometre una altra persona, modificar informació important o ser difícil de desfer.

També importa la reversibilitat.

No és el mateix una acció que es pot corregir immediatament que una altra els efectes de la qual són permanents o molt difícils de revertir. Com més petita sigui la possibilitat de tornar enrere, més sentit té que el sistema redueixi la seva autonomia o sol·liciti una intervenció explícita.

Un altre factor important és si l’acció afecta únicament l’usuari o també tercers.

Reorganitzar informació personal pot requerir molt poca supervisió. Enviar un missatge, cancel·lar una reunió o acceptar unes condicions en nom d’algú introdueix conseqüències que van més enllà de la mateixa interfície.

I hi ha el context.

Una decisió que era vàlida quan es va iniciar una tasca pot deixar de ser-ho uns minuts després. Pot canviar un preu, desaparèixer una disponibilitat, modificar-se un destinatari o aparèixer informació nova que alteri la decisió.

Per això, dissenyar autonomia també vol dir decidir quan val la pena interrompre el flux.

No tota fricció és un obstacle. En determinats moments pot ser precisament allò que permet a l’usuari entendre què està a punt de passar, revisar una decisió o conservar el control quan realment importa.

La bona experiència no serà sempre la que pregunti menys, sinó la que sàpiga quan té sentit preguntar.

Del “ho confirmes?” al permís condicionat

Demanar confirmació abans de cada acció pot ser una manera senzilla de mantenir el control, però també té un límit.

Si un sistema pregunta constantment, la confirmació deixa de ser una decisió conscient i es pot convertir en un gest automàtic.

En molts casos, una alternativa més útil és permetre que l’usuari defineixi per endavant les condicions sota les quals la IA pot actuar.

No es tracta de concedir un permís general, sinó d’establir límits concrets.

“Fes-ho si costa menys de 50 euros.”

“Reserva només si es pot cancel·lar.”

“Respon automàticament únicament a aquest tipus de missatges.”

“Reorganitza la meva agenda, però no moguis reunions amb clients.”

Aquest tipus d’interacció canvia de manera important el paper de la interfície.

Ja no dissenyem únicament el moment en què algú prem “Confirmar”. Dissenyem també les regles que delimiten fins on pot arribar el sistema sense tornar a preguntar.

Això exigeix que aquestes condicions siguin comprensibles, visibles i fàcils de modificar.

L’usuari hauria de poder saber què ha autoritzat, en quines circumstàncies s’aplicarà i quines excepcions ha definit. En cas contrari, l’autonomia es pot convertir ràpidament en una cosa difícil d’anticipar.

També apareix una qüestió interessant: una autorització no ha de ser absoluta.

Pot dependre d’un import, d’un destinatari, d’un horari, d’una categoria de tasca o de qualsevol altre element rellevant per a aquella decisió.

En aquest sentit, dissenyar autonomia s’assembla menys a activar una funció automàtica i més a definir l’espai dins del qual el sistema pot actuar amb llibertat.

El repte ja no consisteix només a preguntar abans de fer alguna cosa, sinó a permetre que cada persona estableixi amb claredat quan no cal tornar-li a preguntar.

El sistema també ha de saber quan tornar a preguntar

Donar permís a una IA per actuar no hauria de significar que aquest permís sigui vàlid indefinidament.

Les condicions canvien.

Pot canviar el preu, el destinatari, el nivell de risc, la informació disponible o fins i tot l’objectiu que tenia sentit uns minuts abans.

Una acció que encaixava perfectament dins d’unes condicions determinades pot deixar de fer-ho quan canvia el context.

Per això, un sistema autònom no només necessita saber quan pot actuar. També necessita reconèixer quan el permís que tenia ja no és suficient.

Imaginem que algú ha autoritzat una reserva automàtica per sota d’un import determinat. Si el preu augmenta, si canvien les condicions de cancel·lació o si apareix un cost addicional, el sistema hauria de ser capaç d’aturar-se.

El mateix passa amb accions que afecten altres persones.

Un missatge automàtic pot ser perfectament acceptable en un context habitual, però potser no quan canvia el destinatari, el contingut adquireix més sensibilitat o la decisió comença a tenir conseqüències que no estaven previstes.

Aquí apareix una responsabilitat de disseny especialment important: definir quins canvis obliguen el sistema a retornar la decisió a la persona.

No es tracta de fer que la IA dubti constantment, sinó d’identificar els moments en què continuar endavant suposaria actuar sota unes condicions diferents de les que l’usuari va acceptar.

En aquest sentit, l’autonomia no consisteix únicament a avançar sense intervenció humana.

També consisteix a saber quan aturar-se.

Un sistema ben dissenyat no demostra intel·ligència només quan resol una tasca per si mateix, sinó també quan reconeix que el context ha canviat prou per tornar a preguntar.

Conclusió

L’evolució de la intel·ligència artificial se sol mesurar en termes de capacitat.

Què pot fer, quantes tasques pot completar, quant context pot interpretar o fins a quin punt pot actuar sense intervenció humana.

Però des del disseny, potser la pregunta més important és una altra.

No quant pot fer una IA, sinó sota quines condicions hauria de poder fer-ho sense nosaltres.

Perquè, a mesura que els sistemes guanyen autonomia, també augmenta la necessitat de definir límits clars: quan poden avançar, quan necessiten confirmació, quines condicions han de respectar i en quin moment una autorització deixa de ser vàlida.

Això obliga a dissenyar alguna cosa més que funcionalitats.

Obliga a dissenyar permisos, excepcions, llindars i moments de retorn a l’usuari.

I aquí apareix una diferència important entre una automatització simplement eficient i una experiència realment ben pensada.

La primera intenta reduir al màxim la intervenció humana.

La segona entén que hi ha moments en què intervenir continua formant part del valor de l’experiència.

Dissenyar autonomia, per tant, no consisteix a eliminar l’usuari del flux.

Consisteix a decidir amb criteri quan es pot apartar i quan ha de tornar a intervenir.

Perquè un sistema no demostra que està ben dissenyat només quan sap actuar per nosaltres.

També quan sap reconèixer que ha arribat el moment de retornar-nos la decisió.

Si una IA pot completar una acció sense preguntar-nos, també hem dissenyat les condicions que l’haurien d’obligar a tornar-ho a fer?