Progettare per gli agenti AI: la UI che l'utente non umano legge

L'utente non umano è l'agente AI che visita il prodotto per agire al posto di una persona: confronta opzioni, compila un form, prenota uno slot o acquista. Progettare per lui vuol dire costruire un'interfaccia che una macchina riesce a leggere e usare, non solo quella che una persona vede sullo schermo.

Prima era un caso limite. Oggi è traffico. Nella settimana dal 30 maggio al 5 giugno 2026, Cloudflare ha misurato che il 57,2% delle richieste a contenuti HTML arrivava da client automatici, davanti ai browser umani. Adobe ha rilevato che il traffico da fonti AI verso i siti retail USA è cresciuto del 393% su base annua nel primo trimestre 2026, e che a marzo convertiva il 42% meglio delle altre fonti, fino al 54% a maggio. Gartner stima che entro fine 2026 il 40% delle applicazioni enterprise integrerà agenti specializzati. Il lettore per cui non hai mai progettato è già sulla pagina.

Chi è l'utente non umano?

Si presentano tre tipi di agente. Gli assistenti (ChatGPT, Claude, Perplexity) navigano e riassumono. Gli agenti computer-use guidano un browser vero e cliccano per portare a termine i task. Gli agenti commerce vanno oltre e completano un acquisto. Hanno un tratto in comune: nessuno di loro vede il design. Ognuno legge una rappresentazione della pagina e agisce su ciò che quella rappresentazione dichiara presente.

La domanda quindi non è più "ha un bell'aspetto", ma "un programma capisce cos'è questo elemento e riesce a usarlo". Una pagina può superare una design review ed essere comunque illeggibile per un agente, perché i due lettori consumano livelli diversi della stessa pagina.

Come legge davvero una pagina un agente AI?

Gran parte degli agenti legge l'accessibility tree. È il modello semantico che il browser costruisce dal DOM: un elenco di elementi con ruoli (button, link, heading), nomi (l'etichetta accessibile) e stati (espanso, selezionato, disabilitato). Gli screen reader usano questo albero da vent'anni. Gli agenti lo riusano perché è più snello e affidabile dell'analisi dei pixel. OpenAI ha dichiarato che il suo browser Atlas legge i tag ARIA per interpretare la struttura della pagina. La conseguenza pratica è netta: una pagina che funziona per una persona cieca tende a funzionare per un agente, e una che fallisce con l'una fallisce con l'altro.

Il costo di un albero degradato si misura. Nello studio A11y-CUA presentato a CHI 2026, i ricercatori di UC Berkeley e University of Michigan hanno fatto girare Claude Sonnet 4.5 su 60 task quotidiani desktop e web in tre condizioni. Con accesso standard completava circa il 78% dei task. Con la sola navigazione da tastiera, che ricalca il modo in cui si muove un agente basato sull'accessibility tree, il successo è sceso al 42% e i task richiedevano circa il doppio del tempo. Con un viewport ingrandito è caduto al 28%. Quasi metà dei fallimenti si riduceva a una cosa sola: l'informazione strutturale che serviva all'agente non era nel markup.

Perché il livello visivo nasconde il problema

L'inganno è che una pagina stilizzata sembra finita. Un button fatto con un div e un handler onClick appare identico a un button vero. Una persona vede un pulsante e clicca. Un agente legge un contenitore generico senza ruolo e senza nome, e lo salta. Lo stesso scarto torna ovunque un team scelga lo stile visivo al posto della semantica:

• Controlli con sola icona e nessuna etichetta testuale. L'agente vede una cosa cliccabile senza sapere cosa fa.
• Dropdown e toggle custom costruiti con div e span. Nessun ruolo, nessuno stato, nessun percorso da tastiera.
• Contenuti disegnati in canvas o WebGL, o testo incastonato nelle immagini. Invisibili all'albero.
• Stato segnalato solo dal colore. "Selezionato" con un bordo blu e niente nel markup che dica selezionato.

