NormaNielsenGroup ha recentemente dedicato un articolo alla attention economy, riconoscendone l’importanza per designer e utenti.

Forse il primo a parlare dell’attenzione umana come risorsa limitata che viene “consumata” dalla ricchezza delle fonti informative disponibili nel mondo è Herbert A. Simon, psicologo della Carnegie Mellon University, in un articolo addirittura del 1971.

L’articolo di NNGroup ha, al solito, il merito di semplificare. Online (e non solo online) esistono molte risorse gratuite che devono competere per il nostro tempo e la nostra attenzione. Io aggiungerei anche per i nostri dati, che spesso vengono raccolti, aggregati, e talvolta ricondivisi con altre aziende.

Tattiche con poco tatto

Questa necessità ha diffuso una serie di tattiche per mantenere l’attenzione e il tempo dell’utente su un sito o un’app. Non è una novità: anche le vecchie home page piene zeppe di contenuti e di banner, per esempio, erano un modo per sperare che almeno qualcuno di quei contenuti attirasse la nostra attenzione, e noi cliccassimo.

Oggi le tattiche sono rivolte, ad esempio, a mantenere il tempo di visualizzazione dei video, facendo partire in automatico il video successivo senza fornire modi per bloccarlo.

Altri modi sono l’offerta di sconti, di download gratuito, e naturalmente, su un piano più sottile ma non meno efficace, l’uso di microcontent, cioè di brevi testi usati come titoli o lanci sui social, pensati per attirare la nostra attenzione e curiosità. Questa è di gran lunga la tattica più usata, benché l’articolo di NNgroup non la menzioni. La tendenza a trovare formule verbali che “funzionano” può essere positiva, perché sintetizza l’utilità immediata di un contenuto (come negli esempi qui elencati), ma può anche arrivare ad effetti perversi, perché inducono al click senza che il contenuto rispetti o soddisfi la promessa del titolo, o semplicemente suscitando una curiosità morbosa che in partenza non avevamo e che di fatto non ci interessa poi molto.

Inoltre, come dice l’articolo, le persone adattano il proprio comportamento alle tattiche fraudolente, il che implica che queste devono sempre essere aggiornate.

Bersagli mobili

Da una parte questo “adattamento” offre delle speranze, dall’altra però ci ricorda che siamo dei bersagli mobili. Quello che l’articolo non sottolinea abbastanza, a mio parere, è l’enorme problema che queste tattiche pongono dal punto di vista etico a chi si occupa (o vorrebbe mettere in cima ai propri obiettivi) di usabilità, e in generale di mettere l’utente al centro del proprio lavoro. Il fatto che di alcune di queste tattiche gli utenti si lamentino o che il loro comportamento si adatti per evitarli e richieda di escogitare nuovi modi per attirare l’attenzione, pone un problema al designer. Stiamo progettando in un modo gradito all’utente, o solo gradito al modello di business?

E che fare quando il modello di business (tutto gratis, attirare l’attenzione per catturare tempo e dati da rivendere) non è nell’interesse dell’utente, senza che questo esplicitamente ce lo dica? È ancora possibile fare i designer ed essere etici, quando le indicazioni di business sono queste?

L’articolo, frettolosamente e ottimisticamente, conclude che, sì, si stanno diffondendo modelli a pagamento invece che gratuiti, all’interno dei quali queste tattiche possono essere evitate (ma lo saranno? E non è un nuovo modo per creare un divide fra have e have-nots?). O che Apple ad esempio ha recentemente accorpato le notifiche per presentarle a blocchi in intervalli di tempo predefiniti, invece che in tempo reale. O che ci rende consapevoli del tempo di utilizzo del dispositivo. E che quindi, in modi come questi, i designer possono contribuire a bilanciare meglio le esigenze dell’attention economy con il rispetto dell’utente.

Ma scelte di questo tipo sono davvero appannaggio del designer, o non sono forse strategie delle aziende per differenziare le fonti di entrate o per distinguersi e sembrare più rispettose della propria clientela rispetto alle altre?

Nel nuovo articolo parliamo di pattern: da dove vengono, cosa si intende, quali sono i cataloghi più noti. Ma anche del lato oscuro dei pattern: antipattern e i sempre più diffusi dark pattern.

Buona lettura.

