La Marta va escriure una frase corrent a la finestra de l'eina de factures: “Arregla les factures pendents”. Esperava trobar una llista d'errors i potser un esborrany de missatges per revisar. En tornar d'una trucada, va veure que l'assistent havia enviat correus a tres proveïdors, modificat dues fitxes bancàries segons documents adjunts i arxivat diverses factures com a resoltes. Una de les adreces era antiga i un proveïdor va respondre alarmat perquè no havia sol·licitat cap canvi. La interfície continuava parlant amb el to útil d'una companya: “He deixat tot organitzat”.
El problema no és que una eina pugui preparar una tasca complexa. Pot estalviar molta feina en localitzar duplicats, ordenar documents o proposar una resposta. El problema apareix quan el llenguatge conversacional esborra la diferència entre suggerir, preparar i executar. Una frase oberta pot semblar una petició d'ajuda, mentre el sistema la interpreta com a permís per produir efectes reals. La proximitat del diàleg no pot amagar que enviar un correu, canviar un proveïdor o arxivar un document modifica relacions, comptes i possibilitats de reparació.
La responsabilitat es manté quan cada nivell d'acció és visible. Qui utilitza l'eina ha de poder saber quina informació ha consultat, què ha preparat, què està a punt de fer i què requerirà una confirmació expressa. Aquesta claredat no converteix la feina en una seqüència interminable de botons. Evita que la comoditat d'una instrucció breu transfereixi decisions rellevants a un mecanisme del qual ningú no ha vist l'abast.
Suggerir, preparar i executar són verbs diferents#
Suggerir vol dir oferir una possibilitat sense canviar res. L'assistent pot dir que hi ha tres factures amb imports duplicats, assenyalar una discrepància entre una comanda i un proveïdor o proposar un missatge de consulta. En aquesta fase, la persona conserva la tasca d'interpretar el context. Pot rebutjar un suggeriment, demanar una altra explicació o comprovar un document abans d'avançar. Una recomanació útil mostra les seves fonts i el seu grau de seguretat; no es presenta com una decisió ja presa.
Suggerir vol dir oferir una possibilitat sense canviar res. L'assistent pot dir que hi ha tres factures amb imports duplicats, assenyalar una discrepància entre una comanda i un proveïdor o proposar un missatge de consulta.
Preparar implica transformar informació per facilitar una acció posterior. El sistema pot agrupar factures, omplir un esborrany de correu, crear una llista de pagaments pendents o marcar camps que semblen incoherents. Aquests canvis haurien de quedar en un espai de revisió, clarament diferenciat de les dades oficials. La Marta ha de poder comparar l'esborrany amb l'original, editar-lo, retirar-lo i veure quins documents ha utilitzat l'eina. Preparar estalvia temps precisament perquè deixa el control final en mans de qui coneix la relació comercial.
Executar és una altra cosa: envia una comunicació, modifica una dada mestra, programa un pagament, arxiva un expedient o comparteix un arxiu fora de l'organització. Les seves conseqüències poden ser difícils de desfer i afectar terceres persones que mai no han parlat amb l'assistent. Per això no ha de quedar inclòs de manera ambigua en expressions com “arregla-ho” o “ocupa-te'n”. La interfície ha d'anomenar l'acció, el destinatari, les dades que sortiran i el moment en què passarà.
Els permisos han d'aparèixer abans de necessitar una disculpa#
Un assistent connectat a correu, comptabilitat i arxius pot semblar una sola eina, però els seus permisos no són iguals. Llegir una factura no és el mateix que modificar un número de compte. Redactar un correu no és el mateix que enviar-lo. Cercar un contracte no és el mateix que concedir accés a aquest contracte. Quan la interfície amaga aquestes diferències, la persona descobreix el poder real del sistema només després que alguna cosa surti malament.
L'aplicació hauria de mostrar un resum senzill abans de cada sessió: pot llegir aquesta carpeta, preparar esborranys de correu, però no enviar missatges ni canviar proveïdors sense confirmació. Si un connector nou demana accés, ha d'explicar quines dades veurà, quines accions podrà fer i com es pot retirar el permís. No n'hi ha prou amb una pantalla d'acceptació en instal·lar. Els permisos canvien d'importància quan canvien les tasques i quan una eina adquireix capacitats noves.
També convé limitar els permisos al mínim necessari. Un assistent que revisa factures vençudes no necessita accés permanent a tots els arxius personals ni capacitat per modificar proveïdors. Separar comptes, utilitzar entorns de prova i concedir accés temporal redueix l'abast d'un error. Aquesta prudència no és desconfiança envers la tecnologia; és disseny responsable d'una eina que opera dins de relacions econòmiques reals.
La confirmació ha de ser proporcional al dany possible#
Demanar confirmació per a cada pas petit acaba entrenant la gent a prémer “acceptar” sense llegir. No demanar-la per a res converteix l'ajuda en una delegació cega. L'equilibri consisteix a adaptar la confirmació a la conseqüència. Per ordenar una llista o generar un esborrany pot ser suficient una indicació visible que el resultat encara no s'ha aplicat. Per enviar un correu a un proveïdor, l'eina ha de mostrar el text, el destinatari i els adjunts. Per canviar un compte bancari, programar un pagament o eliminar documentació, necessita una confirmació més forta i potser una segona persona autoritzada.
La confirmació útil no pregunta només “n'estàs segur?”. Explica què passarà i què no es podrà recuperar fàcilment. Pot avisar: “Aquest canvi afectarà pagaments futurs i substituirà la dada anterior; la versió prèvia es conservarà durant trenta dies”. Així la Marta pot detectar que una correcció aparent és en realitat una decisió amb abast financer. El llenguatge precís retorna atenció al moment en què importa.
Hi ha accions que no s'haurien d'executar des d'una conversa general encara que algú confirmi. Canviar dades de proveïdors, transferir fons o enviar informació sensible pot requerir un flux específic amb comprovacions externes. Una interfície amable no elimina la necessitat de controls dissenyats per evitar frau, error o pressió indeguda. La facilitat de demanar alguna cosa amb paraules no ha de rebaixar la protecció d'allò que aquestes paraules desencadenen.
Un historial reversible és una forma de cura#
Després d'una acció, la persona necessita veure una història clara: què va demanar, què va interpretar l'assistent, quines fonts va utilitzar, quins canvis va proposar, quins es van aprovar i quan es van executar. Aquest historial no és un diari exhaustiu de cada conversa. És una memòria acotada d'accions amb efectes, creada perquè la Marta pugui explicar un canvi a un proveïdor, trobar un error i corregir-lo abans que s'estengui.
La reversibilitat ha de ser real. Si l'assistent ha arxivat una factura, hi ha d'haver una manera de restaurar-la. Si ha canviat un camp, cal poder recuperar el valor anterior i saber qui va autoritzar el canvi. Si ha enviat un correu, no es pot retirar de la bústia del destinatari, però l'historial pot ajudar a respondre aviat, aturar una acció relacionada i revisar com s'ha produït l'enviament. “No es pot desfer” no hauria de ser el punt de partida del disseny.
L'accés a aquest historial s'ha de protegir, perquè també pot contenir informació econòmica sensible. Qui necessiti reparar una acció ha de poder consultar-lo; qui no, no necessita una finestra a tota l'activitat dels companys. Retenció limitada, permisos definits i registres de consulta permeten que la traçabilitat serveixi per corregir sense convertir-se en vigilància quotidiana.
Aprendre dels límits en comptes d'amagar-los#
Quan la Marta descobreixi un correu enviat per sorpresa, la resposta no hauria de ser culpar-la per una instrucció poc precisa. És un senyal que la interfície no va expressar bé el seu abast. L'equip pot revisar quina frase va activar l'acció, quins permisos estaven actius, quina confirmació faltava i per què el flux no va separar esborrany d'enviament. Després pot canviar el disseny i comunicar-lo a qui utilitza l'eina. Una incidència ben tractada millora una regla; una incidència amagada torna a passar.
La formació també ha d'anar més enllà d'una demostració inicial. Les persones han de practicar amb casos simulats: demanar un esborrany, revisar fonts, rebutjar un suggeriment, restaurar un canvi i reconèixer quan una acció necessita un circuit diferent. La meta no és convertir tota la plantilla en especialista tècnica. És donar llenguatge i criteri suficients per distingir suport d'agència i aturar una eina quan supera l'encàrrec.
El pas següent pot ser petit i precís. Reviseu les tres últimes accions que hagi realitzat l'assistent i classifiqueu-les: suggerir, preparar o executar. Per a cada execució, anoteu el permís utilitzat, la confirmació rebuda i la manera de revertir-la. Després elimineu els permisos que no siguin necessaris i canvieu una pantalla perquè mostri l'efecte abans d'actuar. Un assistent útil no és qui fa més coses sense preguntar. És qui ajuda a treballar millor sense que ningú descobreixi massa tard que ja havia decidit.
