Progettare? Un punto di vista

In che modo possiamo avviare la trasformazione digitale di un servizio mettendo al centro i bisogni degli utenti? È la domanda che mi è stata posta da Designers Italia: rispondo attraverso questo Guest Post.

di federico badaloni

Progetto siti e applicazioni per il gruppo editoriale GEDI da diciassette anni. Potrei definirmi designer, oggi va di moda. Ma, soprattutto in italiano, ho sempre amato definire il mio mestiere con il suo nome: architetto dell’informazione.

Nel nostro Paese, designer evoca subito la forma, l’aspetto.
Progettiamo prodotti e servizi digitali, anzi, sempre di più “fisico-digitali” e ci occupiamo anche dell’aspetto, intendiamoci. Ma solo alla fine del percorso. Ci arriviamo dopo aver capito quali relazioni il nostro prodotto dovrà avere con le cose e le persone. Il nostro percorso parte dai bisogni delle persone e ci porta a ragionare sulle funzioni che il prodotto potrà assolvere per risolverli. All’estero, dove la parola design è associata più direttamente alla progettazione, questa visione delle cose si chiama user centered design: le persone sono al centro della progettazione.

Perché questo tipo di visione e questo metodo di lavoro dovrebbero interessare la Pubblica Amministrazione? Perché mettere le persone al centro è l’unica strada per cambiare davvero la qualità di quel che facciamo e le nostre organizzazioni.
Seguitemi, provo a spiegarmi meglio.

Perché innovare significa partire dai bisogni

Questo modo di lavorare porta innovazione. Se Henry Ford fosse partito dalle soluzioni, avrebbe inventato una nuova razza di cavalli veloci e resistenti, non un’automobile per le masse. Se parti dalle soluzioni in genere tendi a rifare quello che ha già fatto qualcun altro. Se proprio ti va bene, lo fai un po’ meglio. Ma perché innovare è importante? Perché succede spesso che nel frattempo il modo di risolvere il problema a cui ti sei ispirato sia invecchiato, cioè non sia più in grado di rispondere in modo adeguato ai bisogni delle persone. I bisogni evolvono di continuo, ma seguono traiettorie che è possibile riconoscere, se si guarda dalla giusta prospettiva. Per questa ragione identificare correttamente i bisogni è un lavoro delicato, che va compiuto attraverso tecniche specifiche derivate dalla ricerca etnografica.
E poi c’è il bias: la nostra tendenza a trovare conferme di ciò che crediamo. Quando cominciamo un progetto guardando in giro cosa esiste già, finiamo per convincerci della bontà della nostra idea prima ancora di aver preso in mano la matita.

Perché la progettazione basata sugli utenti fa circolare fiducia

Questo modo di lavorare ci fa guadagnare fiducia. Solo quando le mettiamo al centro della progettazione le persone tendono ad avere fiducia nel nostro lavoro: se abbiamo lavorato bene lo vedranno come la possibile soluzione ai loro problemi. In un ambiente in cui possiamo scegliere liberamente fra infinite connessioni possibili, l’unico criterio è la fiducia.

Perché la progettazione basata sugli utenti porta efficienza

Mettere le persone al centro del lavoro di progettazione vuol dire tenere in considerazione in ogni nostro intervento che il prodotto dovrà migliorare la qualità della vita di coloro che lo useranno.

In molti ambienti di lavoro, mettere al centro l’utente significa togliere da quel centro il dirigente di turno (altrimenti il nostro lavoro sarebbe uno stakeholder centered design!). È dura per lui scendere dal palcoscenico, per questo troviamo tanta resistenza nel rinnovare i processi. Eppure toglierlo da lì è proprio il modo di mettere al centro i suoi obiettivi. E raggiungerli. Perché i suoi obiettivi, in un’azienda o in un’amministrazione sana, coincidono con il servizio alle persone.

Avete notato? La progettazione basata sugli utenti ha effetto anche sul cambiamento culturale interno alle organizzazioni: accettare di lasciare il palco alle persone a cui sono destinati i servizi e i prodotti significa, inevitabilmente, toccare nervi scoperti, rivalutare gli obiettivi reali. Ma soprattutto, imparare a vedere le cose da un nuovo punto di vista: quello degli altri. Il miglior modo per imparare qualcosa.