I pattern sono configurazioni di soluzioni di design mirate a risolvere problemi comuni. Dall’architettura, dove sono stati ideati nel 19677 con il libro A pattern language dall’architetto e urbanista Christopher Alexander come un modo per catalogare e descrivere soluzioni consuete e utili a problemi ricorrenti (in realtà l’obiettivo era più ambizioso: quello di definire un linguaggio per i problemi di design e le soluzioni) i pattern si sono estesi al mondo del software (i software design pattern, in particolare nella programmazione a oggetti), e infine al mondo del design di interfacce.

Esempi di pattern online

Fra gli archivi online di pattern di interfaccia segnaliamo questa collezione che li divide per categorie e offre un bel po’ di esempi utili per i nostri problemi di UI design.

Un altro grande e storico repository che contiene anche molti esempi è Welie.com.

In entrambi i casi si noterà che alcuni sembrino datati: dipendendo sia dalle tecnologie che dalle mode, i design pattern in qualche modo evolvono, e alcuni cadono nel dimenticatoio per essere sostituiti da alcuni nuovi più adatti al nuovo contesto. Si pensi alla navigazione a doppio tab, oggigiorno praticamente scomparsa non perché non sia utile, ma perché difficilmente adattabile al contesto mobile.

Molti di questi pattern infatti sono specifici di una tecnologia, mentre oggi avrebbe senso non solo descrivere un pattern, ma anche il suo adattamento a diversi contesti fruitivi, desktop vs mobile in primis, ma non ho notizia di cataloghi che facciano questo.

Il lato oscuro dei pattern

Antipattern

Con il termine antipattern si descrivono solitamente dei pattern… negativi, nel senso che non ottengono il risultato ma creano problemi. Errori tipici di programmazione per quanto riguarda il software. Gli antipattern di interfaccia tipici sono… tutte le cose che non bisogna fare: inserire un’immagine di contenuto senza testo alternativo, un bottone funzionale solo con l’icona e privo di etichetta verbale. O usare un oggetto cliccabile (un link, un bottone) con un’area troppo piccola, che non tiene conto della legge di Fitts.

Dark pattern

Gli antipattern non vanno confusi con i dark pattern. Questi sono soluzioni di interfaccia pensate per ingannare l’utente e fargli fare cose che non vuole, ma che tornano utili solo al gestore del sito o dell’app. Non si tratta insomma di errori, ma di deliberati tentativi di ingannare l’utente.

Harry Brignull, che viene considerato l’ideatore del termine, mantiene un catalogo di dark pattern divisi in categorie.

Si va da:

• l’”infilato nel carrello” (sneak into basket), quando ci troviamo nel carrello spese di spedizione o altri servizi non presenti nel costo del prodotto ma indispensabili per completare l’acquisto,
• al “roach motel” (trappola per insetti, ma per assonanza anche una sorta di hotel Californa, dove si arriva ma da cui non si riesce a scappare), quando siamo incastrati in abbonamenti che non riusciamo a disdire (a me è capitato)
• fino agli annunci pubblicitari mascherati da parti del sito (ad esempio il bottone “download” per scaricare quel bel font è in realtà un link a un altro sito malevolo, mentre il vero download è in basso, piccolo e nascosto…),
• o a quei brutti tentativi di Windows 10 di farvi aggiornare il sistema operativo semplicemente chiudendo la finestra, come se fosse un consenso invece che un “annulla”.

Vi consiglio veramente di leggervele tutte. Troverete con buona probabilità situazioni nelle quali siete sfortunatamente già incappati.

Etica del design: un tema per il presente e il prossimo futuro

In rete si sta sempre più spesso parlando di etica del design, perché sono sempre di più i casi in cui le interfacce ingannano di proposito, sfruttando appunto pattern ingannevoli. Ne parla lo stesso Brignull in un articolo del 2011 su Alistapart.

Diversi eventi dello scorso World Usability Day erano orientati a parlare di interfacce “buone o malvagie”.

David Carroll, un professore di nuovi media statunitense che sta tentando un’azione legale in Gran Bretagna per riavere i propri dati rubati nel caso Cambridge Analytica, tentando così di porre l’attenzione sull’inadeguatezza etica (e normativa) delle grandi compagnie tecnologiche, ritiene che il mondo della UX abbia bisogno di un codice etico, e forse di qualche modifica normativa.

Noi ne abbiamo già discusso su Usabile.it parlando di interfacce che mentono (e con il recente caso di Intuit), e sottolineando come questi casi possano essere sempre scoperti solo a danno fatto, mentre, trattandosi di azioni progettate dalle stesse aziende (non compiute da qualche intruso o malintenzionato esterno), dovrebbero poter essere evitate a monte. Il come farlo, e quanto sia sufficiente un codice etico, o quanto modifiche normative che definiscano meglio tali comportamenti possano essere praticabili, è uno dei temi del prossimo futuro¹.

