Quando si progetta un prodotto, la prima cosa che si fa è conoscere le persone che lo useranno.
I prodotti sono pensati per essere utilizzati da milioni di persone, ma in realtà ogni interazione tra il prodotto/fruitore è personale.
Spesso si tende a considerare chi li usa come un gruppo coeso di persone dalle caratteristiche simili, o si fa una media partendo da caratteristiche più estreme. Ma la realtà è ben diversa da questa semplificazione.
Per questo motivo, altrettanto facilmente vengono etichettati come casi limite tutti quegli esempi di utilizzo che differiscono dallo standard pensato per quel prodotto.
Tuttavia, lo stesso parlare di “limite” è una forma di emarginazione. La realtà di fatto non è composta da un unico gruppo di individui tutti uguali con qualche eccezione che ci gravita intorno.
Chi userà il prodotto da te progettato, infatti, è un essere umano complesso con alle spalle una vita altrettanto complessa, in balìa di emozioni contrastanti che inevitabilmente influiranno nelle interazioni col prodotto.
Come designer, il mio lavoro è creare prodotti utili a chi poi si troverà ad adoperarli e agevolare il loro utilizzo il più possibile. Una domanda. Come categoria siamo davvero in grado di rendere il lavoro che facciamo adatto agli esseri umani?
E anche. Cosa significa progettare per gli esseri umani?
UNA QUESTIONE DI APPROCCIO
Design for Humanity significa tenere in considerazione tutte le forme della diversità umana – abilità, lingua, cultura, genere, età, e così via – per creare prodotti adatti al più alto numero possibile di persone.
Questo è ciò che si definisce inclusività, uno degli obiettivi principali da raggiungere nella progettazione della User Experience.
Avere un approccio inclusivo alla progettazione e quindi alla realizzazione dei prodotti, però, non è un processo nè facile nè scontato.
Faccio un esempio per spiegarmi più chiaramente.
Probabilmente ti ricorderai della polemica scaturita intorno ai primi software di riconoscimento vocale non in grado, o comunque in grande difficoltà, nel riconoscere le voci femminili rispetto alle maschili. Perché questo? La risposta è più semplice di quanto possa sembrare, perché le persone che si sono occupate di crearli erano in maggioranza uomini che di conseguenza tendevano a usare loro stessi come soggetti test e ad allenare il software con dati di altrettante voci maschili.
Per farti capire. Un software “sessista” non è certo il risultato che si auspicavano coloro che lo avevano ideato e realizzato. L’esclusione delle donne, infatti, non è stata intenzionale, eppure ne è il risultato.
Quando ci si focalizza troppo sulla risoluzione di un problema, ci si concentra molto sull’obiettivo perdendo di vista il quadro generale del progetto, diventando “ciechi” a problemi che potrebbero sorgere e far naufragare il progetto stesso.
Come detto in precedenza, ciascun prodotto è pensato per una massa di persone, anche se in fin dei conti l’interazione è una attività strettamente personale; nessuno insegna come prendersi cura di queste interazioni.
Per questo è importante mantenere una visione globale di quello che si sta creando, in modo da distinguere pattern e schemi ricorrenti e scegliere le soluzioni più appropriate per garantire l’inclusività. Questo tipo di approccio è frutto della capacità di mettere alla prova la visione del progetto. Ci sono a questo proposito alcuni esercizi che possono essere facilmente integrati in fase di progettazione per aiutarci ad avere un approccio inclusivo.
Vediamoli insieme.
IL DESIGNATED DISSENTER
Una figura centrale, presente – o meglio dovrebbe esserlo – in ogni team di progetto, in quelli più grandi se ne trovano anche di più. Il Designated Dissenter è una figura che ha il compito di mettere sempre in discussione qualsiasi cosa, a cominciare dalle ipotesi iniziali e dalle prime bozze di progetto, dai wireframe al copy, dalle interazioni ai possibili problemi che potrebbero presentarsi. Il suo ruolo è appunto quello di “dissentire”, mettendo così alla prova le scelte fino a quel momento fatte.
Obiettivo non è quello di denigrare il lavoro degli altri, ma di fornire una direzione più umana al progetto e prevenire errori in cui si potrebbe incappare. Il Designated Dissenter dà suggerimenti per eseguire le cose nel migliore dei modi, e sarà sempre alla ricerca dell’alternativa vincente.
Questo tipo di figura è molto utile per individuare i presupposti – dichiarati e non – alla base di un progetto e di conseguenza capire cosa succede o potrebbe succedere se tali requisiti non fossero corretti.
Negli esseri umani, la tendenza a conformare il proprio pensiero a quello degli altri è naturale, in fin dei conti siamo programmati per cercare l’armonia. Altrettanto facilmente in un gruppo di individui molto intelligenti si può perdere il proprio punto di vista per omologarsi al pensiero di gruppo.
Il Dissenter assicura la presenza di un’opinione diversa rispetto alla maggioranza, consentendo comunque agli altri la libertà di espressione individuale e indipendente.
Un compito non facile come potrebbe sembrare a prima vista, infatti non è mai la stessa persona nei vari progetti, ma di volta in volta lo scettro di “signor no” passa a qualcun altro. “Designated Dissenter” non è un job title, ma un ruolo utile da sperimentare almeno una volta nella propria vita lavorativa.
Quali sono le domande da porsi come Designated Dissenter?
Alcuni esempi:
Cosa stiamo dando per scontato su chi userà questo prodotto / funzionalità / sito / altro?
Quali le ipotesi che stiamo facendo?
E se fossero sbagliate?
Cosa accadrebbe se i nostri presupposti fossero in parte o totalmente sbagliati?
E se provassimo a sovvertire le ipotesi?
Quali i risultati delle ipotesi sbagliate?
E nel caso di errore, come poter riparare o limitare i danni fatti?
Ho fatto appositamente degli esempi molto generici, perché l’elemento centrale è porsi continuamente delle domande, mettere tutto in discussione e non dare mai nulla per scontato. Anche senza una figura dedicata è buona pratica integrare questi accorgimenti all’interno del team di progetto.
POST-MORTEM E PRE-MORTEM
Può essere che tu abbia partecipato a quelli che sono definiti dei post-mortem di progetto oppure hai già sentito la definizione e ti suona familiare.
Per post-mortem si intende il momento in cui, a fine progetto, il team si riunisce per discutere di cosa è andato bene e cosa è andato male durante il percorso, così da imparare dagli errori e consolidare le best practice.
Cosa accadrebbe se si invertisse il processo? Ecco che il post-mortem si trasformerebbe in un pre-mortem da farsi all’inizio del progetto.
Il pre-mortem è un esercizio di pianificazione che capovolge il format e viene condotto prima o anche durante l’inizio del progetto stesso.
Come si svolge?
Innanzitutto, è necessario riunire chi è coinvolto nel progetto: il team che ci lavorerà e gli stakeholder, ossia coloro che hanno un qualche tipo di influenza o interesse.
Durante l’incontro si spiega il piano di progetto, in modo che siano tutti allineati.
La persona che conduce il meeting inizia con l’ipotizzare uno scenario di fallimento del progetto e chiede ai partecipanti di elencare una serie di motivi che possono aver condotto a questa infausta situazione.
Ad esempio, “È stato ridisegnato il processo di registrazione sul sito di e-commerce, ma le iscrizioni sono calate del 50% in un mese. Perché?”
A questo punto, ogni partecipante deve dare una risposta.
Si può scegliere tra vari metodi, come un brainstorming a voce alta o una risposta scritta individualmente, purché alla fine venga condivisa con tutti per svelare somiglianze, differenze, punti di incontro nel segnalare eventuali punti di debolezza esistenti a cui prestare attenzione durante il lavoro vero e proprio.
L’utilità di questo esercizio è quella di fornire a ciascuno uno spazio per sollevare delle preoccupazioni che altrimenti sarebbero riluttanti a condividere o di cui non si ha ancora coscienza.
Ci si accorge facilmente di come sia diffusa una certa abitudine a dare per scontato un risultato positivo nei progetti, e anzi, spesso c’è la tendenza alla concentrazione estrema sul risultato atteso, dimenticando di prestare attenzione a tutto quello che c’è intorno.
Questo tipo di concentrazione, come già accennato precedentemente, porta ad una visione “a tunnel”, che rende ciechi ai molti modi in cui il progetto può fallire.
La conduzione di un pre-mortem può essere d’aiuto a invertire questa tendenza, a prevedere e a pianificare in anticipo le mosse. Non sono io a dirlo, ma un vecchio detto: Prevenire è meglio che curare!
PERSONAS IMPERFETTE
Uno degli strumenti più usati nel progettare l’esperienza degli utilizzatori sono le Personas, personaggi di fantasia creati per rappresentare i diversi target che potrebbero usare un prodotto.
Solitamente la loro descrizione si basa su interviste con persone reali, le cui informazioni vengono sintetizzate e aggregate per creare degli archetipi. Possono anche essere completamente fittizie, nel caso in cui non sia possibile procedere con le interviste, come nel caso di prodotti nuovi che non hanno analoghi.
Dare un volto reale a dati astratti è cognitivamente stimolante e consente di concretizzare meglio le esigenze di chi poi si troverà di fronte al prodotto stesso.
Accade però, e con una frequenza piuttosto alta, che le Personas siano poco realistiche. Le foto profilo sono spesso immagini stock di volti sorridenti e perfetti, fotografie scattate apposta per essere belle, che finiscono per rappresentare l’utente “ideale”, piuttosto che l’utente reale.
Come fare quindi per rendere le Personas più umane?
Un piccolo consiglio. Puoi scegliere fotografie più realistiche che mostrino anche altre emozioni del soggetto oltre alla felicità, ad esempio stress, distrazione, o anche espressioni semplicemente neutrali. O anche immagini che ritraggano il soggetto in attività quotidiane.
Un altro piccolo passo è quello di aggiungere alla biografia del soggetto alcuni elementi di stress che la rendano più aderente alla realtà. In questo caso parlo delle sfaccettature di una persona che non sono riassumibili in un elenco puntato di caratteristiche. La vita è complessa e disordinata, e il prodotto verrà usato in situazioni tutt’altro che ideali.
Puoi quindi sfruttare “l’elenco puntato di caratteristiche” e arricchirlo di dettagli per ricordare che… chi usa un prodotto non è un utente astratto, ma un essere umano e, come tale, porta con sé una componente di imprevisto.
Puoi parlare di Anna, madre di due bimbi. Anna fa la spesa on-line perché preferisce dedicare il suo tempo alla famiglia e al volontariato. Inoltre, Anna sta attraversando un momento di difficoltà finanziaria, per questo tende a risparmiare e cercare sempre l’offerta migliore quando fa compere.
Tutte le informazioni contenute nelle righe precedenti sono utili nel processo di creazione ad esempio di un sito e-commerce di un supermercato, e sicuramente più valide dei generici dati anagrafici che di solito compaiono nelle stringate descrizioni delle Personas.
L’aggiunta di dettagli di stress nelle biografie delle Personas consente una maggiore comprensione del modo in cui i target definiti potrebbero comportarsi e cosa è veramente importante per lui/lei.
Quindi, prova a portare le Personas nel mondo reale della quotidianità e dei problemi e di conseguenza ti troverai a compiere scelte più umane nella progettazione.
CONCLUSIONI
Nel corso di questo approfondimento ho evidenziato dei piccoli accorgimenti utili alla realizzazione di prodotti inclusivi.
L’obiettivo non è cambiare il processo di costruzione, ma la visione del prodotto stesso incorporando pian piano gli accorgimenti nel lavoro di tutti i giorni, senza stravolgere nulla di già consolidato.
Poniti le giuste domande e…ricordati di essere umano!
TI È PIACIUTO QUESTO ARTICOLO? LEGGI ANCHE:
Cos’è una intranet e come crearla: UX Design del “Digital puzzle” aziendale
Dalla cassetta degli attrezzi del designer: il test di usabilità