A molti di noi capita di avere dei problemi per ciò che non va nella Pubblica Amministrazione e nelle aziende. Ma l’unico hack in grado di cambiare un sistema che non ci piace è progettare e realizzare qualcos’altro di buono che funzioni. Attenzione però: come ci ha insegnato Einstein, non possiamo risolvere i problemi con lo stesso modo di pensare con il quale li abbiamo creati.

Dunque, le persone al centro.
Ma poi come si progetta concretamente un prodotto o un servizio?

Progettare con il linguaggio

Risposta breve: con il linguaggio. Progettare è un atto linguistico*. Perché?

• Perché in un ambiente tanto complesso dobbiamo lavorare fianco a fianco con persone che hanno competenze diverse dalle nostre: dobbiamo capirci.
• Perché dobbiamo pensare: il linguaggio ci aiuta farlo in modo ordinato.
• Perché nelle regole del linguaggio c’è la logica con cui parliamo alla realtà: il codice e l’algoritmo nascono lì.

L’atto più rivoluzionario dell’architettura dell’informazione è scegliere l’utente come soggetto, non il prodotto. Un atto che si riflette in ogni comunicazione, in ogni pensiero, in ogni riga di codice.

Ora la risposta articolata.

Mappe e scenari

Per prima cosa, cominciamo da una mappa. Si tratta di una mappa che deve rappresentare lo scenario in cui ci muoveremo durante il percorso di progettazione.

Possiamo idealmente dividere gli aspetti da rappresentare in questa mappa in due aree. La prima area è ciò che emerge da una ricerca “interna”, come il tempo a disposizione, le risorse, gli obiettivi di ogni stakeholder, i limiti che esistono. La seconda è ciò che possiamo capire solo attraverso una ricerca “esterna”, nella quale usiamo le tecniche della ricerca etnografica per identificare i gruppi di persone che condividono gli stessi bisogni e che dunque tenderanno ad usare il nostro prodotto nello stesso modo. Questi gruppi sono descritti in forma di “personaggi” e vengono accompagnati da “scenari” che descrivono le circostanze nelle quali tenderanno a manifestare e risolvere i loro bisogni.

Per dare un’idea di questo lavoro, mostro qui sotto alcune immagini del lavoro compiuto per progettare Rep, l’applicazione che la Divisione Digitale del Gruppo GEDI ha realizzato per Repubblica, lanciata il 22 novembre.

Si tratta di una cosiddetta Progressive Web App (PWA): un sito che funziona (anche) come una app. Grazie a una tecnologia lanciata da Google di recente, le persone che usano una PWA, sebbene stiano navigando un sito con il loro browser, hanno un’esperienza d’uso molto simile a quella delle app: possono navigare anche offline, ricevere notifiche e avere un caricamento pressoché istantaneo delle pagine.

Il nostro gruppo editoriale è stato fra i primi al mondo a realizzare una Progressive Web App, contribuendo a migliorarne la tecnologia.

Ecco le immagini di alcune mappe realizzate dal nostro gruppo di lavoro.

A sinistra, noterete che un tipo di utenti è descritto come il personaggio di un trentenne laureato che abita una città italiana di medie dimensioni (Perugia, nell’esempio). I post-it rappresentano alcuni dei suoi bisogni: seguire notizie sui temi di interesse, divertirsi, socializzare, sentirsi utile. Nel corso del lavoro di progettazione, il team stabilisce quali bisogni prendere in carico.

Nell’immagine di destra c’è una tabella: la Journey Map. Una sorta di gioco dell’oca che rappresenta la relazione del personaggio con il prodotto, dove in ogni casella – che rappresenta un luogo o un tempo determinato – si annota lo stato mentale ed emotivo che egli avrà. Vi troviamo i task che vuole compiere, le domande che si pone, una descrizione dei punti di contatto (touchpoints), le sue emozioni, gli elementi di debolezza.

Finito questo lavoro di mappatura, possiamo cominciare a entrare nel vivo della definizione del prodotto.

Dai bisogni alle funzioni

Si comincia col definire la funzione principale** del prodotto rispetto ai bisogni delle persone che vogliamo servire. Tutto in una frase.

Per esempio:

• Repubblica.it: permette agli italiani di avere una panoramica di cosa succede in questo momento in Italia e nel mondo, attraverso i propri dispositivi connessi.
• Rep: permette agli italiani di vedere cos’è importante capire e ricordare ogni giorno, attraverso i propri dispositivi connessi.