Foto: Bricolage 108, Flickr, CC BY-NC-SA 2.0

Intuit è una grossa azienda informatica e finanziaria statunitense. Fra gli altri produce un software per la compilazione della dichiarazione dei redditi negli USA chiamato TurboTax. Il software, sulla base di accordi con l’IRS, l’agenzia fiscale statunitense, dovrebbe essere gratuito a chiunque guadagni meno di 66.000 dollari. Sembra però che l’azienda abbia usato una serie di tattiche fraudolente per ingannare questi contribuenti e far utilizzare loro una delle versioni a pagamento.

Lo rivela una serie di articoli di ProPublica, importante sito di giornalismo investigativo no-profit (ha vinto 4 premi Pulitzer), che sta pubblicando un resoconto piuttosto dettagliato dei trucchi usati, un vero campionario di azioni che dimostrano, come su Usabile ho già raccontato in passato, come sia relativamente facile ingannare gli utenti attraverso le interfacce.

Queste tattiche includono:

1. L’uso fuorviante dell’espressione “Free File Program” sia sul sito di TurboTax che nelle pubblicità e nelle comunicazioni social, per far credere che sia la versione gratuita per chi guadagna meno di 66.000 euro. In realtà tale versione si chiama “Freedom File Program”, ma non viene quasi mai menzionata, se non proprio nel sito dell’IRS.
2. Il fatto che alla versione “Freedom” si possa accedere solo da un sito separato, diverso da quello principale che è invece quello reclamizzato da Intuit.
3. Che Intuit abbia lavorato per non far indicizzare quel sito a google.
4. Che nella procedura che stabilisce quale versione sia più adatta a noi, si venga alla fine spesso instradati verso versioni a pagamento, usando come pretesto presunti dettagli dello stato del contribuente che non sono però quelli inclusi negli gli accordi con IRS. Gli autori del reportage hanno simulato la ricerca della versione gratuita fingendo di avere diverse caratteristiche, ma mai riuscivano ad accedere alla versione che secondo gli accordi sarebbe spettata loro.
5. Ai militari americani proponevano addirittura dei messaggi con sconti dedicati mirati, facendo con ciò credere di non aver diritto alla versione gratuita.

Quelli utilizzati da Intuit, che ora è sotto indagine da parte del governatore Andrew Cuomo, sono veri esempi di DarkPattern, tattiche per ingannare l’utente attraverso l’interfaccia e il modo di procedere, cui è molto difficile scampare.

Intuit non è l’unica azienda a produrre software di questo tipo, e non è nemmeno l’unica finita sotto indagine. Anche H&R Block, fra le altre, ha ricevuto una citazione per ragioni simili, forti anche di alcuni memo interni che attestano quanto le strategie fossero deliberate. Entrambe le aziende hanno dichiarato di collaborare con gli investigatori.

In molti si chiedono (come avevamo già fatto su usabile.it) se non sia finalmente il caso sia di definire sia un codice etico per la UX, sia leggi specifiche che sanzionino l’uso di azioni ingannevoli attraverso le interfacce e le interazioni digitali a tutela degli utenti.

La maggior parte delle volte le icone dovrebbero essere ad accompagnate da label testuali che ne spieghino il funzionamento, tanto più in interfacce che non sono pensate per un uso ripetuto, ma occasionale. Ci sono casi in cui questo si può evitare, ma sono casi rari e ragionati, su cui torneremo prossimamente.

Pur essendo una regola/convenzione sperimentata ultracecennale, capita ancora di vedere moltissime icone senza label. Raramente però ho visto addirittura interfacce con icone senza label ma con… un pdf da scaricare con istruzioni che spiegano le icone! Così:

Il testo in rosso non l’ho aggiunto io come potrebbe sembrare: era proprio presente nel PDF!

Avete capito bene: un pdf da scaricare a parte, con il testo in sovraimpressione che spiega – su due righe! – le tre icone, piccole e ravvicinate. Non è difficile immaginare cosa sia successo: il software è stato fatto, arrivano le prime lamentele degli utenti, ma le modifiche sono:

1. troppo costose, o
2. impossibili perché il contratto è chiuso/scaduto/ci manca il personale/è un prodotto a scatola chiusa/l’informatico si incaponisce sostenendo che va bene così e sono gli utenti che non capiscono.