Ognuno di questi casi va bene per una persona vedente ed è un muro per tutti gli altri, sia chi usa lo screen reader sia l'agente.

Come si progetta per l'utente non umano?

Il lavoro si sovrappone molto all'accessibilità fatta bene. Otto mosse coprono quasi tutto.

1. Usa elementi semantici veri. button, a, nav, main, label, table, heading reali. Gli elementi nativi portano ruolo corretto e comportamento da tastiera senza costi aggiuntivi.
2. Dai un nome a ogni controllo. Testo visibile dove puoi, aria-label dove non puoi. Un button con sola icona, senza nome, per un agente è anonimo.
3. Tieni onesto l'albero sui componenti custom. Se devi costruire un widget con elementi generici, assegna ruolo, stato e un ordine di focus che corrisponda a ciò che l'occhio vede.
4. Rendi lo stato leggibile dalla macchina. aria-expanded, aria-checked, aria-disabled. Il colore da solo all'agente non dice niente.
5. Esponi dati strutturati. Con JSON-LD Schema.org per prodotti, offerte, prezzi e FAQ un agente legge i fatti senza fare scraping del layout. Vedi la nostra guida ai tipi di schema markup che ogni blog serve.
6. Fai entrare gli agenti. Non bloccare i loro crawler al edge per default.
7. Tieni i contenuti critici renderizzati lato server. Un agente può non eseguire il tuo JavaScript client-side. Se prezzo, form o testo principale compaiono solo dopo l'hydration, l'agente legge un guscio vuoto.
8. Per il commerce, parla un protocollo. Un checkout strutturato batte la compilazione fragile di un form. Vedi come costruire un server MCP per il lato interfaccia-agente.

Il livello commerce si sta standardizzando in fretta

Se il prodotto vende qualcosa, il modo in cui un agente compra passa dall'indovinare a uno standard. Stripe e OpenAI hanno rilasciato l'Agentic Commerce Protocol per alimentare Instant Checkout in ChatGPT. Google ad aprile 2026 ha donato il suo Agent Payments Protocol (AP2) alla FIDO Alliance. Shopify e Google al NRF di gennaio hanno annunciato un Universal Commerce Protocol, e Visa ha rilasciato un on-ramp agnostico che ne accetta diversi insieme. L'idea condivisa è un checkout strutturato e con consenso esplicito che l'agente richiama, invece di un agente che annaspa in un form pensato per il mouse. Supportarne uno è il modo in cui un agente chiude una vendita alle tue condizioni invece di abbandonarla.

La fiducia resta il filtro dell'ultimo passo. I sondaggi del 2026 collocano la disponibilità a far confrontare i prezzi all'AI intorno al 65%, ma quella a farle piazzare l'ordine vicino al 14%. Gran parte degli agenti restituisce ancora il clic finale alla persona. Va bene così. Il compito è rendere puliti la lettura, il confronto e il passaggio di mano, così l'umano dice sì con tutto già nel carrello.

Dove la UI per gli umani e quella per gli agenti divergono

Quasi tutto è condiviso con l'accessibilità, ma non tutto. Gli agenti vogliono struttura stabile, selettori prevedibili e un percorso macchina verso lo stesso risultato che un umano raggiunge a occhio. Non hanno bisogno della tua coreografia di scroll, degli stati di hover o dei tempi della modale. La risposta onesta è un core unico, non due siti: costruisci una base accessibile, semantica e renderizzata lato server, poi sopra ci metti l'esperienza visiva. Costruire una versione nascosta separata per i bot invita penalizzazioni da cloaking e nel giro di settimane si disallinea dalla pagina reale. Una sola fonte di verità, letta da entrambi i pubblici.

L'utente non umano è la persona con screen reader per cui avresti già dovuto progettare, ora con un budget e un checkout. I team che spediscono interfacce semantiche, strutturate e renderizzate lato server ottengono due lettori al prezzo di uno. I team che spediscono interfacce solo-pixel vengono saltati da entrambi.