Poi passiamo in controluce la lista dei bisogni mappati, osservandoli attraverso la lente della funzione principale del prodotto appena trovata. Per ogni bisogno formuliamo una frase che descrive la funzione che il prodotto compie per risolverlo.

Condividiamo questa lista di bisogni e macro-funzioni con tutto il team di progetto: non è in gergo. Può anche essere condivisa con gli stakeholders per spiegare loro a che punto siamo.

Formulare le macro-funzioni fa emergere gli elementi che saranno usati come i mattoni della costruzione del prodotto: i “concetti-soluzione”.

Per esempio, su Rep abbiamo il concetto di “contenuto” che viene ulteriormente qualificato dai concetti di “argomento”, di “tipo” e di “autore”. Nell’immagine seguente, che ritrae il titolo di un contenuto pubblicato nella homepage di Rep, troviamo tutti e tre i concetti: la testatina nera indica il tipo (“Commento”), quella rossa l’argomento (“Nazionale Di Calcio”). Sotto al titolo c’è l’autore.

La soluzione dei bisogni è data dalla relazione tra i concetti: quando progettiamo chiamiamo “funzione” il modo in cui avviene questa relazione. Un esempio di funzione: “il sistema suggerisce contenuti agli utenti loggati in base agli argomenti di cui hanno letto più spesso nella loro navigazione”.

Dalle funzioni alla struttura

Ora è il momento di suddividere le macro-funzioni in funzioni di maggior dettaglio. Per farlo, ci aiutiamo con varie tecniche di collaborazione fra i membri del team. Questo percorso ci aiuta a delineare anche la struttura delle informazioni e il modo ottimale di classificarle all’interno del sistema.

Per esempio, se affermiamo che il sistema, in una certa pagina, dovrà svolgere la funzione di mostrare alle persone tutti i contenuti che riguardano un certo tema, capiremo anche di aver bisogno del concetto di “tema” e dovremo capire contestualmente come formalizzarlo. Possiamo farlo in vari modi: attraverso un tagging aperto, oppure con una lista chiusa di categorie. Può anche darsi che, formulando altre funzioni, capiremo di aver bisogno di descrivere ogni “tema” con una serie di attributi come un titolo, una descrizione, un’immagine.

Formulando tutte le funzioni di cui abbiamo bisogno definiamo pian piano ciò che chiamiamo in gergo l’ontologia, la tassonomia e la coreografia del nostro sistema: cioè il significato degli elementi in gioco, il modo in cui sono organizzati e le regole attraverso le quali questi elementi interagiscono fra loro.

Su Rep, per esempio, abbiamo deciso di usare un numero finito di tag per descrivere gli argomenti di cui tratta ogni contenuto. Questa classificazione consente anche al sistema di inviare notifiche ogni volta che viene pubblicato un nuovo contenuto su un determinato tema.

Mentre navighiamo la app, possiamo cliccare su ogni argomento per raggiungere la lista di tutti i contenuti che sono stati prodotti a riguardo:

In questa fase del lavoro, ogni macro-funzione viene espressa con un grado di definizione sempre maggiore. Per farlo, suddividiamo ogni macro-funzione in tante sotto-funzioni che il sistema dovrà compiere in un ordine stabilito. In questo modo, le frasi che all’inizio del lavoro erano generiche, alla fine assomigliano a degli algoritmi, cioè a delle sequenze di istruzioni che il sistema dovrà seguire in determinate circostanze. Queste frasi dettagliate sono una risorsa molto utile per gli sviluppatori che dovranno trasformarle in codice.

Per esempio, la frase che descrive la macro-funzione “il sistema mostra alle persone tutti i contenuti che riguardano un certo tema”, potrà diventare: “il sistema individua in archivio i contenuti che sono stati descritti attraverso un determinato tema, ne estrae i titoli e li ordina in modo cronologicamente inverso alla loro data di pubblicazione”.

La definizione di ogni funzione può essere molto più dettagliata e precisa di così: questo grado dipende dall’accordo che stabiliscono i membri del team fra di loro e può variare anche da una funzione a un’altra.

Raffinare le macro-funzioni, insomma, ci aiuta a definire le caratteristiche della struttura interna di ogni contenuto. Nel nostro caso, stiamo assumendo che ciò che definiamo contenuto dovrà obbligatoriamente avere un titolo e una data di pubblicazione per consentire al sistema di svolgere una determinata funzione. In questa fase del lavoro, annotiamo questi elementi in un documento separato. Quando avremo finito con la definizione delle funzioni, questo documento descriverà proprio la tassonomia e la coreografia del sistema.