l’Urp o chi per lui, per evitare di rispondere a decine di mail, prepara un pdf. Con il risultato paradossale di avere un manuale di istruzioni per un’interfaccia lacunosa, che potrebbe essere sistemata con un intervento risibile: si potrebbe cogliere anche l’occasione per separare un po’ di più le icone, sfruttando lo spazio che peraltro esiste.

La vera malattia dell’informatica nella PA

Di casi come questi sono purtroppo pieni i software in uso nelle PA, sia per utenti registrati che per dipendenti (tornerò con qualche aneddoto nei prossimi giorni). Questo esempio è interessante per ciò che ci fa capire della difficoltà a ottenere modifiche banali in enti di questo tipo, per ragioni organizzative, amministrative, procedurali, contrattuali.

Ed è anche la ragione per la quale sorrido (amaramente) quando si parla di usabilità nella PA, o anche – perdonatemi – di un tema che sarebbe serissimo, come la trasformazione digitale. Più mi capita di dare il mio contributo, infatti, più capisco che il problema sta a monte, non dipende dalle redazioni web, ma da come sono gestiti i progetti e dai requisiti presenti in origine nei contratti.

A chi stende il Piano Triennale, per esempio, o a tutti i professionisti (me incluso) che predicano la semplificazione, chiedo una cosa molto semplice: come si fa, secondo voi, a situazione vigente, a risolvere casi come questi nel modo che sarebbe logico, con modifiche rapide dell’interfaccia, senza un aumento della complessità come invece prodotto dalle “pezze” che il pdf cerca di apportare?

La domanda non è retorica. Se qualcuno ha delle idee, sono lieto di sentirle.

Il Piano Triennale 2019-2021 ha inserito l’usabilità fra gli scenari, gli obiettivi e le azioni. Nonostante evidenti passi avanti, spicca il fatto che tra gli strumenti di riferimento per l’usabilità sia citato il solo Protocollo eGLU, dicendo oltretutto che deve essere:

1. usato dalle PA stesse (non da aziende terze che lavorano per la PA) e
2. a costo basso o nullo.

Qui urge perciò una precisazione. Del Protocollo eGLU, che assieme a Simone Borsci ho coordinato per conto del GLU, Gruppo Lavoro Usabilità della Funzione Pubblica, si possono avere diverse visioni. Di suo è una procedura passo-passo per l’esecuzione di test di usabilità semplificati, con raccolta anche di qualche semplice metrica utile per valutazioni e comparazioni.

L’uso che se ne può fare, però, è vario e molteplice, e dipende dalla strategia globale che viene suggerita o indicata alle PA.

Primo uso possibile

Il Protocollo può benissimo essere un modo per “farsi i test in casa”, e magari, identificati i principali problemi di un sito o di un servizio, richiedere delle modifiche all’azienda incaricata. Lo possiamo vedere anche così, ma così svalutiamo e riduciamo l’usabilità a mera pratica “autosomministrata” nel tempo rubato al lavoro da persone che hanno un’altra mansione, e che si avvicinano all’usabilità per la prima volta. Però è legittimo: il Protocollo è anche uno strumento di diffusione di conoscenza, per avvicinare ai test di usabilità, sebbene semplici, anche non esperti. Sarebbe davvero un peccato se nel contesto pubblico rimanesse solo questo. Ma soprattutto, sarebbe un vero peccato se si desse l’idea che l’usabilità tutta è solo test a basso costo avulsi dal processo progettuale.

E ancora peggio se, per effetto di questa “autosomministrazione dei test” nella PA, gli unici a guadagnarci fossero… le aziende che hanno in primis prodotto il sito, il servizio o il software che richiede modifiche. Perché è scontato che le modifiche verranno richieste a loro. Hanno prodotto un software subottimale, e ora gli diamo un nuovo incarico per correggerlo. Praticamente il business model attuale. Ma è proprio quel business model che va cambiato!

Secondo uso possibile

Un altro uso che si può fare del protocollo eGLU, invece, è considerarlo uno strumento di base, che offra anche una serie di metriche di valutazione che attestino un livello di qualità del prodotto. E quindi obbligare tutte le aziende a inserirlo, assieme a altre tecniche orientate all’utente (molte sono presenti su Designers Italia, assieme al Protocollo eGLU), nel processo usato per realizzare i prodotti informatici per la PA.

A questo punto, l’indicazione di specifici strumenti da usare nel processo dovrebbe modificare, si spera in senso virtuoso, e a carico delle aziende stesse, il modo di realizzare i prodotti, rendendoli più usabili.

Terzo uso possibile

