Se fossimo razionali, il piacere di guadagnare qualcosa dovrebbe equivalere alla paura di perdere la stessa cosa. Per esempio, 20 euro. Ma non è così: la paura di perdere qualcosa è maggiore (circa doppia) del piacere di acquisirla. Questa è una delle grandi scoperte per le quali gli psicologi Kahneman e Tversky vinsero il premio Nobel per… l’economia (non lo danno, il premio Nobel per la psicologia!). La tendenza è nota come “avversione alla perdita”.

La Teoria del Prospetto e come ci comportiamo in realtà

Le scoperte di Kahneman e Tversky sono molto più complesse di così e vengono riassunte in una teoria generale chiamata Prospect Theory o Teoria del Prospetto. Validata da esperimenti, definisce come le persone si comportano realmente quando devono prendere delle decisioni, e non come dovrebbero o potrebbero comportarsi.

Per questo le scoperte della Teoria del Prospetto vengono utilizzate in molti settori: da quello commerciale alllo studio delle crisi internazionali. E, naturalmente, anche nel settore della progettazione online.

Ne ho accennato parlando del modo in cui sono costruiti i Termini del Servizio che accettiamo con un click quando ci iscriviamo ad un servizio online.

Il caso dell’iscrizione ai servizi online

Pochi se lo ricordano, ma una quindicina d’anni fa fare in modo che le persone si iscrivessero a un servizio online era un’impresa titanica. Venivano predisposte lunghe pagine di form per richiedere dati personali e fiscali che le persone non volevano dare, e la cui compilazione era lenta e onerosa, ma che gli uffici legali insistevano essere necessarie.

In altre parole bisognava sostenere quella che veniva percepita come una perdita immediata a fronte di un guadagno incerto, perché i vantaggi dei servizi erano meno chiari di oggi. Pessima strategia. Infatti i tassi di conversione erano bassissimi.

Oggi è sufficiente una mail e una password e siamo iscritti.

Si è capito che le informazioni più dettagliate possono essere fornite dopo, in fasi successive, magari parcellizzate in procedure di più pagine costruite come un gioco per minimizzare il costo cognitivo o l’incertezza.

Insomma, è come se tutti i progettisti si fossero progressivamente adattati alla nostra naturale avversione alla perdita e avessero modificato procedure e design di queste pagine.

Altre applicazioni

Ma altri esempi non mancano. Il sito Ui-patterns consiglia di applicare le conoscenze derivate dalla loss-aversion nei seguenti casi:

• Quando una decisione può essere fatta percepire o descritta come una perdita o un guadagno
• Quando si voglia motivare un utente a continuare
• Quando si voglia motivare un utente a iniziare un percorso.

Tutte queste situazioni si applicano all’iscrizione online a un servizio esemplificata sopra. Un unico bottone invece di molti campi non è solo usabilità migliore: è far percepire un’azione come poco rischiosa e poco costosa.
Il problema è che si può far percepire in questo modo un’azione come poco rischiosa anche se invece rischiosa lo è: e questo è un ennesimo problema etico nella progettazione delle interfacce e dei contenuti veicolati.

Il framing della situazione

È importante sottolineare che le persone non scelgono in base a come sono le alternative in realtà, ma a come sono formulate. La formulazione altera la percezione di perdite e guadagni. Questo fenomeno è detto framing, incorniciamento, e la sua importanza è una delle scoperte di Kahneman e Tversky. Nei loro esperimenti, infatti, a gruppi diversi di partecipanti venivano presentati problemi equivalenti. Ma semplici differenze linguistiche nel modo di presentarli ai diversi gruppi cambiava la probabilità delle scelte.

L’acquisto dell’accessorio

Il framing non è solo linguistico, ma relativo al contesto.

Un esempio fornito da UXMatters è particolarmente utile, e compare anche in alcuni libri sull’applicazione della psicologia al design:

Chi ha familiarità con le proposte di e-commerce sugli “articoli comprati assieme” dovrebbe conoscere già la risposta. Chi non ce l’ha dovrebbe dedurla dall’avversione alla perdita. La risposta corretta è la 1, perché in quel momento l’utente sta spendendo molto di più per la macchina fotografica, dunque l’esborso per una custodia costosa gli sembrerà meno svantaggioso che in un secondo momento, visto che spende comunque meno della macchina fotografica e che, anzi, quell’acquisto gli apparirà in quel momento un modo economico proprio per proteggere da una possibile perdita un oggetto di valore.

Se effettuato in un momento successivo, l’acquisto della custodia sembrerà invece un esborso rispetto allo status quo, cioè una perdita netta.

In questo esempio, l’acquisto di un tablet viene associato all’acquisto di ben due diversi accessori di prezzo inferiore. Si noti che non vengono proposti gli accessori più economici né i più costosi, ma quelli con un prezzo all’incirca mediano. È probabile che questo sia frutto di test e sia collegato anche ai giudizi espressi dagli utenti sui prodotti: evita il rischio di lamentele su prodotti troppo economici o troppo costosi. In questo caso pare entrare in gioco un ulteriore fattore, non previsto nella formulazione originale del problema: il rating dei prodotti.

L’ancoraggio e l’esca

Per lo stesso principio quando si elencano le opzioni di possibili importi per delle donazioni, ad esempio, l’ordine può fare la differenza. Mostrando per primi gli importi più elevati (ad esempio 500 € prima di 100 €, 50 €, 20 €), gli altri sembreranno opzioni più favorevoli che se non ci fosse quella prima opzione molto cara. Questo effetto di influenza di una opzione iniziale sulle altre si chiama ancoraggio.

Come in tutto ciò che riguarda la loss-aversion, però, le cose non sono così semplici. L’effetto dell’ancoraggio dipende anche da altri fattori:

• quali sono gli importi massimi
• le possibilità economiche del vostro pubblico
• l’attrattività delle diverse alternative (cosa si ottiene in cambio di una certa offerta)
• la differenza di costo fra le alternative
• il numero delle opzioni
• la scarsità eventuale di qualcuna di queste opzioni

Un interessante esempio di scuola che consente di apprezzare l’importanza di diversi fattori in gioco nella predisposizione alle scelte è il seguente, descritto da Dan Ariely nel libro Predictabily Irrational:

L’84% degli studenti ha scelto la terza opzione, carta più web.