Attenzione: man mano che emergono gli elementi tassonomici, è fondamentale verificare che il nostro sistema, nelle forme in cui lo stiamo tratteggiando, sia sostenibile. Come flusso di lavoro, come fattibilità tecnologica, come tempi di sviluppo.

Dalla struttura alla forma

Viene infine il momento di progettare come i concetti-soluzione, o per meglio dire le informazioni di cui sono composti, prenderanno forma. La forma che assumeranno è subordinata alle interazioni che dovranno consentire alle persone: non posso realizzare una maniglia con un ramo spinoso solo perché lo trovo bello.

Uno dei punti di forza di questo metodo è che permette di progettare sistemi pervasivi, cioè sistemi in grado di gestire luoghi e oggetti sia virtuali che fisici.

Per censire e definire tutti i luoghi e gli oggetti in cui si articola il sistema, abbiamo bisogno di una seconda mappa. Alcune volte si tratterà di una mappa concettuale, altre volte sarà preferibile un semplice elenco testuale, come nell’esempio che segue (in inglese), sempre tratto dalla progettazione di Rep.

Queste mappe funzionali sono usate come base per definire i cosiddetti wireframes, che sono rappresentazioni schematiche di maggior dettaglio.

Ecco il wireframe di una pagina destinata a rappresentare un articolo di Rep:

I wireframes vengono utilizzati per realizzare la grafica. Ecco un confronto fra wireframe e la prima versione della grafica della pagina dedicata a un singolo contenuto su Rep:

Quasi sempre facciamo anche dei prototipi che simulano le principali interazioni e percorsi di navigazione. Le immagini qui sopra sono proprio tratte dai due prototipi che abbiamo realizzato per Rep: il prototipo di sinistra – costituito da wireframes – è servito a mostrare l’idea che avevamo maturato e a compiere i primi test di usabilità dei percorsi di navigazione; quello di destra è stato fatto dopo qualche tempo per dare un’idea dell’aspetto che avrebbe avuto la PWA.

Qui sotto, la stessa pagina nella grafica definitiva.

Con un prototipo è molto più semplice rendersi conto subito di eventuali incongruenze o difficoltà d’uso. È anche molto utile, quando lavoriamo in team, per stimare e guidare il lavoro di sviluppo. Infine, aiuta a far capire rapidamente agli stakeholders come verrà fuori il prodotto.

La progettazione funzionale dà ottimi risultati anche quando si lavora con il metodo waterfall, cioè a cascata, ma dà il meglio di sé quando si lavora con il metodo agile, con team multidisciplinari che includono tutte le figure coinvolte in un progetto: dal referente per il business al grafico, dallo sviluppatore al sistemista, dal project manager all’architetto dell’informazione.

Il linguaggio comune, non tecnico né specifico, con cui si definiscono le funzioni e il coinvolgimento di tutti i componenti del team sin dalle fasi iniziali del progetto, consentono a ognuno di liberare la propria creatività e incidere sul prodotto mettendo a frutto le proprie competenze.

Lavorare in questo modo cambia alla radice anche la cultura delle amministrazioni e delle aziende:

• nel modo in cui ogni membro del team si rapporta agli altri, perché in un team si dialoga da pari a pari;
• nel modo in cui si definiscono i rapporti gerarchici, perché il metodo funziona solo se ogni membro del team riceve dal proprio capo deleghe che lo rendano autonomo;
• nel modo in cui ogni membro definisce la propria responsabilità rispetto al prodotto finale, perché in un team il successo o la sconfitta non sono mai individuali.

Lavorare così è una sfida. Ma è una sfida senza alternative: solo accettando di sedere assieme a colleghi con competenze diverse, trattandoli da pari, mettendo al centro i bisogni delle persone, usando un linguaggio comune, possiamo progettare prodotti e servizi di successo, degni della fiducia delle persone.

Quando andrà particolarmente bene, innoveremo.
Perché saremo stati capaci di un nuovo sguardo.

* Cfr John Searle, Della intenzionalità. Un saggio di filosofia della conoscenza, Milano, Bompiani, 1985

** Nel libro Architettura della Comunicazione ho descritto più nel dettaglio questo metodo, che chiamo “progettazione funzionale”