Un altro modo ancora per considerare il protocollo eGLU è, in alcune circostanze, come uno strumento (di base ma estendibile) di valutazione da affidare a professionisti terzi sul livello di qualità raggiunto dal lavoro di un’azienda. Specialmente nel caso in cui quel prodotto informatico abbia impatto sulla produttività o sulla sicurezza (penso ai software in uso dagli operatori pubblici, più che ai siti informativi). Così, per esempio, nei capitolati si potrebbero inserire non solo il rispetto dei punti funzionali, ma anche un livello minimo di facilità d’uso al primo utilizzo, o di facilità di apprendimento, o di assenza di errori, in mancanza dei quali il lavoro non si può considerare correttamente svolto.

Finale non a sorpresa

Sono tre possibili modi di intendere il Protocollo eGlu, insomma. Due obbligano le aziende a modificare i loro processi e a realizzare prodotti migliori, uno invece non interviene sui processi e aumenta la probabilità per le aziende di ricevere nuovi incarichi, ovviamente pagati, per correggere ciò che hanno fatto male in primis.

Bene. Ora, leggete il Piano Triennale e provate a valutare da voi quale di questi tre possibili modi “strategici” di usare uno strumento in sé “tecnico” come il Protocollo eGLU è stato privilegiato. Quelli evolutivi, o quello che mantiene lo status quo?

Ehi, ma perché pensate male?

Io non l’ho detto.

In occasione dell’uscita (qualche mese fa) del suo nuovo libro Intranet Information Architecture, ho pensato di fare qualche domanda Giacomo Mason su un argomento di cui non parliamo spesso su usabile.it, le intranet. Ne è uscita un’intervista a mio parere piuttosto interessante per tutti, anche per coloro che non si occupano esplicitamente di Intranet, ma di progettazione digitale tout-court.

Buona lettura.

Un articolo di Nngroup sull’esperienza di checkout da mobile presenta un caso che è esemplare della differenza fra usabilità e user experience. Una delle indicazioni che l’articolo suggerisce è quella di fornire per ogni elemento inserito nel carrello un chiaro pulsante per la rimozione dell’articolo.

E tuttavia, l’esempio negativo mostrato è quello di un carrello che ha una tendina per modificare la quantità di quel prodotto, e nessun oggetto per eliminarlo. L’articolo riporta che per eliminare il prodotto dal carrello bisogna impostare la tendina a 0, e che questo ha causato frustrazione in molti partecipanti ai test.

L’esempio di un carrello senza un pulsante per la rimozione esplicita dell’articolo.

Le lamentele di praticamente tutti

Se dai test giungono chiare indicazioni sull’opportunità di creare un bottone esplicito, perché alcuni siti di ecommerce non lo fanno? Semplice: perché vogliono rendere più difficile, e quindi meno probabile, l’eliminazione di prodotti dal carrello. Non è poi nemmeno detto che questo tentativo di influenza non indispettisca l’utente: ciò che conta è che venga attuato un tentativo di influenzare il nostro comportamento per per massimizzare il mantenimento dei prodotti nel carrello.

Ovviamente l’alternativa “usabile” è simile alla seguente:

In questo caso vi sono pulsanti (o link) espliciti per la rimozione del mezzo. L’inserimento della possibilità “Salva per dopo” consente di aumentare la probabilità che l’articolo scartato venga ripreso in futuro, e la sua sola presenza limita la probabilità di perderlo per sempre senza ridurre l’usabilità del processo.

Tutto è user experience, ma non tutto è usabile

Il termine “User Experience” vale per tutte le esperienze, sia quelle che puntano a offrire massima libertà e agio all’utente, sia quelle che cercano di influenzare (anche senza obbligarlo) il comportamento dell’utente verso l’output desiderato dal committente.

Solo una delle due esperienze può essere considerata, però, “usabile”. Perché da un punto di vista di usabilità conta che l’utente possa svolgere il suo compito (che in quel caso sarebbe eliminare l’elemento dal carrello) con efficacia, efficienza e soddisfazione. E se con la tendina può comunque riuscire a svolgere quanto deve, lo farebbe certamente con maggior efficienza e soddisfazione se ci fosse un elemento di interfaccia esplicito che lo consenta, come nella seconda immagine sopra.

La differenza fra user experience e usabilità, di fatto, è tutta qui: mentre orientandosi alla user experience si bilanciano esigenze diverse, anche a costo di penalizzare l’usabilità, quando si mette al centro l’usabilità si mira al contrario a garantire l’esperienza migliore per l’utente.