Eppure, questa scelta è stata manipolata. Lo si capisce chiaramente con i risultati di un secondo gruppo, al quale non veniva presentata la seconda opzione (solo carta). In presenza di sole due alternative, solo il 34% di studenti sceglieva l’opzione “carta e web”!

L’opzione “solo carta” era dunque quella che viene chiamata offerta-esca, o decoy, cioè un’opzione che serviva solo a far percepire più attrattiva la terza* E ha funzionato.

Conclusioni

Dovrebbe a questo punto essere chiaro che la loss-aversion è solo una delle distorsioni cognitive che entrano in gioco quando si prendono decisioni, e che le loro interazioni potrebbero non essere sempre ovvie.

Ogni caso progettuale andrebbe dunque definito, studiato e testato, come questo paper suggerisce.

Per il momento, è utile iniziare a identificare nelle proprie opzioni di design tutti i momenti in cui poniamo l’utente di fronte a delle scelte e a ragionare su come stiamo architettando quelle scelte. Sia che lo facciamo consapevolmente che in modo ingenuo, il modo in cui le presentiamo ha sicuramente effetto sulle sue probabilità di risposta.

Quando i media generalisti si occupano di tecnologia e social network i casi sono due: o stanno spingendo un prodotto, o è successo qualcosa di grosso.

Sugli scudi stavolta c’è la campagna elettorale di Donald Trump, condotta dallo stratega Steve Bannon attraverso una società creata assieme a Robert Mercer e chiamata Cambridge Analytica. Questa società sarebbe stata creata al fine di costruire profili “psicografici” (che non sarebbero altro però che normali profili che includono gusti e inclinazioni) di milioni di americani per costruire campagne social con messaggi mirati.

La “psicografia” per nascondere una violazione

Un primo problema nasce con la definizione di “profilo psicografico”: un termine che non vuol dire niente, non ha base scientifica e che ha fatto gridare qualcuno al millantato credito. In verità, con quello che è emerso in seguito, pare chiaro che fosse un termine vago e pomposo usato per occultare che si trattasse di profili estratti da Facebook in violazione dei suoi termini di servizio.

Lo scopo era semplice. In pratica, mandando il messaggio giusto alla persona predisposta o coinvolta su un certo argomento, è più facile fare in modo che questa persona rimanga convinta dall’argomento. Non serve solo a convincere qualcuno a cambiare idea, ma soprattutto a rafforzare le idee di quel qualcuno, in modo che non solo non le cambi, ma diventi più attivo e faccia proselitismo, invece di starsene silente. Da information recipient diventi information seeker e persino opinion leader, secondo un diffuso modello di propaganda.

Questo tipo di messaggi – poiché sono mirati a qualcuno che già pensa certe cose – sono meno efficaci e più costosi se inviati a un mucchio indistinto di persone. E’ lo stesso principio per cui vi trovate banner con le scarpe che vi interessano dopo aver fatto una ricerca online proprio sulle scarpe. E magari ne siete pure contenti perché trovate l’offerta migliore. Solo, riferito alle idee politiche, o magari anche solo alla “visione del mondo”: aspetti particolari e sensibili come l’uso delle armi, o l’immigrazione o i temi etici su inizio e fine vita. Un messaggio particolarmente aggressivo su questi temi, se arriva a qualcuno che ha idee opposte genera indignazione e resistenza, ma se arriva a qualcuno già incline a pensarla in quel modo, genera in meccanismo di rafforzamento delle proprie opinioni, specie se accompagnato da alcune strategie mirate a farlo sembrare già condiviso da un sacco di gente, e in particolare da gente proprio simile a noi. Non solo aderiamo quindi ancora di più a quella idea: ci convinciamo pure di non essere soli a pensarla così, e di essere al centro di un gruppo coeso di sconosciuti simili a noi.

Scoprire i profili a cui inviare

Se questo è ciò che Bannon e Mercer hanno fatto, il punto è: come hanno fatto a sapere a chi inviare, sui social network, questo genere di messaggi e a chi no? Per chi sarebbero stati più efficaci e per chi meno? Grazie al lavoro del professor Aleksandr Kogan dell’Università di Cambridge. Assoldato da Bannon e Mercer, Kogan ha accettato di produrre un’app chiamata “Thisisyourdigitallife” e l’ha reclamizzata (con un discreto investimento, pagando anche i partecipanti) come un’app per la raccolta dati in ambito accademico. Lo scopo dichiarato era compilare un questionario personale, ma il vero obiettivo dell’app era più complesso: fare in modo che chi la scaricasse usasse per loggarsi le funzionalità di Facebook Login, il servizio – simile a quello offerto da molti altri social network – grazie al quale si possono usare le stesse credenziali di Facebook su app e servizi terzi senza dover ricordare nuove password. Ben 270.000 utenti si sono loggati all’app nel 2014 usando questa funzionalità.

Kogan a quel punto non ha fatto altro che sfruttare una funzionalità ben prevista da Facebook Login: accedere ad alcuni dati non solo degli utenti che si sono loggati, ma anche dei loro amici, registrati dal social network. Secondo alcune stime, circa 50 milioni in tutto. Di queste persone, che non avevano scaricato l’app ed erano ignare di tutto, Kogan ha potuto utilizzare informazioni che vanno dalla residenza a un insieme di gusti e inclinazioni, associati a quelle del profilo compilato dagli originali 270.000. Utilizzandole hanno potuto dedurre altri gusti e preferenze, costruendo un profilo utile agli scopi della campagna.

Nessuna violazione della sicurezza o della privacy

Quanto fatto da Kogan, ci tiene a precisare Facebook, era perfettamente legale. Non è stata sfruttata nessuna vulnerabilità. Nessuna intrusione nei meccanismi di sicurezza. Nemmeno alcuna violazione della privacy. Perché era proprio il modo in cui Facebook e il suo sistema di Login distribuito funzionava “by-design”, e gli iscritti lo avevano accettato accettando i termini del servizio.

Laddove Facebook ritiene che Kogan abbia violato i termini del servizio è in quel che ha fatto dopo: ha passato questi dati e questi profili a Cambridge Analytica. Questo è espressamente vietato da Facebook, anche se all’epoca lo era in maniera forse meno chiara di oggi. Era (ed è) vietato tentare di monetizzare quei dati inviandoli a servizi terzi di advertising, essenzialmente. Da allora, Facebook ha modificato le API e gli sviluppatori di terze parti non possono più accedere ai dati degli amici.

Facebook sapeva e ha taciuto

Per almeno due anni Facebook avrebbe saputo di questo uso dei dati, e avrebbe semplicemente chiesto a Kogan di cancellarli. Senza nemmeno verificare che poi l’abbia veramente fatto.

E’ proprio per questo comportamento che ora Facebook viene chiamato in correità dall’FBI.

Questo è quello che è successo e le cui responsabilità verranno acclarate. La domanda che io mi porrei però è: quello che nel 2014 era un’iniziativa un po’ fraudolenta di un professore e un paio di miliardari che hanno voluto influenzare una campagna elettorale, non è forse ciò che, di base, fanno le piattaforme di programmatic advertising ? Incrociando dati provenienti da svariate fonti, pur legali, costruiscono profili accurati degli interessi in tempo reale di ciascuno di noi, per proporci su qualunque sito proprio la reclame delle scarpe e proprio nel momento in cui le stavamo cercando.

Una possibilità già alla portata di piattaforme specializzate

La differenza la fa il fatto che Bannon e Mercer hanno usato uno strumento personalizzato bypassando le tradizionali piattaforme di advertising, e in particolare quella interna di Facebook. E magari inviando non solo pubblicità, ma anche messaggi, inviti a gruppi, insomma, facendo sembrare l’azione più “spontanea”. Ma le informazioni su di noi consentirebbero a chiunque gestisca queste piattaforme di farlo comunque. Magari senza violare alcun “Termine del servizio”.

Ma qui allora dovremmo ricordarci che Facebook non ha eliminato la possibilità di utilizzare i dati degli amici. L’ha solo riservata a… se stesso. In pratica, il problema della Cambridge Analytica sarebbe che ha fatto quello che consente di fare Facebook, ma senza pagare Facebook. Alcuni ricordano infatti che la stessa campagna 2012 di Obama (non quella del 2008, che era basata su un meccanismo autonomo e senza l’uso così massiccio dei social network commerciali, che non avevano le capacità di oggi) era stata fatta per creare messaggi personalizzati da inviare a target specifici. Bannon e Mercer fanno lo stesso ma “fuori da Facebook”.

In mezzo, ci sono i nostri dati, oggetto oggi più che mai di quello che viene chiamato surveillance capitalism. In pratica gli operatori possono agire h24 indirizzandoci messaggi mirati perché ci conoscono bene. A volte questo avviene per fini commerciali, ma a volte per fini politici o ideologici. Ogni volta viene comunque fatto per influenzarci. Talvolta ce ne accorgiamo, altre no.

Trasparenza e usabilità vanno a braccetto?

Su questo si innesta dunque il problema del modello di business di queste tecnologie, e soprattutto della trasparenza o meno della loro azione nei nostri confronti. Avrete notato infatti che l’app di Kogan ha sfruttato proprio un vantaggio di usabilità per gli utenti: la possibilità di un login unico, tramite Facebook. L’usabilità qui viene usata come grimaldello per quella che appare nell’immediato una facilitazione, ma nel lungo termine consente un pescaggio di dati di cui i nostri amici non sono consapevoli, reso possibile dalle API di Facebook e dalla nostra accettazione dei suoi termini di servizio. Era chiara questa possibilità al momento di usare il Facebook Login? E quando abbiamo accettato i termini di servizio?

Ecco, l’ultimo tema è quello dei termini di servizio. È davvero possibile sostenere che basti un qualche click da parte nostra su un qualche bottone e qualche casella di spunta per mettere questi fornitori di servizi al riparo da ogni responsabilità legale? Il problema è spinoso, perché riguarda quello non dell’usabilità, ma della comprensibilità delle condizioni contrattuali. E non coinvolge solo i giganti tech, ma anche banche e assicurazioni (e ogni altro erogatore di servizio). Quanto davvero capiamo dei contratti che sottoscriviamo? In banca, oppure online? Eppure, queste sottoscrizioni sembrano tutto ciò che basta a tutelare il service-provider.

È davvero giusto che sia così? Non sarebbe più giusto invece verificare, con casi concreti ed esempi, che il sottoscrittore abbia capito in pratica cosa significa il contratto, o cosa implicano i termini del servizio, usando precisi scenari? E che sia davvero d’accordo con i casi peggiori che possono presentarsi? Se anziché sottoscrivere un documento in legalese ci venissero posti davanti problemi, cioè situazioni-tipo che comportano conseguenze per i nostri soldi e per i nostri dati, e dessimo direttamente il consenso o il diniego a quelle?

Ad esempio, se ci venisse chiesto:

E ancora, si potrebbe specificare:

Sono solo esempi, ma sufficienti a spingerci a riflettere cosa risponderemmo. Accetteremmo ancora di usare il servizio? Ed è positivo per una società (e per una democrazia…) consentire, ad esempio, che le persone ricevano messaggi solo da coloro che già concordano con loro? Ecco che, messe in questi termini, le condizioni di un servizio appaiono sotto una luce differente.

Una circonvenzione di massa?

E se ci venisse detto prima di tutto:

sottoscriveremmo ancora certi contratti finanziari? Un legale può obiettare che il modo in cui sono scritti questi contratti implica già che queste sono le condizioni, ma se facessimo un test di comprensibilità ad ogni sottoscrittore di un contratto dopo la firma, per essere certi che chi ha firmato ne capisca le implicazioni, siamo certi che non troveremmo risultati che contraddicono questi legali?

In molti casi peraltro nemmeno li leggiamo, i contratti: finiamo per affidarci al consulente finanziario o al social a cui vogliamo accedere. Che infatti si affrettano a conquistare una preziosa proprietà chiamata fiducia. E se fosse tutta una circonvenzione di incapace a comprendere, o, peggio, disinteressato a comprendere?…

L’avversione alla perdita

In un certo senso, il modo in cui sono scritti i contratti costituisce quindi una prima forma di manipolazione. Sappiamo dalla psicologia cognitiva che uno stesso problema che coinvolge le probabilità di perdita e guadagno può essere espresso in modi diversi, e che questi modi diversi, pur equivalenti sul piano del significato, danno vita a scelte e giudizi differenti. Si tratta di un fenomeno noto come avversione alla perdita: siamo più propensi a evitare un evento se ci viene raccontata la probabilità di perdere qualcosa, che se ci viene esposta la complementare probabilità di guadagno. È ovviamente così anche con i contratti. Se tali contratti mettessero sempre in chiaro concretamente cosa rischiamo di perdere, in determinate circostanze, oltre che le probabilità di guadagno, non sarebbero forse solo allora veramente onesti?