Sia chiaro: l’usabilità non esaurisce da sola tutti gli aspetti importanti di una progettazione, e non è possibile pensare di aver risolto la progettazione solo scegliendo la soluzione più usabile. Ma l’usabilità dovrebbe rimanere sempre e comunque un aspetto non penalizzato dagli altri. Un aspetto su cui non si devono accettare compromessi al ribasso. È bene ricordare che un approccio generico alla user experience non garantisce di per sé questo risultato.

In occasione dell’uscita (qualche mese fa) del suo nuovo libro Intranet Information Architecture (qui su Amazon), ho pensato di fare qualche domanda Giacomo Mason su un argomento di cui non parliamo spesso su usabile.it, le intranet.

Giacomo è un Intranet designer che, dopo aver maturato un’importante esperienza dentro grosse aziende italiane, lavora come consulente per la progettazione di intranet aziendali. Contestualmente si occupa anche di formazione sui medesimi temi, ed è riconosciuto come uno dei principali esperti di intranet in Italia.

Il libro è un manuale sintetico e molto preciso sulle diverse sfide progettuali e sugli strumenti a disposizione dei progettisti nella realizzazione di intranet efficaci.

La prima cosa che ho pensato leggendolo, è: la progettazione di una intranet assomiglia dannatamente alla progettazione di un sito web (cosa che avevo pensato anche quando mi è capitato, alcuni anni fa, di lavorare a una intranet). Ma con delle differenze: l’utenza è interamente o quasi interamente nota.

Questo sembra un vantaggio. Tuttavia, lavorandoci, mi sono reso conto che entrano in gioco una serie di altri fattori che in altri progetti non ci sono: le dinamiche aziendali.

La prima domanda dunque è: corrisponde al vero questa impressione? O, per dirla in altre parole, quali somiglianze e quali differenze ci sono, o vantaggi e svantaggi, almeno secondo la tua esperienza, fra la progettazione di un ecosistema relativamente chiuso ma molto dinamico e con forte impatto sui processi interni come una intranet e un artefatto simile ma aperto verso un pubblico esterno (sia un sito, una app, un sistema interattivo più complesso)?

Il metodo è lo stesso, e il risultato finale può assomigliare in effetti a un normale sito web (uno di quelli con tantissimi contenuti) ma tutto quello che ci sta intorno cambia parecchio, e questo rende diversa la progettazione.

I dipendenti, ad esempio, sono il pubblico più difficile che esista, non solo perché costituiscono in genere un insieme disomogeneo (in azienda coesistono spesso anche 3 o 4 generazioni contemporaneamente, con diversi gradi di dimestichezza con il digitale) ma anche perché negli ambienti lavorativi ci troviamo di fronte a routine e rituali che creano una barriera al cambiamento: le persone spesso preferiscono proseguire con il vecchio-conosciuto-inefficiente piuttosto che adottare il nuovo-sconosciuto-funzionale. Questa resistenza non riguarda, ovviamente, solo gli ambienti lavorativi, ma in essi trova una sua giustificazione retorica: dobbiamo lavorare, e non abbiamo tempo per il “nuovo”.
Gli ambienti lavorativi sono attraversati, come tutti gli ambienti, da ”narrazioni unificanti”, da cornici di senso, e bisogna fare in modo che un progetto intranet trovi una collocazione all’interno di una di tali cornici (non necessariamente il “dobbiamo lavorare” ma in ogni caso in qualcosa che faccia parte del “paesaggio culturale” del momento in azienda).

Un altro elemento di differenza riguarda, ancora, le persone, questa volta dal punto di vista del coinvolgimento e della partecipazione attiva: progettare un servizio web esterno efficace e utile per le persone ci può far piacere, ma il nostro focus come progettisti restano i risultati di business: oggetti venduti, transazioni effettuate, efficienza misurata. Il coinvolgimento delle persone, il loro ruolo attivo, è solo uno strumento per ottenere questi risultati. Nel caso di un progetto intranet, invece, la partecipazione, il coinvolgimento, l’emancipazione e l’autonomia dei dipendenti sono un fine, oltre che un mezzo.
Questo rende le intranet progetti fortemente orientati all’HR, oltre che alla comunicazione o al miglioramento di alcuni processi.

Un terzo elemento differenziante sono le dinamiche organizzative: un’applicazione esterna vede in genere come referenti in azienda alcuni settori definiti (Comunicazione, Marketing, IT o un mix di queste figure), mentre una intranet, per sviluppare il suo potenziale, ha bisogno di tutta l’azienda: ci sono settori che ovviamente guidano il progetto (HR, IT, Comunicazione in genere), ma la intranet riguarda tutti. E questo complica non poco le cose.