Il problema non è detto si risolva neanche così, ma il tema si pone e andrebbe approfondito. È ormai chiaro che i contratti scritti per non essere letti e comunque per non essere capiti sono all’origine delle principali controversie, quando non proprio truffe, nella nostra società dei servizi. Quanto dovremo attendere per rendercene conto e discutere delle loro modalità e della nostra capacità di accettazione?

Aggiornamento: L’articolo è stato modificato dopo la prima pubblicazione per correggere l’anno in cui Kogan ha usato l’app: era il 2014 e non il 2015. Facebook ha d’altra parte eliminato questa possibilità dalle sue API nell’aprile 2015.

Nel campo dell’usabilità ci sono alcuni eventi emblematici che attirano l’attenzione sulla nostra disciplina e travalicano la cerchia degli specialisti.

Uno degli esempi più citati è quello della scheda delle elezioni USA 2000, che costarono il posto ad Al Gore e diedero un decisivo impulso al doppio mandato di George Bush. Il disastro viene ben raccontato da Bruce Tognazzini, e viene spesso citato a esempio di cattiva progettazione, finendo nei commenti di molti giornali e siti generalisti.

La posizione dei fori di punzonatura è ambigua e non corrisponde all’ordine di comparsa nell’elenco dei candidati.

A margine, è bene notare come il design della punzonatrice ne ricordi altri. Ad esempio, quello di alcune emettitrici di biglietti per trasporti pubblici, dove tuttavia non risulta ambiguo (il che ci dice anche come avrebbe potuto essere corretto quello della scheda elettorale).

In questa emettitrice l’ambiguità viene risolta, oltre che con un allineamento preciso fra righe e pulsanti,
anche con la corrispondenza diretta di frecce che collegano righe e pulsante. Si potrebbe dire molto altro sulla comprensibilità delle molte opzioni disponibili, ma questo è un altro discorso.

HealtCare.gov: quando il fiasco minaccia un’azione politica

Più sorprendente quello che è successo nel 2013 sempre negli USA, con il lancio del sito Healthcare.gov, che doveva concretizzare finalmente l’agognata riforma del sistema sanitario statunitense nota anche come “Obamacare”.

Molti ricorderanno che l’esordio del sito Healtcare.gov fu un fiasco tale da rischiare di affossare l’intera riforma di Obama. Ne parlarono a lungo i giornali generalisti, e la cosa sorprese anche perché in precedenza lo staff di Obama aveva dimostrato grande capacità nell’uso delle nuove tecnologie e in particolare dei social media¹.

Se la scheda elettorale del 2000 mostrava errori di progettazione e di stampa del materiale cartaceo in relazione alla modalità di votazione con punzonatura – quindi non atteneva strettamente al solo mondo digitale – il problema del 2013 è perfettamente esemplificativo delle difficoltà di progettazione e di gestione che affliggono molti progetti online pubblici.

L’aspetto che finì all’epoca sui giornali riguardava principalmente l’errato dimensionamento dei carichi di accesso al sito nel momento in cui, il primo ottobre 2013, questo andò online. L’accesso degli utenti fu talmente massiccio – con picchi di 250.000 accessi simultanei quando ne erano stati previsti al massimo 60.000 – che portò all’impossibilità per molti utenti di completare le procedure, con attese ingiustificatamente lunghe, le quali davano vita a nuovi tentativi da frustrazione che sovraccaricavano ulteriormente il server, in una spirale che si autoalimentava.

Dai problemi tecnici a quelli di usabilità

Strettamente parlando, si potrebbe derubricare l’episodio a problema gestionale e funzionale, e non legato all’usabilità. In fondo, il corretto dimensionamento dei carichi di un server non è – di solito – compito di coloro che si occupano dell’usabilità. Ed è vero.

Tuttavia i problemi non si fermavano lì. Come un dettagliato resoconto di Craig Tomlin, che condusse dei test di usabilità, ci ricorda, alcuni aspetti concomitanti alle difficoltà di accesso erano mal gestiti anche dal punto di vista dell’usabilità. E potrebbero tutt’ora interessare i progettisti di tutti i siti, pubblici e privati.

1. Le schermate d’attesa devono fornire informazioni appropriate, rassicuranti e utili

Mentre gli utenti avevano difficoltà ad accedere al sito per i già menzionati problemi di dimensionamento, la schermata su cui rimanevano bloccati in attesa offriva un messaggio generico, senza indicazioni di quanto tempo ci sarebbe voluto per procedere.

“Abbiamo un sacco di visitatori in questo momento, per favore rimanete su questa pagina” – su un sito così lungamente atteso-
non offre una grande impressione di affidabilità. No, purtroppo le simpatiche icone non sono sufficienti…

In molti siti la messaggistica non è curata, non si ragiona per scenari d’errore ma solo per scenari di successo, cosicché inevitabilmente, quando l’errore capita, non se ne ha una gestione che aiuti a minimizzare il danno, pratico e di immagine. I messaggi d’errore devono spiegare con un linguaggio chiaro all’utente cosa è successo (o, in questo caso, cosa sta succedendo) e cosa può fare lui per risolvere, offrendo indicazioni pratiche (se possibile, idealmente dei link attivi verso pagine di soluzione).

La cosa più notevole però è che in questo caso il messaggio c’è e la pagina è curata: semplicemente è un messaggio troppo generico e deresponsabilizzante: il sito era molto atteso, come mai ora mi dicono solo che ci sono tanti visitatori? Non lo immaginavano? E non devo far altro che rimanere qui per “non perdere la priorità acquisita”, come in una qualsiasi telefonata di assistenza? Lo stesso richiamo a quell’espressione contribuisce probabilmente a evocare un senso di fastidio e di scarso rispetto per il cittadino.

Bisognava informare su cosa stava succedendo e perché proprio nel giorno del lancio ci si trovava ad avere un eccesso di utenti. A volte le attese sono inevitabili, ma le pagine d’attesa dovrebbero essere chiare su quanto bisognerà attendere, e magari cogliere l’occasione per offrire informazioni utili, rassicurare, spiegare quanto potrà accadere e quali opzioni avrà davanti all’utente.

2. La chat: uno strumento potenzialmente utile, ma gestito malissimo

A peggiorare l’impressione che il sito fece ai cittadini c’è la cattiva gestione di uno strumento che era stato preparato e pensato proprio con l’obiettivo opposto: quello di dare l’idea di un sito vivo, dove l’utente è accudito, grazie a una live-chat disponibile sul sito.

Peccato che anche questa soffrisse, inevitabilmente, dello stesso difetto di dimensionamento. Così quella che, in condizioni normali, diventa un’occasione per intervenire e aiutare direttamente l’utente, divenne in quell’occasione l’ennesimo strumento che non offriva risposte, né indicazioni sui tempi per ottenere risposte.

La conseguenza di questo doppio malfunzionamento (causato in realtà dallo stesso problema, e da una cattiva progettazione delle alternative) fu che gli utilizzatori si fecero non solo un’idea negativa del servizio, ma anche di possibili altre strade di supporto. Ad esempio, si convinsero che non valesse la pena telefonare al numero verde perché, se due strade percepite come “automatiche” e tecnologiche si erano rivelate così scadenti, come avrebbe potuto una semplice assistenza telefonica essere di maggior aiuto?

3. Errori di comunicazione dei formati già nella fase di login

Nel momento del login, il messaggio di errore che invitava a comporre uno username e una password sicuri appariva ambiguo, con delle congiunzioni oppositive (“o” invece che “e”), posizionate nella frase in modo da far credere che bastasse scegliere o caratteri minuscoli o maiuscoli (e non entrambi), o numeri o simboli (e non entrambi). La conseguenza è che molti sbagliarono già nella fase di creazione del login.

I molti siti privati che gestiscono password e username forniscono una serie di pattern abbastanza consolidati su come spiegare e gestire questi vincoli. Sono fasi difficili per utenti non esperti, e implicano oltretutto la necessità di annotarsi le password, di digitarle nuovamente, aumentando il carico cognitivo su utenti che stavano già sperimentando un’utilizzo faticoso di un sito che doveva prima di tutto… essere rassicurante, poiché riguardava un’assicurazione sanitaria e proveniva dal settore pubblico!

Non basta, però. Quello che segue è un errore che, rivisto oggi, appare incredibile. Benché venisse alla fine richiesto di creare uno username case-sensitive, sia con lettere maiuscole che minuscole, l’email di reminder che veniva inviata presentava il login in maiuscolo, qualunque cosa l’utente avesse scritto!

Così anche chi copiò i dati dalla mail di appoggio sbagliò, e lo fece a causa del sistema stesso!

Figli minori di un progetto

Questo insieme di errori, soprattutto se elencati tutti assieme, sembrano dimostrare una grande sciatteria nella progettazione. Invece sono tipologie di errori molto comuni, perché riguardano tutto ciò su cui di solito non si riflette in un tradizionale processo di progettazione. In esso ci si concentra molto, per esempio:

• sulla scelta delle immagini,
• sul layout,
• sul tono della comunicazione,
• sui wireframe
• sulle schermate, in particolare delle pagine principali e dei primi step del processo,
• sull’architettura informativa…

Quelli accaduti sono invece errori che non riguardano affatto questi “oggetti progettuali”. Dipendono dall’esecuzione vera e propria di procedure, che durante il processo di progettazione vengono eseguite di solito da esperti – a volte solo dai programmatori – che ne testano soprattutto l’esecuzione corretta.

Riguardano inoltre la progettazione di schermate e di materiali cui si dedica tradizionalmente un’attenzione limitata. Schermate di attesa, messaggi su come creare password o sugli step di una procedura… e a chi mai viene in mente di pensare al modo in cui è formattata una semplice mail automatica di sistema?

Sono oggetti “minori”, quasi invisibili, e che calamitano molte meno attenzioni in fase progettuale di quanto sarebbe invece necessario. Perché richiedono una mentalità anti-confirmativa: ovvero ci vuole che qualcuno pensi agli scenari peggiori, non alle cose che funzionano.

E’ chiaro che il riferimento ai diversi “touchpoint” di un progetto, terminologia legata al settore del cosiddetto “service design”, design dei servizi, serve proprio a focalizzarsi su tutti i punti di contatto fra utente e sistema, non solo su quelli più vistosi. E dunque gli approcci più recenti facilitano la soluzione di questi problemi. Stupisce a maggior ragione che un sito facente parte di un ecosistema complesso di “service design” come quello dell’Obamacare non ne tenesse conto.

Il test di usabilità: la miglior assicurazione per un progetto

C’è un modo “sicuro”, al di là della metodologia che adottate, per identificare precocemente questi problemi?

La risposta più ovvia è che – oltre a una buona direzione di progetto, che abbracci una mentalità critica senza stroncare la creatività – solo i test di usabilità consentono di osservare scenari che noi, progettisti, non immagineremmo nemmeno accadessero. I test di usabilità, in questo caso, si sarebbero dovuti fare ben prima della pubblicazione del sito, ma con il sito già funzionante (almeno nelle funzionalità essenziali). Per consentire il tempo necessario a porre rimedio a quanto si sarebbe evidenziato.

Ma uno dei problemi che soprattutto siti di questo tipo hanno – e lo abbiamo visto anche con la frettolosa pubblicazione di Verybello qualche anno fa e con le difficoltà che ha avuto finora l’attivazione di Spid in Italia – è che spesso la politica non sa gestire correttamente i tempi di un progetto basato su tecnologie internet. Forse perché lo confonde con un tradizionale progetto di comunicazione non interattiva.

Dopo una presentazione frettolosa e affrettata solo per rispettare alcune scadenze, il progetto di Verybello.it, che tante polemiche generò all’epoca, risulta oggi abbandonato, o in un generico stato di “redesign”.

O, detto in un altro modo, i tempi della politica – legati a consenso e annunci – non sempre si attagliano a quelli ideali di un progetto complesso. Quindi si arriva spesso a ridosso della pubblicazione senza esser riusciti a svolgere i test di usabilità pre-rilascio, perché concentrati sul lavoro necessario a garantire la messa online del sistema.

Cosa ci insegna questo episodio sui rapporti fra politica e tecnologia