Può una intranet contribuire all’evoluzione stessa di questi processi aziendali e di queste pratiche aziendali relativamente stratificate, a volte bloccanti e di difficile alterazione?

La intranet contribuisce certamente a cambiare pratiche aziendali stratificate e bloccanti, ma difficilmente può farlo da sola, come semplice variabile tecnologica: le persone sono molto brave ad “aggirare” le tecnologie se non percepiscono un vantaggio o se le vivono come una nuova minaccia alle loro routine. Sono necessari quindi anche altri ingredienti: supporto manageriale, accompagnamento al cambiamento e una strategia di progettazione condivisa

Oltre che un aggancio costante agli standard di design presenti all’esterno: non possiamo far vivere alle persone l’esperienza schizoide di un utilizzo all’esterno esterno dominato dalle UX fluide di Google, Facebook, Whatsapp e al contrario, una interazione con le applicazioni interne di basso, se non infimo livello.

Ecco, questo è un aspetto che si considera poco. Di fatto queste applicazioni definiscono lo standard, che definirei “modellante”, per le esperienze d’uso che diventano in breve l’aspettativa minima per i nostri utenti. Il che ci obbliga a una rincorsa perenne…

Sì. Dobbiamo quindi fornire un design che sia al passo con i tempi e con l’esperienza utente che le persone vivono quotidianamente. Il nostro compito di progettisti è contribuire ad aggiornare le aziende portando ed adattando al loro interno queste evoluzioni

E ci vuole, rassegnamoci, tanta pazienza e ostinazione. I processi aziendali non si cambiano dall’oggi al domani e bisogni fare i conti con tanti fattori di resistenza

Il libro è a mio parere adatto a tutti i progettisti digitali, anche a coloro che non sviluppano intranet, perché descrive, senza esplicitamente dire di farlo (lo si scopre un po’ verso la fine, diciamo) un vero processo di User Experience Design orientato all’utente. Altri, tra cui io, lo chiamerebbero Human Centred Design. Perché ritieni che questo processo orientato all’utente sia utile in una intranet?

Lavorare con gli utenti è indispensabile per vari motivi, innanzitutto per fare abbassare la cresta agli stessi progettisti: mi ricordo una collega che aiutavo nel gestire una sezione intranet con informazioni sulla concorrenza (ambito telco), dedicata alle persone del call center dell’azienda. La cosa è andata avanti liscia per parecchi mesi, fino a che la collega si è decisa ad andare fisicamente dai destinatari a vedere la situazione. Quando è tornata mi ha detto, un po’ scoraggiata “dobbiamo cambiare tutto”.
Ecco, lavorare con le persone ti aiuta a “cambiare tutto”. E poi c’è il fatto che se non coinvolgiamo le persone sarà molto più difficile superare le resistenze che, come ho detto, vanno messe in conto sempre.

Coinvolgere gli utenti non è solo più efficace ma anche più interessante (e divertente): non dobbiamo più solo “inventare” (posto che si possa isolare questa funzione nel processo di design) ma piuttosto ricombinare, tradurre, trasferire da un dominio ad un altro, affinare progressivamente.

Il nostro ruolo di progettisti è quello di fornire un know how modulare, come dei pezzi di un Lego che le persone useranno per costruire il proprio ambiente.

Nel libro mi concentro sull’architettura informativa, ma questo processo può e deve essere esteso a tutti gli aspetti della intranet: contenuti, design, interazioni, funzionalità. Non solo: possiamo farlo uscire dall’ambito intranet e dall’ambito digitale in genere: possiamo usarlo per progettare la formazione, i luoghi di lavoro, il welfare aziendale, il sistema organizzativo. Ci sono molti esperimenti in questi senso in giro per il mondo.

Tu proponi di costruire l’architettura informativa attraverso processi collaborativi con i dipendenti e i dirigenti, e in seguito di sottoporla a una serie di test empirici per valutarne la rispondenza alle necessità e arrivare a un fine-tuning. Questo modo di procedere, con il coinvolgimento massiccio del personale, incontra ancora qualche difficoltà in alcuni tipi di aziende, o è stato ormai digerito? In caso, quali leve possono essere utilizzate per spiegare i benefici di un approccio del genere, rispetto, magari, al privilegiare soprattutto le decisioni di chi ritiene di conoscere già le risposte o addirittura che l’intranet dovrebbe contribuire a imporre una visione aziendale calata dall’alto?