Dal punto di vista della reputazione, non solo i progettisti ma anche i politici dovrebbero aver ormai capito che fare annunci roboanti su servizi tecnologici è un rischio che forse non vale la pena di correre, perché nessun servizio può essere, per definizione, maturo al momento del lancio.

Mentre, specialmente in tempi di antipolitica, le aspettative dei cittadini sono elevate quasi quanto il grado di sfiducia preventivo. E invece solo la presenza di una grande fiducia nell’emittente può salvare dalle figuracce informatiche.

Solo la fiducia preventiva genera tolleranza ai difetti

Si cita molto spesso, non a caso, il fatto che per anni la Apple abbia goduto della fiducia degli appassionati anche negli anni in cui i prodotti non erano a livelli ottimi.

Con le dovute differenze, lo stesso si potrebbe dire, ad esempio, per l’estrema tolleranza, o comunque le scarse critiche che la lunga gestazione della piattaforma di democrazia diretta annunciata ad horam dal M5S subito dopo le elezioni del 2013 ha invece richiesto, non venendo alla fine nemmeno poi pubblicata con le caratteristiche attese. Questo per dire che il problema, con questo genere di progetti, non è legato a un colore politico: la tecnologia è complessa e la politica ha esigenze di immediatezza spesso incompatibili con una buona progettazione.

Il rischio di una partita loose-loose è sempre molto alto. Il “caso Obamacare” ce lo ricorda. E, nel farlo, ci offre qualche ammonimento e una manciata di consigli:

• Pianificate in anticipo il tempo necessario per fare i test di usabilità sia durante le varie fasi di progetto (dove si spera vengano fatti), sia in fase di pre-lancio (e poi fateli davvero!)
• Pensate agli scenari peggiori già durante il progetto
• Curate anche i materiali apparentemente minori, comunque tutti quelli con i quali gli utenti potrebbero venire a contatto.
• Non create aspettative eccessive se non avete una base molto fidelizzata.

Nel nuovo articolo riprendiamo – per approfondirlo – un argomento oramai consegnato alla Storia della nostra disciplina, proprio nel momento in cui negli USA se ne discute per tutt’altre ragioni: l’Obamacare. Alcuni si ricorderanno che l’esordio della riforma sanitaria voluta da Obama non fu dei migliori, informaticamente parlando. Il sito ebbe molti problemi e rischiò di affossare la riforma.

Raccontiamo qui un po’ più nel dettaglio quei problemi, cercando di capire quali errori furono fatti e cosa questo ci suggerisca per i nostri progetti attuali.

Buona lettura!

Nel nuovo articolo parliamo di cos’è e perché abbiamo creato il Protocollo eGLU per test di usabilità semplificati per la PA. E come questo metodo si inserisca nel più ampio contesto della Discount Usability di nielseniana memoria. Cogliamo così l’occasione di spiegare che, no, discount usability non vuol dire usabilità gratuita.

E di spiegare anche perché il Protocollo eGLU è uno strumento che abbiamo realizzato per aiutare tutti: PA, privati, liberi professionisti e esperti di UX.

Buona lettura.

Mentre si fa un gran parlare (e giustamente) di servizi web, rimane sempre fuori dai radar una voce di costo informatico estremamente rilevante nella PA italiana: quella per lo sviluppo dei software a uso dei dipendenti. Nei più svariati settori: dagli uffici anagrafe, ai servizi sociali, al catasto, all’ambito medico-sanitario.

Il tema si interseca con quello dei servizi online rivolti al cittadino. Perché spesso questi operano sugli stessi “oggetti”, e spesso con funzioni simili, a quelli di questi software che possiamo chiamare di back-office. Ad esempio, se un cittadino può, che ne so, prenotare esami sanitari online grazie a un nuovo servizio online della sua Azienda Sanitaria, la funzione dovrà in qualche maniera utilizzare lo stesso database di prenotazioni sul quale opera anche il software dell’operatore dell’ufficio prenotazioni che riceve i cittadini allo sportello.

E così via: ogni cosa che si mette online per il cittadino, non opera in solitudine (tranne rari casi) ma interopera con basi di dati già esistenti su cui operano altri software, a volte di molte generazioni fa (quindi con logiche molto diverse da quelle che operano oggi attraverso le tecnologie web attuali).

La moltiplicazione dei software e dei pesci

Questa interoperabilità è ovviamente un problema. Ma c’è un altro problema, altrettanto occulto: il fatto che molti soldi vengano spesi per realizzare adattamenti continui alle nuove normative o alle modifiche delle stesse.

Un esempio su tutti.

Quando è stato introdotto il SIA, sostegno al reddito sperimentato in alcune regioni, le aziende informatiche regionali hanno dovuto (o avrebbero dovuto…) realizzare dei software per l’apertura della pratica con il cittadino che ne facesse richiesta, che comprendesse la registrazione dei dati, delle firme sui moduli, il possesso dei requisiti, l’accettazione delle condizioni, il calcolo dei parametri economici. A volte queste procedure richiedono una comunicazione fra diversi uffici (per esempio con i Centri per l’Impiego, o l’INPS). Insomma, sono cose che devono essere usate dagli operatori pubblici ogni giorno, se si vuole che il provvedimento venga attuato.

In molti casi l’applicazione dei provvedimenti come il SIA varia da regione a regione, a volte viene attuata in modo diverso anche in parti diverse della stessa regione: questo si traduce naturalmente in una moltiplicazione dei costi.

Spesso poi i tempi di implementazione delle misure normative sono estremamente accelerati, anche per ragioni di comunicazione politica. Questo fa mancare altrettanto spesso i tempi tecnici per un’analisi e una progettazione efficace, lasciamo stare orientata al cittadino, di questi software. Che poi vengono corretti in corsa. Quando vengono corretti, intendo…

Quando i costi si scaricano sui dipendenti

A volte si verificano casi in cui gli operatori pubblici sono costretti a iniziare a implementare le misure senza avere ancora la disponibilità del software. Raccolgono documentazione cartacea, obbligandosi poi a reinserire i dati nel sistema informatico non appena il software viene rilasciato.

Ma non solo: a volte, semplicemente, proprio per una scarsa linearità e prevedibilità delle norme, insomma, per incertezza politica, si preferisce aspettare prima di realizzare il software. Magari la norma cambia. Formalmente quindi la misura, la policy inizia ad essere attuata, ma senza fornire ai dipendenti gli strumenti per farlo.

Questo rende l’implementazione delle politiche inefficaci, e sicuramente la produttività dei dipendenti si abbassa… ma non per colpa loro! Quando si parla di inefficienza della PA, i media generalisti forse dovrebbero iniziare a parlare non solo dei “furbetti del cartellino”, che ci sono, ma sono una minoranza; ma pure delle condizioni nelle quali i dipendenti pubblici che vogliono lavorare si trovano costretti a operare. Non solo a livello informatico: ma anche a livello informatico.

Cambiare per cambiare, non importa a quale costo

Ma c’è dell’altro. Nell’esempio del SIA di cui s’è detto sopra, la sperimentazione è partita in alcune regioni da pochi mesi, e da poco si è deciso di sostituirla con una misura differente, il REI, reddito di inclusione. Ebbene, senza entrare nel merito dei singoli provvedimenti, che non ci competono: qualcuno si è posto il problema di quanto costi modificare/adattare i software per attuare questi cambi di politiche? Passare da una misura all’altra, dal punto di vista degli strumenti informatici?

E, se queste modifiche non vengono realizzate per ragioni di tempo o di costi, quanto ci costi in ore uomo buttate il lavoro dei dipendenti che sono costretti a operare senza lo strumento informatico, o con uno strumento informatico inefficiente, che provoca errori, danneggia i cittadini e aumenta lo stress lavoro-correlato?

E’ chiaro che una sperimentazione va fatta, per politiche di questo genere: ma non sarebbe meglio in quei casi evitare di produrre software diversi, per poi trovarsi ad aggiornarli o a sostituirli, e partire subito con un software unico per le diverse realtà locali che si candidano alla sperimentazione, magari fornito dallo Stato, e già pensato per eventuali successive modifiche qualora dalla sperimentazione si passasse a una misura definitiva?

Il sistema operativo delle applicazioni pubbliche

In tempi di design-jam, di codesign e di linee guida, utili ma ancora lente a produrre servizi online per il cittadino, vi è tutto un capitolo di produzione informatica grosso, rilevante, e completamente occulto nella PA italiana che contribuisce all’inefficacia e all’inefficienza della macchina amministrativa. E, no, non sono i dipendenti. Non sono le regole tecniche. Sono le decisioni dall’alto.

E’ possibile che l’annunciato “sistema operativo della PA” in fase di realizzazione dal team guidato da Diego Piacentini possa rendere presto più semplice sia la rapida implementazione di strumenti software (anche realizzati da soggetti diversi, che si troverebbero parte dell’infrastruttura realizzata e API ben definite), che più rapida una loro modifica. Togliendo discrezionalità alle molte aziende private che ci lavorano, velocizzando al tempo stesso il loro lavoro. Ce lo auguriamo, perché di questo ci sarebbe davvero bisogno, anche più di SPID.

Sarebbe bello se, ogni tanto, ne parlassimo.

Un’interessante articolo del programmatore Quincy Larson racconta molto meglio degli articoli della stampa generalista il dilemma che abbiamo davanti, come “operatori dell’informatica”. Uso questo termine, perché, anche se Larson la vede dal lato programmatore, il problema riguarda tutti noi: designer, analisti, progettisti dell’esperienza, esperti di interfacce, di usabilità, di architettura dell’informazione, di service design, e quante altre etichette volete assumervi.

Ed è un problema etico. Per nulla teorico, però.

Larson racconta fatti noti e meno noti di come 3 grandi aziende abbiano mentito, tratto profitto e ingannato, al punto da prendersi l’accusa di aver causato delle morti, grazie al software.

Uber, ovvero, come ti aggiro le leggi senza che tu lo sappia

Nelle città in cui non è ancora concesso a Uber di operare, a volte poliziotti in borghese tentano di prendere un passaggio sull’app Uber, con l’obiettivo di multare il conducente in flagrante. Uber ha trovato il modo di evitare i controlli di polizia in un modo molto ingegnoso: identifica i poliziotti sotto copertura riconoscendoli attraverso un incrocio di dati, sia dai social, sia, forse da altre fonti (Larson parla di una banca dati di carte di credito usate dalla polizia). Quando l’utente identificato come appartenente alle forze dell’ordine cerca il passaggio Uber, l’app mostra (a lui, e solo a lui) delle macchine fantasma. Che non esistono, e che lui non vedrà mai arrivare, perché l’app gli mostrerà che devono fermarsi a prendere un altro cliente, o che sono dirette altrove.

Di fatto, il poliziotto non riuscirà mai a incastrare alcun autista Uber abusivo. E rimarrà semplicemente convinto di essere sfortunato, e di non riuscire a prendere un passaggio perché capita sempre nel posto sbagliato al momento sbagliato.

Questa tecnologia, chiamata Greyball, è stata in uso dal 2014, ed è stata sfruttata sia in alcune città USA, come Portland, Las Vegas e Boston, sia a Parigi, in Australia, Cina e Corea del Sud.

Dopo essere stata svelata dal New York Times, e come risposta anche ad altre controversie, Uber ha annunciato una revisione del modo in cui questa tecnologia è stata usata, e ne ha proibito l’uso per aggirare l’intervento delle forze dell’ordine. Attualmente è in corso un’inchiesta federale sull’uso di Greyball dai potenziali risvolti penali.

Zenefits, o il più classico degli imbrogli sulla formazione

Ok, visto come noi in Italia sfruttiamo i soldi europei per la formazione, creando una miridade di corsi inutili, con il tasso di occupazione a seguire fra i più bassi d’Europa, può sembrare una frode ridicola. Ma se prendiamo sul serio le garanzie, non lo è. Zenefits produce software per la gestione di uffici assicurativi. Nel 2016 si è scoperto che, grazie a una estensione proprietaria per il browser, aveva aiutato le agenzie a far saltare ai nuovi assunti un corso online obbligatorio per avere l’abilitazione a operare come agenti assicurativi.

52 ore di corso, con tanto di quiz annessi, saltate, per consentire alle agenzie di sfruttare quelle ore facendo lavorare subito i nuovi arrivati. Un bel risparmio per le agenzie, una bella garanzia in meno per il cliente. Un imbroglio per i certificatori.

Volkswagen, le emissioni differenziali e i 60 morti