Se procediamo in modo rigoroso e trasparente le aziende sono in qualche modo “costrette” a seguirti. Di fronte ad un test dell’architettura che rivela problemi su delle aree è più difficile opporre resistenza.

Anche se questo avviene lo stesso, intendiamoci: i dirigenti aziendali sono dei campioni nel produrre ipotesi ad hoc per difendere il “nucleo metafisico” delle loro teorie, per parafrasare il filosofo della scienza Imre Lakatos. E allora viene fuori che un certo risultato che emerge dal lavoro con le persone non va considerato perché… (inserite motivazioni aziendali a piacere).

Non è un processo lineare, non siamo al CERN di Ginevra (e, chissà, magari anche lì, a ben guardare, troveremmo decisioni irrazionali e contorsioni “politiche”…)

Onestamente lo credo anch’io…

Tuttavia, quando i risultati cominciano ad arrivare, gli animi si rasserenano e le resistenze vengono meno. Il consiglio quindi è cominciare sempre con un ambito ristretto, nel quale ottenere rapidamente un risultato positivo, per poi estedendere il metodo a tutto il sistema.

Tu hai un’esperienza ventennale. Come sono cambiate le aziende e le culture aziendali in questi anni, se lo sono? Ritieni che sia più facile far accettare una logica empirica, iterativa e orientata all’utente, rispetto a un tempo, o esistono ancora resistenze, o, peggio forme di “adesione di facciata”?

Le cose sono cambiate moltissimo: oggi puoi trovare responsabili del personale che ti superano a sinistra nelle proposte (recentemente uno di loro ha proposto un sistema di valutazione della documentazione di marketing da parte dei venditori sul modello di Trip Advisor).

Oggi sono le aziende stesse che chiedono questi metodi, anche se ovviamente ci sono differenze nella sensibilità e nella cultura di ogni organizzazione e anche dei singoli settori: devo purtroppo rilevare, a questo riguardo, un certo arroccamento dei settori IT, che oggi sono, mi duole ammetterlo, i settori nei quali incontriamo le maggiori resistenze, e lascio ai lettori il compito di capire il perché.

Il libro su Amazon.

Ricordate il caso di Uber che aveva messo in piedi un programma, chiamato “Greyball”, per mostrare auto fantasma ai poliziotti sotto copertura che indagavano sulle sue pratiche? Ne abbiamo parlato su Usabile.it lo scorso anno, quando Greyball finì sotto indagine dal Dipartimento di Giustizia USA. Era un esempio con altri 3 di interfacce che mentono agli utenti.

L’evoluzione della storia, a indagine non ancora conclusa, ricorda la trama di una serie tv. A luglio infatti è stato annunciato che un avvocato che aveva lavorato al Dipartimento di Giustizia, Scott Schools, veniva assunto da Uber come Responsabile della Conformità aziendale (Chief Compliance Officer), una figura che si occupa di supervisionare le pratiche e le politiche di un’azienda e assicurarsi che siano in linea con le leggi vigenti nei Paesi in cui opera.

Si tratterebbe di un colpo di scena, perché, benché Schools non abbia lavorato direttamente al caso Greyball, conosce certamente bene i modus operandi del Dipartimento. Può quindi dare una grossa mano a Uber a uscire dai diversi casi, non solo quello delle auto fantasma, in cui è coinvolto. Questo episodio segnala anche quali sono le strategie che le grosse aziende, forti di consistenti possibilità economiche, adottano per uscire dai pasticci e continuare a prosperare all’interno dei contesti regolatori più diversi. Utilizzando gruppi di pressione, certo, ma anche assumendo direttamente persone che facciano da “ponte” fra mondi contrapposti.

In realtà la pratica ha una sua tradizione negli USA, e non va necessariamente vista come un tentativo di “fregare” il dipartimento. Negli USA la vedono anche come il segnale che Uber stia prendendo sul serio i suoi problemi e stia assumendo gente seria e competente nei posti chiave, dopo aver licenziato i responsabili delle precedenti scelte.

Il caso ricorda da vicino il personaggio di Liz Reddick Lawrence nella seconda stagione della serie TV di ambientazione legale The Good Fight, ideale sequel/spinoff del più noto “The Good Wife”. La Lawrence è un avvocato del Dipartimento di Giustizia che viene assunto da uno studio privato, dove fornirà fra le altre cose informazioni utili ad un caso che riguarda una delle associate dello studio, ufficialmente senza “tradire” il vincolo che le impone di non trasferire informazioni riservate ottenute nella precedente mansione.