Lo scandalo emissioni del 2015 della Volkswagen è noto a tutti, perché abbastanza clamoroso da arrivare sui telegiornali nazionali. Meno noto è il meccanismo usato. In pratica, un software era in grado di identificare i pattern di regolazioni e parametri usati dagli ispettori per il test sulle emissioni, perché evidentemente differivano da quelli di uso comune.

Il resoconto delle emissioni veniva dunque alterato, ma, appunto, solo per le ispezioni.

In pratica, è come se il software funzionasse normalmente, e non fosse ingannevole, tranne durante i test. L’interfaccia di output mentiva, ma solo a poche specifiche domande: quelle che ponevano gli ispettori.

L’andamento del titolo Volkswagen con il crollo in corrispondenza dello scandalo di settembre-ottobre 2015

Rispetto agli altri casi citati, questo è anche il più grave. Volkswagen è accusata di aver venduto 10 milioni di macchine che inquinavano fino a 40 volte il limite consentito (negli USA).

Stime del MIT sostengono che questo avrebbe contribuito ad un aumento del cancro ai polmoni, causando una morte prematura di 60 persone solo in America.

Il farmaco adatto a tutte le situazioni

Un altro autore, Bill Sourour, in un altro articolo fa un altro esempio personale, risalente a diversi anni fa, quando venne incaricato di realizzare un sito informativo di carattere medico-sanitario. Questi siti avevano il divieto di reclamizzare direttamente dei farmaci, così il committente aveva richiesto che il sito ponesse domande all’utente sui propri sintomi e poi, qualunque fossero le risposte (tranne in caso di accertata allergia ai componenti, suppongo per evitare cause legali) che l’utente venisse comunque rimandato alla reclame di un farmaco specifico, sempre lo stesso, fingendo che fosse una scelta basata sulle sue risposte.

L’autore scoprì poco dopo aver realizzato l’algoritmo che il farmaco era sotto accusa perché aumentava, in una piccola percentuale di utilizzatori, le tendenze suicide!

Non è tutto: Sourour scoprì poco dopo che la sorella assumeva il farmaco e fece di tutto per convincerla ad abbandonarlo, per fortuna con successo. Naturalmente, non si sentì benissimo ad aver realizzato il software che guidava l’utente sul sito, e poco dopo si dimise dall’agenzia web per cui lavorava.

Il codice può mentire. E lo fa attraverso le interfacce

Il punto è chiaro, e anche ovvio: con il codice si può mentire. E si può anche uccidere: non per forza con intenzione, ma anche semplicemente con dei bachi, come il caso del software Toyota che causava involontarie accelerazioni che hanno ucciso almeno 89 persone.

Qui però ci troviamo di fronte a software che mentono consapevolmente. Ed è ancora più facile che farlo di persona, perché non c’è il contatto diretto con le persone (come nel front-end degli sportelli o nei call-center). E’ facile per i progettisti sentirsi a posto con la coscienza, anche se sanno che stanno progettando un meccanismo fraudolento, perché in realtà non lo stanno somministrando loro: svolgono solo un lavoro.

Ma dovrebbe essere ancora più chiaro che non è il codice a mentire: il codice fa quello che gli diciamo di fare. Il codice è il nostro discorso, la nostra retorica, l’architettura delle azioni e delle reazioni che noi progettiamo.

Poiché il codice è nascosto, sono le interfacce, quelle che alla fine dicono il vero o mentono. Perché è attraverso la componente di interfaccia che il codice agisce e si fa capire, si relaziona con gli utenti. Di questo potenziale manipolatorio avevamo già parlato in passato, e sappiamo che anche i social hanno un forte orientamento persuasivo. Qui andiamo ancora oltre: non modifichiamo solo la probabilità dei comportamenti, ma mentiamo agli utenti attraverso il codice.

L’effetto placebo dei codici etici

Il problema dell’etica nelle nuove tecnologie è presente almeno dagli anni ’40, quando Norman Wiener scrisse Cybernetics: Or Control and Communication in the Animal and the Machine. In seguito approfondì il tema con The Human Use of Human Beings.

Un codice etico è in realtà già in vigore per i membri dell’American Computer Machinery (ACM), la principale associazione e comunità di pratiche in ambito informatico. Ciò non ha impedito che anche in realtà informatiche nordamericane si realizzassero pratiche fraudolente attraverso il codice.

L’ACM sta provando ad aggiornare il proprio codice etico, con il progetto di licenziarlo entro il 2018.

Ma, proprio come i codici etici in ambito medico non garantiscono da medici imbroglioni, come potrà un nuovo codice etico in ambito informatico garantirci dalla presumibile crescente pressione da parte dei committenti a produrre codice e interfacce che servano soprattutto a difendere i loro interessi, piuttosto che il bene della società nel suo insieme?

Esiste un modo legale per difendersi?

Il tema da porsi è semmai se l’attuale impianto legislativo e sanzionatorio sia adeguato a scoraggiare comportamenti che poi, una volta messi in atto, sono difficili da scoprire, perché “nascosti” dietro algoritmi chiusi in una scatola nera, che potrebbero anche non rivelarsi mai come truffaldini in modo palese, se l’interfaccia mente bene. E molto diversi dalle tradizionali “frodi informatiche” di cui si parla di solito sui giornali, associate a imprecisati soggetti oscuri, esperti informatici solitari che agiscono individualmente o per conto del miglior offerente. No, qui parliamo di software ufficiali di grandi gruppi.

Il problema diventa quindi di metodologie di controllo, in primis, e in seguito di meccanismi di sanzione.

Un tema molto difficile da affrontare, e su cui è molto probabile continueremo a interrogarci ancora a lungo.

Ulteriori letture

Focus on Ethic sul sito dell’FBI

Professional code of ethics in Software development

Software engineering ethics

12 ethical dilemmas gnawing at developers today

Ethics and software development

An Introduction to Software Engineering Ethics

Professional Ethics of Software Engineers: An Ethical Framework

L’articolo di oggi ricalca in parte l’intervento che feci al World Usability Day di Torino nello scorso novembre, e si focalizza sui problemi che sembrano esserci con l’approccio mobile-first alla progettazione dei siti web. Almeno per come lo intendiamo noi oggi.

Partendo da alcuni dati, vediamo cosa sembra non andare in questo approccio, come alcuni grandi gruppi scelgano di interpretarlo, e cosa dovremmo comunque fare noi, nel nostro piccolo (più o meno grande che sia). Buona lettura!