APPUNTI_Programmazione_di_Interfacce PDF

Interazione Uomo Macchina per Informatici Daniele Mazzei, Dipartimento di Informatica Università di Pisa A.A. 2020/2021 2 Indice 1 Introduzione 5 2...

Interazione Uomo Macchina per Informatici Daniele Mazzei, Dipartimento di Informatica Università di Pisa A.A. 2020/2021 2 Indice 1 Introduzione 5 2 Progettare l’Interazione fra Uomo e Macchina 7 2.1 Interaction Design............................ 8 2.1.1 Product Design.......................... 9 2.1.2 User Experience Design..................... 11 2.1.3 User Interaction Design..................... 11 3 Human Centered Design 13 3.1 Usabilità.................................. 17 4 Progettazione delle interfacce 19 4.1 Design of Useful Things......................... 20 4.2 L’Incidente di Three Mile Island.................... 22 5 Principi Fondamentali dell’Interazione 25 5.1 Affordance................................. 25 5.2 Significante................................ 26 5.3 Mapping.................................. 27 5.4 Feedback................................. 28 5.5 Modello concettuale........................... 28 5.6 Immagine di Sistema........................... 29 6 Vincoli 31 6.1 Funzioni Obbliganti........................... 32 6.2 Activity-Centered Control........................ 33 7 How do people do things 35 7.1 I Golfi dell’Esecuzione e della Valutazione............... 35 7.2 I sette stadi dell’azione.......................... 36 7.3 I sette Principi Fondamentali della Progettazione........... 37 7.4 Pensiero umano.............................. 38 8 Errore Umano 41 8.1 Root Cause Analysis........................... 41 8.2 I cinque perchè.............................. 42 8.3 Definizione di errore........................... 43 8.4 Prevenzione dell’errore.......................... 44 9 Le interfacce utente 47 9.1 Classificazione delle interfacce...................... 49 9.2 Categorizzare le CUI........................... 50 9.3 Human Interface Devices......................... 51 9.4 Natural User Interfaces......................... 56 3 4 INDICE 9.5 GUI.................................... 58 10 UX Design 61 10.1 Personas.................................. 61 10.2 Requirements............................... 62 10.3 User Stories................................ 62 10.4 Scenarios................................. 63 10.5 Use Cases................................. 64 11 Metodi e Strumenti per l’Innovazione 67 11.1 Disruptive Innovation.......................... 67 11.2 Human Centered Design Process.................... 69 11.3 Design Thinking............................. 70 11.4 Agile, Scrum e DevOps......................... 73 12 Pretotipazione delle interfacce 77 12.1 Thoughtland, il mondo dei pensieri................... 78 12.2 Thoughts without data are just opinions................ 78 12.3 Pretotype vs Prototype......................... 79 12.4 Flusso del Pretotyping.......................... 80 12.5 Tipi di Pretotyping............................ 80 12.6 Minimum Viable Product........................ 83 Capitolo 1 Introduzione Negli ultimi anni il ruolo degli informatici è decisamente cambiato. Per anni l’infor- matico è stato chiuso in uno sgabuzzino ad interagire in solitudine con una tastiera, bevendo bibite gassate mentre qualcuno gli diceva che cosa serviva (o almeno era convinto di sapere cosa servisse) all’azienda per crescere. Poi sono arrivati Internet, gli smartphone, la banda larga e l’Internet delle cose (IOT) e tutto è cambiato. Oggi gli informatici sono diventati le nuove star! Il mondo è ormai tecnocratico e le nuove soluzioni informatiche e tecnologiche hanno la capacità di mutare la vita delle persone e gli andamenti dell’economia in tempi così veloci da far rabbrividire. Tuttavia, l’informatico è rimasto (spesso) in termini di attitudine e di bagaglio culturale lo stesso di prima. Li abbiamo fatti uscire dagli sgabuzzini, abbiamo messo loro una giacca sopra la maglietta di Star Wars e li abbiamo spediti sui palchi dei tecnoeventi a fare pitch. È chiaro che le competenze tecniche siano il bagaglio fondamentale per un in- formatico, ma in un epoca in cui le scelte degli informatici hanno la potenzialità di cambiare la vita delle persone non si può più prescindere da far capire agli informa- tici che cosa accade ad una persona “normale” (un non informatico, un babbano) quando interagisce con un software o con un sistema tecnologico in generale. Per troppi anni gli informatici hanno potuto limitarsi a sviluppare per i loro simili o al massimo per i loro capi. Ora che il frutto del lavoro degli scienziati dell’informa- zione è destinato alle masse è arrivato il momento che gli informatici studino anche i principi fondamentali dell’interazione uomo-macchina e uomo-computer. Questo corso è una trattazione adattata per informatici delle teorie di human computer (HCI) e human machine interaction (HMI) [interazione uomo-computer e interazione uomo-macchina]. Questo corso è ispirato alla teoria dell’interazione del Prof. Donald Norman ed in particolare, queste dispense sono in parte un adattamento didattico del libro “La caffettiera del masochista” di Donald Norman, pubblicato in Italia da Giunti e disponibile in lingua originale come “The design of everyday things, D. Norman”. Consiglio di acquistare il libro per avere una trattazione con taglio più narrativo e sicuramente più esteso ed approfondito di quanto qui riportato. Nel corso verranno trattati anche aspetti relativi all’Internet delle cose e alle interazioni con robot e altri sistemi “smart”. Questi aspetti legati all’interazione con oggetti smart sono anch’essi ispirati agli studi di Norman e sono ampiamente trattati nel libro “Il Computer Invisibile, D. Norman”, pubblicato in Italia da Apogeo. L’obiettivo di questo corso è quindi quello di fornire agli studenti del corso di laurea in Informatica gli strumenti necessari a comprendere e gestire il processo di sviluppo delle interfacce e dei prodotti interattivi. Questo corso ambisce quindi a 5 6 CAPITOLO 1. INTRODUZIONE spostare l’informatico dal suo tipico ruolo di sviluppatore per farlo diventare un progettista non solo del “codice” ma del prodotto nel suo insieme. Nel corso parlerò spesso di “prodotto” (nei termini di questo corso, viene definito come qualsiasi cosa un utente usi), “business”, “acquisto” e altri termini legati al mondo della vendita, dell’economia e del mercato. Questo perché l’informatico deve a mio parere sviluppare una consapevolezza fondamentale per il suo lavoro: un prodotto che nessuno compra è un prodotto inutile. Non importa quanto geniale sia il codice che avete scritto o rivoluzionario il sistema che avete implementato, se non vi curerete di far sì che questo artefatto venga apprezzato (e quindi utilizzato dalle persone) la vostra creazione, geniale o stupida che sia, morirà dentro il vostro computer. Per comprendere appieno la definizione di prodotto, si prende come esempio “Google” (motore di ricerca): è gratuito, è un prodotto che viene usato come servizio e ha una certa strategia di remunerazione. Queste dispense derivano dagli appunti di Simone Pepi e Francesco Iannelli pubblicati su GitHub e relativi all’ A.A 19/20. Queste dispense sono ad esclusivo uso degli studenti del corso di Pro- grammazione di Interfacce dell’Università di Pisa. È vietata la divulga- zione, copia o riproduzione in qualsiasi forma. Capitolo 2 Progettare l’Interazione fra Uomo e Macchina La rivoluzione tecnologica degli ultimi anni ha portato a parlare molto di User Experience Design, User Interface Design, Interaction Design etc. Cosa si intende con il termine Design? In Italiano tendiamo ad usare il termine design per riferirci sia al processo di progettazione che al risultato stesso di questo processo: (processo)“...È stato avviato il design dell’interfaccia grafica” (risultato del processo)“...Ecco il design dell’interfaccia grafica pronto per essere implementato” Per design si intende quindi sia il processo di progettazione e pianificazione sia il risultato di questo processo. È importante notare che nel mondo del design, ed in particolare nel design in- dustriale, si approccia alla risoluzione dei problemi e alla progettazione con una forma mentis molto diversa rispetto a quella “computazionale” tipica del mondo informatico. Nel 2006 Jeannette Wing, direttrice del Dipartimento di informatica della Car- negie Mellon University, formulò la seguente definizione di pensiero computazionale: “il pensiero computazionale è un processo di formulazione di problemi e di soluzioni in una forma che sia eseguibile da un agente che processi informazioni.” Il pensiero computazionale consiste nel pensare a diversi livelli di astrazione in modo tale da individuare sottoproblemi risolvibili con una serie finita di azioni atomiche (i.e. risolvibile da un “algoritmo”): è quindi un processo mentale che consente di risolvere problemi di varia natura seguendo metodi e strumenti specifici, pianificando una strategia; abitua al rigore e quindi rende possibili gli atti creativi. Permette di interagire con persone e strumenti, di fruire delle potenzialità delle macchine quali oggetti capaci di compensare le lentezze o l’imprecisione dell’uomo, se ben programmati. Nel modo del design invece, la progettazione è tipicamente affrontata in maniera globale. L’obiettivo principale del design di prodotto non è necessariamente quello di trovare una soluzione al problema specifico ma è piuttosto quella di comprendere il problema stesso nel suo insieme. Nel mondo del design il primo passo è sempre quello di capire perché il proble- ma esiste e solo dopo aver appurato che l’origine di un problema non può essere eliminata o mitigata ci si adopera per cercare di risolverlo nello specifico. Viceversa, l’informatico medio non appena si trova davanti ad un problema, apre il proprio editor di testo e inizia a scrivere un algoritmo per cercare di risolverlo senza neanche chiedersi se il problema che si sta affrontando esiste veramente. 7 8CAPITOLO 2. PROGETTARE L’INTERAZIONE FRA UOMO E MACCHINA Cosa vuol dire “se il problema esiste veramente?” George Berkeley, un filosofo irlandese del ’700 sosteneva che gli oggetti esistono solo in quanto percepiti. Dunque, se un albero cade in una foresta e nessuno lo sente, non fa rumore. Estesa al mondo dell’interazione uomo-macchina e dello sviluppo prodotto in generale, la filosofia di Berkeley ci dice quindi che se un problema non è percepito da un utente allora quel problema non esiste. Nel design dell’interazione e quin- di dell’esperienza utente l’obiettivo primo è (o almeno, dovrebbe essere) quello di avere un utente soddisfatto non un software teoricamente perfetto or super-ricco di funzionalità. Questo può portare a situazioni che dal punto di vista informatico sono percepite come assurde. Nel design di prodotto ci si trova infatti spesso costretti a modificare i requirement e le specifiche di prodotto per andare in contro alle esigenze degli utenti e sacrificando funzionalità tecniche e qualità dell’implementazione software. Trovare il corretto bilanciamento fra esperienza utente, funzionalità e qualità tecnica è la parte più complessa dell’intero processo di sviluppo prodotto. Nei prossimi capitoli introdurremo delle tecniche e dei processi atti a gestire questo processo in maniera scientifica e strutturata. Questo processo antropocentrico di adattamento del software alle esigenze del- l’utente piuttosto che al virtuosismo tecnico è spesso vissuto dalla maggior parte degli informatici come un’assurda violenza. Per questo motivo è molto importante che gli informatici studino i principi del design, perché il mondo del design antro- pocentrico è per i tecnici tipicamente molto molto complicato da metabolizzare in quanto distante dal pensiero computazionale. È importante evidenziare che design dell’interazione e pensiero computazionale non sono mutualmente esclusivi, anzi. È nell’unione dei due e nell’integrazione dei due processi di studio e progettazione che nascono prodotti di successo e software di qualità. “If we want users to like our software, we should design it to behave like a likeable person: respectful, generous and helpful.” Alan Cooper, software designer e programmatore, noto come “il padre del Visual Basic” 2.1 Interaction Design Il mondo della progettazione è diventato talmente ampio e variegato che il termine design da solo ormai non ha quasi più significato. Esistono varie sotto discipline del design e con queste numerose professioni, metodi di lavoro, scuole di pensiero e altrettante immancabili faide e lotte fra fazioni. Un informatico può fare a meno di conoscere al completo il mondo del design ma non può esimersi da possedere i rudimenti base del “design dell’interazione”. Interaction design, o progettazione dell’interazione, è l’attività di progettazione dell’interazione che avviene tra esseri umani e oggetti in generale. L’obiettivo principale dell’interaction design è quello di rendere macchine, servizi e sistemi usabili dagli utenti per cui sono stati pensati e realizzati e non solamente dai propri creatori. All’interno di un processo di interaction design, si investigano l’uso che verrà fatto dell’artefatto e il target a cui esso si rivolge. Questo significa che le questioni legate agli utenti guidano il processo più di quanto non facciano le questioni tecniche. Gli sviluppatori devono mettere al centro del processo di sviluppo i bisogni degli utenti, arrivando a realizzare un prodotto più appropriato 2.1. INTERACTION DESIGN 9 e maggiormente usabile. Le forze trainanti lo sviluppo di un prodotto dovrebbero essere quindi gli utenti reali e i loro bisogni e non solo le tecnologie. Nel nostro caso ci focalizzeremo sull’interazione fra uomo e sistemi informatici e quindi andremo a lavorare nel campo dell’interazione uomo-macchina e uomo- computer (in Inglese HMI Human-Machine Interaction e HCI Human Computer Interaction). L’obiettivo principale del HMI e HCI design è quindi rendere possibile e facilitare al massimo, per un essere umano, l’uso e l’interazione con sistemi del mondo IT (Information Technology) quali, calcolatori, dispositivi mobili, servizi web etc. Interaction design, HMI e HCI sono discipline molto variegate ed ampie che spaziano dall’informatica, alla psicologia, passando per la grafica e l’ingegneria. Capiamo meglio il mondo dell’Interaction design analizzando in dettaglio alcune sotto discipline del design: il design di prodotto, il design dell’esperienza utente e il design dell’interfaccia. Figura 2.1: Il design dell’interazione è un settore altamente interdisciplinare in cui si vanno a compenetrare diverse discipline. Prima di entrare nel dettaglio è importante sottolineare che nessuna di queste discipline o settori della progettazione è rigidamente definite e spesso le tre si intrec- ciano e vengono quindi eseguite da team multi disciplinari. Inoltre, specialmente in piccole aziende e piccoli team di sviluppo non si riesce a separare queste attività di progettazione e quindi è estremamente importante che l’informatico moderno cono- sca i rudimenti di base necessari per poter contribuire ad un team in cui vengono portate avanti anche questa tipologia di attività. 2.1.1 Product Design Il design di prodotto è un processo strategico di risoluzione dei problemi che guida l’innovazione e porta a una migliore qualità della vita attraverso prodotti, sistemi, servizi ed esperienze innovative (definizione ufficiale di disegno industriale coniata nel 2015 dalla World Design Organization (ex ICSID). Spesso design di prodotto e design industriale sono utilizzati in modo intercambiabile). Nel design di prodotto si progettano beni e servizi il cui obiettivo principale è quello di essere utilizzati da quanti più utenti possibili migliorandone la vita; dunque, il designer (di prodotto) è colui che inventa un nuovo modo o un nuovo oggetto per fare cose che fino a ieri non si potevano fare o si facevano in maniera più complicata. Riassumendo, il design di prodotto è il punto di partenza dei processi di innova- zione e rappresenta il punto di partenza del percorso di design dell’interazione che 10CAPITOLO 2. PROGETTARE L’INTERAZIONE FRA UOMO E MACCHINA stiamo esplorando; l’inventore (il designer del prodotto) si focalizza su un proble- ma da risolvere e inventa un prodotto che grazie alle sue caratteristiche tecniche lo permette. Descriviamo un prodotto noto come se stessimo provando a formalizzare un pro- cesso di product design atto a reinventare un processo noto e consolidato: ascoltare musica. Nome prodotto: Spotify; Problema a cui assolve: Ascoltare musica senza possederla; Tipologia di prodotto: Servizio basato su Internet; Funzionalità principale: Consentire l’ascolto di qualunque brano, su qualsiasi piattaforma senza richiedere l’acquisto di un supporto fisico e dei diritti d’autore; Soluzioni esistenti: Noleggio/prestito CD e altri supporti fisici, download di musica pirata; Soluzione: Servizio di streaming basato su business model “freemium” che di fatto rappresenta un jukebox con brani pressoché illimitati; Requisiti per l’utilizzo: PC o smartphone o tablet, Connessione internet. Estremizzando un po’ i concetti potremmo dire che il product designer di Spotify ha terminato il suo lavoro. Quello sopra descritto è il frutto del processo di design di prodotto che ha portato alla nascita di un servizio rivoluzionario come Spotify. Non c’è tanto altro da aggiungere per descrivere il concetto che sta alla base del prodotto e quindi l’innovazione che esso introduce. Figura 2.2: Business model canvas di Spotify (Fonte). È chiaro però che questo nuovo prodotto potrebbe essere realizzato in tanti modi e che sarà proprio il modo in cui viene costruito a decretarne il successo o il fallimento del prodotto. Questo perché non basta un’idea per fare un prodotto di successo, ci vuole un lungo e complicato processo di progettazione che vada oltre l’idea e metta al centro l’utente, i suo bisogni e le sue aspettative: inventare qualcosa che non esiste ma che non risulta davvero utilizzabile per gli utenti non è garanzia di successo; spesso i prodotti rivoluzionari sono quelli che reinventano cose già esistenti offrendo una esperienza utente migliore (si veda l’esempio di PayPal che risolve un “non-problema”). 2.1. INTERACTION DESIGN 11 2.1.2 User Experience Design Il design dell’esperienza utente è il processo volto ad aumentare la soddisfazione e la fedeltà del cliente migliorando l’usabilità, la facilità d’uso e il piacere fornito nell’interazione tra il cliente e il prodotto. La progettazione dell’esperienza utente comprende la tradizionale progettazione dell’interazione uomo-macchina e la estende integrandola con tutti gli aspetti di business, marketing e sviluppo prodotto necessari per garantire il successo del prodotto e/o servizio. Ogni prodotto durante l’utilizzo da parte di un utente porta a far vivere un esperienza e di conseguenza si dice abbia una sua “user experience”. Ovviamente, la user experience non è una proprietà del prodotto in se ma piuttosto una relazione che intercorre fra il prodotto ed uno specifico utente. Il tema delle relazioni e della relatività delle esperienze verrà meglio affrontato nei capitoli successivi. Lo UX Designer ha l’obiettivo di far vivere all’utente del suo prodotto la mi- glior esperienza possibile, evitando che l’oggetto induca nell’utente sensazioni di frustrazione e delusione. Spesso si tende a dire che si “progetta l’esperienza utente”. In realtà è impossibile progettare l’esperienza utente perché ogni utente è diverso dall’altro e illusorio pensare che chiunque durante l’utilizzo del prodotto si comporti alla stessa maniera e in particolare si comporti esattamente come il progettista ha ipotizzato. È corretto dire che si “progetta per l’esperienza utente”. Come vedremo nei capitoli successivi, lo studio e la progettazione dell’esperienza utente partono sempre dalla analisi e comprensione delle esigenze dell’utente e non dalle specifiche funzionali di prodotto. 2.1.3 User Interaction Design Il Design dell’interazione ha come focus il modo in cui le persone interagiscono con la tecnologia, lo scopo è migliorare la loro comprensione di ciò che si può fare, ciò che succede e ciò che è appena successo, basandosi su principi psicologici, tecnici ed estetici. Dallo studio della UX si crea uno schema di interazione che poi viene passato allo UI Designer che ha il compito di progettare l’interfaccia utente al fine di abilitare l’esperienza progettata. Figura 2.3: Esempio di progetto di UI per una App mobile. Il wireframe riporta le linee guida per la struttura dell’interfaccia e il flusso utente (implementato a partire dal lavoro di UX Design) (Fonte). 12CAPITOLO 2. PROGETTARE L’INTERAZIONE FRA UOMO E MACCHINA Lo UI designer non costruisce l’interfaccia utente, nei team numerosi questa figura è spesso un progettista grafico e non un informatico; il suo obiettivo è quello di progettare l’aspetto estetico e la struttura dell’interfaccia così che questa durante l’utilizzo induca l’utente nel seguire l’esperienza che è stata per lui progettata. Lo UI designer produce un wireframe, una bozza grafica dell’interfaccia e una serie di linee guida che poi verranno seguite dagli sviluppatori (UI developer o Front-end developer) per implementare la reale interfaccia del prodotto o servizio (ad esempio, è compito dello UI designer decidere quale sarà la posizione di un menù a tendina). Figura 2.4: Flusso di lavoro e ruoli necessari per lo sviluppo di un prodotto (Fonte). Il processo di Product Design è un percorso strutturato che include varie figure e discipline. In grandi team questi step sono eseguiti tipicamente da diverse persone e team ma spesso nella media e piccola impresa o startup questo percorso deve poter essere seguito in autonomia da una o al massimo due figure. L’interfaccia vera e propria viene implementata solo alla fine del percorso di pro- gettazione da figure con profilo tecnico informatico (Front End Developer o UI Deve- loper). Queste figure devono essere in grado di comprendere le richieste provenienti dagli step di progettazione precedenti e possedere i rudimenti base dell’Interaction Design e delle relative sotto discipline. Capitolo 3 Human Centered Design I progettisti devono produrre cose che soddisfino i bisogni della gente, in termini di funzioni, facilità d’uso e gratificazione emotiva. In altre parole, il design (di prodotto) deve essere pensato come un’esperienza totale (per l’utente). [Donald Norman — La caffettiera del masochista] Le persone sono sempre più frustate dalla complessità degli oggetti quotidiani. Dalla complessità sempre maggiore del cruscotto dell’auto, dalla lavatrice piena di incomprensibili funzioni e pulsanti, dalla crescente automazione della casa, e dalla continua proliferazione di funzioni che i progettisti aggiungono con orgoglio ad ogni nuova versione dei loro prodotti. La vita della maggior parte degli utenti è ormai diventata una battaglia quoti- diana per la sopravvivenza alla invadente e iper-funzionale tecnologia. Questo problema origina direttamente dalla modalità con la quale oggigiorno vengono progettati gli oggetti quotidiani ed in particolare quelli tecnologici. Le macchine (computer) hanno una modalità di funzionamento logica, dovuta all’algo- ritmo che il progettista ha sviluppato come anima della macchina. Noi umani invece siamo tutt’altro che logici e razionali, siamo intuitivi, flessibili, versatili e curiosi. È chiaro che nell’interazione uomo-macchina si va a creare una relazione fra specie diverse che hanno modalità di pensiero e di funzionamento opposte. Gli ingegneri e gli informatici, orgogliosi dei loro progressi tecnologici, hanno preteso da sempre che gli umani si adattassero alle loro macchine. Le macchine sono viste come un elemento di orgoglio che rappresenta il progresso e chi non è in grado di capirle è retrogrado, vecchio e a volte anche un po’ stupido. Questo approccio tecno-centrico dei progettisti ha in realtà leso lo sviluppo stesso della tecnologia dal momento che ne ha rallentato la sua diffusione e accettazione. La maggior parte degli utenti oggi è frustrata dall’utilizzo di incomprensibili oggetti tecnologici di cui non capisce il principio di funzionamento e dove tipicamente si limita ad utilizzare il 10% delle funzionalità disponibili. Le macchine hanno delle loro regole di funzionamento che sono spesso note solo ai progettisti. Quando non si seguono queste regole le cose non vanno come previsto e l’utente si sente stupido ed incapace. La macchina è perfetta, non può sbagliare, quindi se le cose sono andate male è sicuramente colpa dell’umano. È vero ma non è l’umano utente ad aver sbagliato, la colpa è del progettista! Nel design antropocentrico si inverte il paradigma di progettazione mettendo l’utente al centro del processo. Le funzionalità del prodotto vengono dopo. Prima ci sono i bisogni dell’utente! Questo processo, apparentemente ovvio e banale, risulta in realtà estremamente difficile da applicare per gli informatici. I tecnici infatti amano le funzioni e fun- zionalità, amano le peculiarità tecniche dei sistemi e sono spesso spinti a sviluppare 13 14 CAPITOLO 3. HUMAN CENTERED DESIGN nuove soluzioni non tanto per risolvere problema ma piuttosto per soddisfazione personale di aver implementato qualcosa che prima non esisteva. La blockchain è sicuramente un esempio di questo fenomeno. Creata per dilet- to da degli appassionati di crittografia, ha dato vita alla prima criptomoneta della storia. Dopo il boom di Bitcoin e delle altre criptomonete è scoppiata la bolla block- chain dove tutti nel mondo IT hanno iniziato a dichiarare che grazie alla blockchain si sarebbe potuto innovare in maniera radicale tantissimi settori. Ad oggi in real- tà dopo aver lanciato numerosi bandi di concorso in tutto il mondo, aver aperto fondi di investimento dedicati alle startup che utilizzano tecnologia blockchain non si è ancora trovata una applicazione di successo, oltre alle criptomonete, che senza blockchain non sarebbe realizzabile. Per dirla in altre parole, nessun utente ci ha chiesto di sviluppare la blockchain in quanto tale, c’era bisogno di scambiarsi denaro in maniera alternativa e quindi sono nate le criptomonete. Ora la corsa a cercare di applicare la blockchain ad altri settori non sta funzionando perché non esiste il problema da risolvere! Stiamo cercando un problema per una tecnologia ma bisognerebbe cercare tecnologie che risolvono problemi! La morale di questo ragionamento è: se vogliamo progettare tecnologia per le persone dobbiamo capire sia la tecnologia che le persone. Dobbiamo pensare a risolvere i problemi delle persone (non a crearne di nuovi perché dobbiamo bulimi- camente sviluppare nuova tecnologia) e smettere di progettare per le persone come vorremmo fossero e iniziare a farlo per come realmente sono. Figura 3.1: La tecnologia è percepita come utile quando è possibile comunicarci per risolvere insieme problemi. Questo vuol dire passare da un approccio tecno-centrico a uno antropocentri- co. Lo human centered desing o HCD, è una metodologia di progettazione che parte dai bisogni, dalle capacità e dai comportamenti umani, adattando la progettazione a quei bisogni, quelle capacità e quei comportamenti. Lo HCD è un approccio di design specificamente orientato allo sviluppo di siste- mi interattivi, con l’obiettivo di produrre sistemi utili, altamente usabili e che si focalizzino sull’utente. Il design antropocentrico è orientato all’efficienza ed all’efficacia e punta ad au- mentare la soddisfazione dell’utente durante l’utilizzo del prodotto e ad evitare il più possibile gli effetti negativi e indurre frustrazione. Prima l’utente, poi le features!. Lo HCD mette i bisogni, comportamenti e capacità umane prima di tutto e pro- getta in funzione di esse. Per questo motivo il processo HCD parte dall’osservazione  15 dell’utente, dei suoi comportamenti: dallo studio dei suoi bisogni per poi arrivare solo dopo all’identificazione della tecnologia necessaria. Il problema principale delle UI è la comunicazione fra uomo e macchina. L’in- terazione uomo-macchina è una forma di dialogo inter-specie; due soggetti aventi culture, corpi e lingue diverse si trovano a dover interagire per risolvere insieme un problema che uno dei due (l’umano) ha. Progettare interfacce che funzionano fintanto che le cose vanno bene è relativa- mente facile, ma la comunicazione è ancora più importante quando le cose non vanno bene. È qui che i progettisti devono concentrare l’attenzione, sui casi in cui le cose vanno storte, non su quelli in cui le cose funzionano secondo i piani. Questo approccio è valido sempre, non solo nello sviluppo tecnologico. Un buon avvocato scrive un contratto in previsione di cosa potrebbe andare male nella rela- zione fra le parti. Se le cose dovessero andare bene sicuramente le parti non avranno bisogno del contratto e questo verrà dimenticato in un cassetto. Il contratto diventa utile quando qualcosa va storto e se ben fatto rende la gestione del problema molto più semplice, veloce e potenzialmente indolore. È quindi bene focalizzare sempre l’attenzione su ciò che potrebbe andare storto durante l’interazione così da progettare accuratamente la comunicazione e guidare l’utente verso la risoluzione del problema così da ridurre la frustrazione e la negatività verso il prodotto. Non bisogna aver paura che l’utente abbia problemi o che il nostro software abbia degli errori o bug, è inevitabile che questo accada. È importante progettare perché l’utente venga guidato nella risoluzione e gestione dell’errore senza provare frustrazione. Avremmo così un utente soddisfatto. L’esperienza di utilizzo produce emozioni negli utenti, più emozioni positive (suc- cessi) l’utente avrà e migliore sarà la percezione che avrà del nostro prodotto. È im- portante sottolineare inoltre che la memoria ha la capacità di far provare sensazioni più profonde rispetto al presente. Un utente che di fronte ad un problema riesce a risolverlo perché ben guidato dalla tecnologia avrà memoria di un suo successo. Questo tipo di sensazioni sono molto forti e se associate al prodotto fanno si che l’utente sviluppi empatia per il prodotto e che lo apprezzi e ne senta il bisogno. L’obiettivo dello HCD deve dunque essere quello di creare nell’utente empatia verso il sistema. Riassumendo, l’HCD è una forma di pensiero (NON un’area o un metodo) compatibile con le varie discipline del design di prodotto che abbiamo precedente- mente introdotto: è infatti applicabile sia al design industriale sia alla progettazione dell’interazione o dell’esperienza utente. A sottolineare quanto l’HCD sia ritenuto oggigiorno fondamentale per la proget- tazione di sistemi destinati all’utilizzo umano, è importante ricordare che il design antropocentrico è ormai parte della norma ISO EU. 16 CAPITOLO 3. HUMAN CENTERED DESIGN ISO 9241-210: 2019 Ergonomics of human-system interaction Part 210: Human-centered design for interactive systems (Fonte). This document provides requirements and recommendations for human-centred design principles and activities throughout the life cycle of computer-based interactive systems. It is intended to be used by those managing design processes, and is concerned with ways in which both hardware and software components of interactive systems can enhance human-system interaction. Computer-based interactive systems vary in scale and complexity. Examples in- clude off-the-shelf (shrink-wrap) software products, custom office systems, process control systems, automated banking systems, Web sites and applications, and consu- mer products such as vending machines, mobile phones and digital television. Th- roughout this document, such systems are generally referred to as products, systems or services although, for simplicity, sometimes only one term is used. This document provides an overview of human-centred design activities. It does not provide detai- led coverage of the methods and techniques required for human-centred design, nor does it address health or safety aspects in detail. Although it addresses the planning and management of human-centred design, it does not address all aspects of project management. The information in this document is intended for use by those responsible for planning and managing projects that design and develop interactive systems. It therefore addresses technical human factors and ergonomics issues only to the extent necessary to allow such individuals to understand their relevance and importance in the design process as a whole. It also provides a framework for human factors and usability professionals involved in human-centred design. Detailed human factors/ergonomics, usability and accessibility issues are dealt with more fully in a number of standards including other parts of ISO 9241 (see Annex A) and ISO 6385, which sets out the broad principles of ergonomics. Un buon processo HCD parte, come abbiamo detto, dall’osservazione dell’utente e dei suoi bisogni. Tuttavia, tale osservazione non è sempre possibile o facile da attuare. Nei successivi capitoli analizzeremo varie tecniche di prototipazione rapida e metodi di lavoro finalizzati all’estrazione veloce di bisogni utente e all’esecuzione rapida e a basso costo di test. Possiamo schematizzare un processo di HCD come un flusso continuo ed iterativo che attraversa le seguenti fasi: Figura 3.2: Flusso di lavoro tipico di un processo di design antropocentrico (Fonte). 3.1. USABILITÀ 17 Specificare il contesto d’uso: identificare gli utenti che utilizzeranno il prodotto, per cosa lo utilizzeranno e sotto quale condizioni e vincoli; Specificare i Requirements: Identificare i business requirement e gli ob- biettivi utente che devono essere raggiunti grazie all’utilizzo del software; Progettare la soluzione: questa fase può essere a sua volta spacchettata in sotto fasi iterative. Si passa tipicamente dadelle bozze a dei prototipi e poi alla soluzione; Testare e valutare: è fondamentale testare e valutare il sistema così da poter iniziare il ciclo sulla base dei risultati dei test e procedere ad uno sviluppo e miglioramento incrementale. Per ora, al fine di inquadrare meglio la filosofia HCD nel contesto dello sviluppo software vi basti pensare che le versioni alfa e beta dei nostri software possono diventare potenti strumenti di analisi degli utenti. Le versioni di test non servono solamente a fare debugging del codice e delle funzioni, ma anche e soprattutto a capire che cosa fanno e come si comportano gli utenti durante l’utilizzo del nostro software. Nello sviluppo software diventa indispensabile abilitare dei sistemi di tracking dell’utente finalizzati alla produzione di statistiche di utilizzo. Avere zero errori (segnalazioni di bug) su una funzionalità che nessuno usa non vuol dire che questa sia perfetta ma soprattutto vuol dire che non aveva senso implementarla e quindi non ha senso mantenerla. Viceversa, avere alti utilizzi di una funzionale che era stata pensata come opzionale o accessoria ci deve indurre a pensare che invece gli utenti hanno trovato quel processo più utile e soddisfacente rispetto a quello che in fase di progettazione il designer aveva pensato come “principale” e fondamentale. Nell’a.a. 2021/2022 non è stata trattata la sezione immediatamente successiva. 3.1 Usabilità Secondo la norma ISO, per usabilità si intende il “grado in cui un prodotto può essere usato da particolari utenti per raggiungere certi obiettivi con efficacia, efficienza e soddisfazione in uno specifico contesto d’uso”. Sul sito dell’Agenzia per L’italia digitale si legge: L’usabilità è un carattere imprescindibile nella realizzazione di un portale web, perché permette di creare un ambiente familiare per l’utente, determinando numerosi vantaggi: consente di trovare e comprendere informazioni in modo più semplice e intui- tivo; facilita la memorizzazione e l’apprendimento dei contenuti presenti; permette una riduzione dei costi e degli errori di sviluppo; rende l’utente più autonomo e sicuro nel rapporto con lo strumento. L’usabilità mira a ridurre la distanza tra il cittadino e le amministrazioni, per- mettendo agli utenti di trovare le informazioni necessarie, comprenderne i contenuti ed eliminare le difficoltà di utilizzo di un determinato sito istituzionale. Si nota subito che il tema dell’usabilità è spesso associato esclusivamente al mondo del web e dello sviluppo di siti internet. L’usabilità è intesa come la disciplina che regola la costruzione del sito o applicazione sulla base delle esigenze dell’utente, cercando di semplificare la sua esperienza di navigazione. Questa è ovviamente un’errata semplificazione dovuta a come diversi in settori dell’informatica si siano adottate terminologie diverse per esprimere concetti simili se 18 CAPITOLO 3. HUMAN CENTERED DESIGN non equivalenti. Nel mondo del design di oggetti interattivi per esempio, l’usabilità è talmente importante che viene quasi data per assodata e il suo studio è spacchettato in diverse sotto attività quindi risulta più raro trovare delle attività dedicate allo studio dell’usabilità in quanto tale. Il tema dell’usabilità e del design antropocentrico si applicano (si dovrebbero applicare) a tutto il mondo dello sviluppo di prodotto. Ogni oggetto, artefatto, software o sistema destinato all’utilizzo da parte di utenti (umani) necessita che se ne studi la relativa usabilità e che intorno a questa si progetti il sistema stesso (HCD). Una risorsa molto interessante e ben fatta sul tema dell’usabilità di servizi de- stinati ai cittadini è https://designers.italia.it/. Sul portale, nato nel 2017, sono presenti numerose linee guida e forum di conversazione relativi allo sviluppo di software per la Pubblica Amministrazione. Figura 3.3: Il sito sopra citato mette a disposizione varie linee guida e strumenti per la progettazione antropocentrica di servizi dedicati alla pubblica amministrazione. Capitolo 4 Progettazione delle interfacce Esistono solo due tipi di design, riuscito e fallito; buono e cattivo. [D. Norman] Il problema è che il buon design non è universale. Un progetto, prodotto o sistema apprezzato da tutti non esiste perché l’esperienza di interazione è soggettiva e quindi dipende più dalla persona che non dall’artefatto e di conseguenza è statisticamente impossibile progettare qualcosa che sia apprezzato da chiunque. Nel corso vedremo come classificare gli utenti in gruppi e categorie così da poter identificare degli archetipi di persona per i quali andare a progettare l’interazione nella speranza di ottenere dei prodotti che almeno da alcune persone selezionate vengano apprezzati. questo perchè è bene ricordare che non è possibile progettare l’esperienza di un utente ma si può lavorare per progettare un prodotto che guidi l’utente verso una particolare esperienza da noi identificata come ottimale. Ci sono due proprietà che sono fondamentali per qualsiasi progetto destina- to ad essere utilizzato da persone: Discoverability (rilevabilità) e Understanding (comprensibilità). Discoverability: è la capacità di un sistema di veicolare e comunicare i propri possibili usi all’utente. Un sistema che a prima vista fa capire all’utente a cosa serve e che cosa ci si può fare ha una buona Discoverability. Per avere una buona discoverability si usa tipicamente la visibilità. Se le funzioni dell’oggetto sono visivamente eclatanti è probabile che l’oggetto abbia una buona discoverability. Un rubinetto con i pomelli ha una discoverability migliore di un rubinetto auto- matico perchè le sue funzioni sono più facilmente identificabili grazie a una maggiore visibilità dei controlli. Figura 4.1: Discoverability e visibilità. 19 20 CAPITOLO 4. PROGETTAZIONE DELLE INTERFACCE Understanding: è la capacità del prodotto di farsi usare correttamente dall’u- tente. Se la discoverability è la misura di quanto bene si capisce cosa si può fare con il prodotto, l’understanding invece è la proprietà associata a quanto bene un prodotto dice come si usano le funzioni disponibili. Per capire come si usa un prodotto non basta infatti aver identificato quali sono i controlli, è necessario dare con facilità risposta alle seguenti domande: Come si usa il prodotto? Che funzione ha ciascun controllo? Come si combinano i controlli?... Figura 4.2: Understanding. 4.1 Design of Useful Things Quando le cose vanno bene, si dimenticano subito, quando vanno male non si dimenticano mai! Questo fenomeno è noto a tutti, si tende a ricordare più facilmente le disavventure e i problemi che le belle esperienze, che spesso vengono percepite come ovvie e scontate. Questo accade perchè ormai viviamo in una società in cui le cose devono andare bene per definizione. Quando qualcosa invece va storto, scattano tutta una serie di reazioni che portano la persona a provare sensazioni e emozioni spiacevoli, tipicamente frustrazione. Questo è un processo neurologico del tutto naturale che consente agli uomini di apprendere velocemente dalla propria esperienza andando ad etichettare le espe- rienze spiacevoli come più importanti rispetto a quelle positive. Dal punto di vista evolutivo, sbagliare vuol dire rischiare la vita mentre fare bene è solo l’ovvio cammino per la sopravvivenza. Il design deve quindi preoccuparsi di come funzionano le cose, come vengono controllate e della natura delle interazioni che questi oggetti e sistemi abilitano con gli utenti. Gli oggetti, i software e i sistemi ben progettati danno vita ad esperienze d’uso piacevoli e rilassanti, quando un oggetto o un software sono mal progettati l’utente vive invece un’esperienza spiacevole caratterizzata da emozioni negative e dalla desiderio di evitare in futuro di doversi imbattere nuovamente in un’ esperienza simile. 4.1. DESIGN OF USEFUL THINGS 21 Questo vuol dire che una cattiva esperienza utente induce l’utilizzatore non so- lo ad abbandonare l’utilizzo di un prodotto ma soprattutto porta la persona ad etichettare il prodotto e l’azienda produttrice come da evitare. Le macchine sono concepite, progettate e costruite da esseri umani ma sono ben diverse dai loro creatori. Le macchine sono sistemi logici, deterministici, prevedibili e con comportamenti basati su algoritmi fissi. L’uomo è invece aleatorio, versatile, variabile, volubile, e intuitivo. Uno l’opposto dell’altro! Inoltre, le macchine non hanno esperienza (nell’accezione in cui la intendiamo tipicamente in neuroscienze). Per una macchina ogni azione, procedura e sequenza è nuova, si ricomincia sempre da zero. Non importa se l’utente ha già fatto quella procedura decine di volte, anche questa volta la macchina pretenderà che questa venga eseguita alla perfezione e seguendo tutti i passi richiesti. Inoltre, le macchine al nostro confronto, sono assai limitate. Non possono fare qualsiasi cosa in maniera mediocre come noi ma sono concepite per fare poche cose (spesso solo una) in maniera eccellente. Anche in questo caso hanno un compor- tamento opposto rispetto a quello umano. Gli uomini sono in grado di fare tutto in maniera mediocre e qualche cosa in maniera eccellente e possono inoltre, con l’e- sperienza, cambiare le attività su cui eccellono. Le macchine nascono in un modo e muoiono invariate. Le macchine seguono, di solito, regole di comportamento rigide, piuttosto complicate. Se si sbaglia nel seguirle, anche di poco, il sistema fallisce. La macchina esegue infatti quello che gli è stato richiesto, anche se questo è insensato e illogico. Questa analisi ci porta a concludere che le macchine obbligano le persone a smettere di comportarsi da umani inducendole a comportarsi da macchine. La tipica esperienza d’uso di un software è quella di un umano che impara le procedure imposte dal software, capisce come questo funziona, è stato progettato e inizia così a ragionare come lui. L’umano asseconda la macchina per poter ottenere un risultato e procedere nell’esecuzione dell’attività senza intoppi. We have to humanize machines instead of dehumanizing humans (David Hanson, Padre del robot Sophia della Hanson Robotics.) Questo condizione di schiavitù umana è dovuta al fatto che spesso le rego- le di funzionamento della macchina sono note solo alla macchina stessa e ai suoi progettisti. Come detto, quando non si eseguono queste regole segrete e bizzarre, la macchina fa la cosa sbagliata e la colpa è tipicamente accollata all’utente incapace. Quando questo accade con oggetti comuni, di uso domestico o personale, il risultato è la frustrazione dell’utente e il fallimento del prodotto. Quando invece questo fenomeno accade in contesti industriali e commerciali, le conseguenze possono essere incidenti mortali e importanti conseguenze economiche. È tempo di ribaltare la prospettiva. Quando le cose vanno male la colpa non è mai dell’utente ma è sempre della macchina e quindi del progettista. Questa prospettiva, apparentemente estrema, è in realtà il punto di partenza fondamentale per la progettazione di prodotti, sistemi e servizi usabili e quindi di successo. Le ragioni della complessità dell’interazione uomo-macchina sono numerose. Spesso però, la maggior causa del “cattivo design” è dovuta alla formazione dei tecnici e dei progettisti. Per molti anni si è focalizzato tutto il bagaglio formativo dei tecnici su tematiche tecnologiche ignorando gli aspetti legati alla psicologia umana e alle dinamiche di mercato. 22 CAPITOLO 4. PROGETTAZIONE DELLE INTERFACCE La maggior parte dei problemi di design deriva quindi dalla totale incomprensione dei principi del design necessari per portare alla realizzazione di un prodotto capace di abilitare una positiva esperienza di interazione uomo-macchina. Gli ingegneri, gli informatici sono eccellenti sul piano tecnico ma spesso sono molto limitati nella comprensione delle persone e della socialità. I tecnici pensano: ”Siamo uomini anche noi, quindi siamo in grado di capire i nostri simili e di progettare per loro.” Sbagliato! I tecnici falliscono perchè partono da un’assunzione profondamente sbagliata e cioè che la spiegazione logica del funzionamento di un sistema sia suffi- ciente per consentire a chiunque di utilizzarlo. Purtroppo, come già detto, la logica e le persone non vanno molto d’accordo! ”Basterebbe che leggessero le istruzioni e tutto andrebbe bene!” Gli ingegneri sono formati per utilizzare quotidianamente il pensiero logico e computazionale, di conseguenza finiscono per credere che quello sia il modo comune di ragionare. È quindi fondamentale accettare che il comportamento umano è illogico e non può essere modificato (per fortuna). Bisogna progettare per come le persone sono e non per come vorremmo che fossero! “we were designing things for people, so we needed to understand both technology and people. But that’s a difficult step for many engineers: machines are so logical, so orderly. If we didn’t have people, everything would work so much better. Yup, that’s how I used to think.” (Donald Norman) 4.2 L’Incidente di Three Mile Island Fonte. L’incidente di Three Mile Island fu una parziale fusione del nocciolo avvenuto nella centrale nucleare sull’omonima isola, nella Contea di Dauphin, in Pennsylvania, il 28 marzo del 1979. Fu il più grave incidente nucleare avvenuto negli Stati Uniti d’America, e ha portato al rilascio di piccole quantità di gas radioattivi e di iodio radioattivo nell’ambiente. L’incidente avvenne esattamente alle ore 4:00 di mercoledì 28 marzo 1979, quan- do il reattore era ad un regime di potenza del 97% ; ebbe inizio nel circuito di refrigerazione secondario, con il blocco della portata di alimentazione ai generatori di vapore. Questo blocco portò, nel circuito primario di raffreddamento del nocciolo, ad un considerevole aumento della pressione del refrigerante, causando prima l’aper- tura di una valvola PORV di rilascio posta sul pressurizzatore e poi lo “SCRAM” (arresto di emergenza del reattore mediante l’inserimento delle barre di controllo). A questo punto la valvola di rilascio non si richiuse e gli operatori non si resero conto del problema, anche perché non vi era nella strumentazione l’indicazione della reale posizione della valvola. La strumentazione era infatti legata all’alimentazione del motore della valvola e non alla reale posizione della valvola. Fu così che il circuito di raffreddamento primario si vuotò parzialmente e il calore residuo del nocciolo del reattore non poté essere smaltito. A causa di ciò il nocciolo radioattivo subì gravi danni. Gli operatori non poterono diagnosticare correttamente cosa avveniva e reagire in maniera adeguata. La strumentazione carente della sala controllo e l’addestramento inadeguato risultarono essere le cause principali dell’incidente. 4.2. L’INCIDENTE DI THREE MILE ISLAND 23 Durante l’incidente si ebbe una pericolosa fusione parziale del nocciolo e di con- seguenza vennero riportati alcuni gravissimi danni; l’unità 2 fu chiusa ed è ancora oggi sotto monitoraggio, in attesa delle future azioni di smantellamento. 24 CAPITOLO 4. PROGETTAZIONE DELLE INTERFACCE Capitolo 5 Principi Fondamentali dell’Interazione Un buon design produce un’esperienza piacevole! Ai tecnici non piace molto la parola esperienza poiché la considerano troppo soggettiva e poco legata alla tecnologia ed al progresso. Ma se chiediamo a un ingegnere di descrivere la sua automobile preferita descriverà modello e finiture, dettagli tecnici e poi ci narrerà la sensazione che ha provato quando era alla guida: la potenza percepita dall’accelerazione, la maneggevolezza del cambio e dello sterzo, la sensazione di aderenza etc.. L’esperienza è cruciale nell’utilizzo di qualsiasi sistema tecnologico e non. È gra- zie all’esperienza che si crea la tonalità del ricordo che conserviamo e associamo agli oggetti con cui abbiamo interagito. Quando la tecnologia si comporta in maniera inaspettata, gli utenti provano con- fusione, frustrazione e rabbia: tutte emozioni negative. L’utente che invece riesce a comprendere il funzionamento, e quindi ad utilizzare correttamente un prodotto, proverà una piacevole sensazione di controllo, sarà soddisfatto e persino orgoglioso. Tutte queste sensazioni positive saranno associate al prodotto! Cognizione ed emozione sono profondamente legate: se non si mette l’utente in uno stato mentale positivo e quindi propenso alla sperimentazione e all’interazione, inevitabilmente l’utente compierà più errori perchè avrà un basso in- teresse per l’oggetto e farà più fatica ad usare l’interfaccia. Più l’utente è arrabbiato e frustrato meno è predisposto ad interagire e imparare come si usa il prodotto e riutilizzarlo in futuro. Come abbiamo detto nel capitolo precedente, la visibilità o discoverability di un prodotto è il grado di facilità con cui un utente scopre cosa può fare, come funziona e che tipo di azioni sono possibili con il prodotto. Tale visibilità si ottiene attraverso il processo di design dell’interazione ed è il risultato dell’applicazione di cinque concetti psicologici fondamentali: affordance, significanti, mapping, feedback, vincoli. C’è poi un sesto principio che come vedremo non è legato a degli elementi specifici dell’interfaccia ma piuttosto al concetto generale su cui si va a basare il funziona- mento del sistema, il modello concettuale del sistema. Il modello concettuale di un sistema è il cuore dell’interazione e su questo si fonda l’intera esperienza utente. 5.1 Affordance Il termine affordance, letteralmente invito, indica la relazione fra le proprietà di un oggetto o sistema e le proprietà del suo utilizzatore: indica la relazione tra le proprietà di un oggetto e le capacità dell’agente che determina come l’oggetto possa essere utilizzato. 25 26 CAPITOLO 5. PRINCIPI FONDAMENTALI DELL’INTERAZIONE Le affordance non sono quindi proprietà oggettive di un sistema o prodotto ma piuttosto relazioni prodotto-utente che se stabilite abilitano o disabilitano specifiche modalità di interazione fra le parti. Una sedia appare fatta apposta per sostenere qualcosa, invita alla seduta. La maggior parte delle sedie è abbastanza leggera da poter essere sollevata e spostata da una persona: possiamo affermare che una sedia presenta l’affordance per il ”sedersi” e per ”essere sollevata” da una persona adulta normodotata. La sedia non ha infatti la proprietà universale di consentire la seduta a chiun- que: un neonato non riesce a salire su una sedia e non riesce a stare seduto se non ha un sostegno laterale; dunque la sedia NON HA l’affordance del consentire la seduta. Stessa cosa per la sollevabilità, un bambino di 3 anni può sedersi su una sedia ma non ha abbastanza forza per sollevarla: anche in questo caso abbiamo un’affordance che non è disponibile con una categoria di utenti ma lo diventa con altre. Un’affordance non è una proprietà, è una relazione tra un oggetto e utente, dipende quindi dalle proprietà sia dell’oggetto che dell’utente. Oltre alle affordance esistono anche le anti-affordance. Un’anti-affordance è una relazione fra oggetto e utente che se stabilita va a negare, vietare alcune pro- prietà o modi di interazione disponibili fra utente e oggetto. Un esempio di anti- affordance sono gli ”spunzoni” usati come deterrenti per i volatili sui cornicioni, in- segne etc. Questo sistema nega all’utente (piccione) di posarsi sul cornicione disabi- litando, quindi la (altrimenti presente) affordance della stazionabilità che altrimenti il piccione sarebbe in grado di abilitare e usufruirne. Le affordance e le anti-affordance per abilitare o disabilitare una particolare modalità di interazione fra oggetto ed utente devono essere percepibili, ”disco- verable”. La percepibilità di un affordance non è certo un aspetto ovvio e che può essere dato per scontato. Il vetro, famoso per la sua trasparenza ha ”affordance” per la trasmissibilità della luce ma ha un’ anti-affordance per l’attraversabilità. Infatti, il vetro non consente il passaggio di corpi solidi. Essendo trasparente, questa anti- affordance non è facilmente percepibile dall’utente e quindi l’utente può attuare interazioni non permesse dando origine a problemi di utilizzo (sbattere sulla porta a vetri). Per dare visibilità ad un’affordance si usano i significanti. Spesso nei testi di design si trovano affermazioni tipo: ”E’ stata messa un’affordance per...”; le affordance non si mettono o si tolgono, sono modalità dell’interazione che nascono da relazioni fra proprietà dell’oggetto e proprietà dell’utente. Per abilitare delle affordance rendendole visibili e quindi palesi all’utente si inseriscono dei significanti che vanno solamente ad aumentare la visibilità e la comprensione di affordance già presenti. 5.2 Significante I progettisti hanno dei problemi pratici: hanno bisogno di sapere come rendere comprensibili gli oggetti che creano. Lavorando sulla grafica degli schermi elettronici, dovevano trovare il modo di indicare quali parti potevano essere sfiorate, battute, fatte scivolare in sù, in giù o di lato, azioni che si potevano eseguire con le dita, con lo stilo o con il mouse. Un significante è quindi un modo per indicare dove effettuare un’azione (tipicamente attraverso delle convenzioni), data un’affordance che determina quali azioni sono possibili. Affordance: cosa si può fare? quale azione è possibile compiere? Signifier: dove è possibile fare l’azione? 5.3. MAPPING 27 Molto spesso i significanti sono indispensabili poiché la maggior parte delle affordance sono invisibili. Per fare un esempio basti pensare alle porte scorrevoli: se i cardini non sono visibili, quando vede la maniglia la prima azione che una persona tenta di fare è quella di spingere o di tirare la porta, ma essa non si muoverà, è quindi necessario mettere un significante (e.g. un cartello o una scritta) che indica quale azione è necessaria per aprire la porta. I significanti posso essere: Voluti o intenzionali: come un’etichetta, una stringa o un’icona. Accidentali o non intenzionali: come ad esempio un sentiero tracciato da persone che camminano attraverso un campo o delle persone in fila alla stazione. Nel design i significanti sono molto più importanti delle affordances, per- chè comunicano come usare il prodotto o l’interfaccia. Ma come si può associare l’affordance e il significante ad azioni reali? Nella maggior parte dei casi trami- te convenzioni. La comprensione di un’affordance percepita è dovuta anche alle convenzioni culturali. (a) La scritta pull è un significante. (b) La folla è un esempio di significante so- ciale. 5.3 Mapping Mapping è un termine tecnico, ripreso dalla matematica, che indica la relazione fra gli elementi di due insiemi. Il concetto di mapping è di grande importanza nella progettazione di interfacce, in particolare nel posizionamento dei significanti. La disposizione dei significanti 28 CAPITOLO 5. PRINCIPI FONDAMENTALI DELL’INTERAZIONE può comunicare di più circa l’interfaccia e circa le sue funzionalità. Infatti se si sfrutta una corrispondenza spaziale fra la collocazione dei comandi e quella dei dispositivi comandati, risulta molto più facile capire come usarli. Il modo migliore per fare mapping è quello naturale (riguarda forme e colori), perché è un’attività in cui il cervello umano è molto bravo, i bambini imparano a fare mapping fin dai primi anni di vita. È da tenere presente che il concetto di naturale è ben diverso dal concetto di universale, poiché ci possono essere molti mappings che sembrano naturali ma che in realtà sono specifici a una cerchia di culture. Figura 5.2: Mapping cattivo e mapping buono. 5.4 Feedback Il feedback è la comunicazione del risultato di un’azione, è una risposta che l’inter- faccia dà all’utente. Il feedback deve essere immediato (se oltre i 100ms non viene percepito come una risposta all’azione appena compiuta), se il ritardo è troppo lungo l’utente po- trebbe rinunciare all’attività che stava compiendo e passare ad altro o addirittura non riuscire a comprendere l’origine del feedback stesso. Deve essere informativo, non deve portare con sè troppa informazione, ma deve assolvere al proprio obiettivo, deve far capire che un’azione è in corso o che è stato prodotto il risultato che ci si aspetta. Uno scarso feedback può essere peggio di nessun feedback, perché distrae, crea confusione e di conseguenza frustrazione nell’utente. Un altro caratteristica importante è la semplicità, un feedback non deve essere pedante: troppi annunci o segnali portano le persone ad ignorarli perdendo anche i feedback cruciali e veramente importanti. Il feedback deve essere essenziale e mantenere l’ambiente calmo e tranquillo. 5.5 Modello concettuale Un modello concettuale è una descrizione altamente semplificata delle funzionalità di un sistema, non deve essere completa o accurata ma utile. I file, le cartelle e le icone che si vedono sullo schermo del computer aiutano le persone a crearsi un modello concettuale dei dati in memoria o delle applicazioni disponibili. In realtà il computer non contiene fascicoli o cartelle: esse sono solo concettualizzazioni ideate per facilitarne l’uso. I modelli semplificati sono preziosi e utili fintanto che le ipotesi che li supportano sono vere. Nel cloud storage i file sembrano essere sul dispositivo, ma in molti casi il materiale è in realtà nel cloud. Il modello concettuale veicola- to è quello di un archivio disponibile sui dispositivi degli utenti. Questo modello semplificato è utile e basta per il normale utilizzo, ma se il collegamento dei servizi si interrompe, può nascere confusione nell’utente: l’informazione è sempre presente 5.6. IMMAGINE DI SISTEMA 29 sullo schermo, ma egli non può più salvarla o recuperare altri dati, cosa inspiegabile in relazione al modello concettuale precedentemente veicolato. Il modello concettuale esprime come il designer vuole che l’utente percepi- sca il prodotto, sarebbe, in un certo senso, l’ambizione di progettare e comprendere la UX. Una volta che i progettisti hanno pensato e progettato il modello concettua- le si implementa l’interfaccia, in modo che il modello concettuale venga veicolato all’utente tramite affordances, significanti e mapping presenti su di essa. Quando una persona interagisce con il sistema o con il prodotto sviluppa un proprio modello mentale. Un modello mentale è un modello concettuale nella mente dell’utente che rappresenta il modo in cui, secondo lui, funzionano le cose. Non solo persone diverse possono avere modelli mentali diversi dello stesso oggetto, ma la stessa persona può avere molteplici modelli, pertinenti ciascuno ad un aspetto diverso del suo funzionamento, e persino contraddittori gli uni con gli altri. Più è grande la differenza tra il modello mentale e quello concettuale, più l’utente farà fatica ad usare il sistema. L’ideale è che l’utente apprenda un modello concettuale giusto direttamente dal device che utilizza, senza andare a leggere manuali o istruzioni o, peggio ancora, che gli venga trasmesso da terzi. La comprensione di un dispositivo tramite passaparola porta all’effetto del telefono senza fili: l’interpretazione cambia da persona a persona. Per questo vi è necessità che il modello concettuale trasmesso dal prodotto sia pressoché unico in relazione a quello mentale che l’utente si costruisce. In questo contesto vale l’affermazione less is more secondo cui se una feature è difficile da veicolare allora è meglio non implementarla. 5.6 Immagine di Sistema Le persone si creano di continuo, attraverso l’esperienza, l’addestramento e l’istru- zione, modelli mentali di sé, degli altri, dell’ambiente e degli oggetti con cui esse interagiscono. Questi modelli servono agli uomini da guida per realizzare i loro scopi e com- prendere il mondo in cui vivono. Figura 5.3: Immagine di sistema. Come fanno gli uomini a formarsi un modello concettuale adeguato dei dispositivi che utilizzano? Non potendo parlare con il progettista, essi si basano su tutta l’informazione accessibile: l’aspetto dell’apparecchio, cosa hanno imparato dall’uso di oggetti simili in passato, cosa comunicano le pubblicità, i venditori, i pieghevoli illustrativi, il sito web e il libretto di istruzioni. 30 CAPITOLO 5. PRINCIPI FONDAMENTALI DELL’INTERAZIONE L’insieme di tutta questa informazione è l’immagine di sistema. Come illustrato nella figura, il progettista e l’utilizzatore finale del prodotto costituiscono i vertici scollegati di un triangolo. Il vertice del triangolo più a destra è occupato dal modello concettuale del progettista, cioè dalla sua concezione del prodotto in questione. Una volta commercializzato, il prodotto si stacca dal progettista: lo vediamo infatti isolato nel secondo vertice del triangolo. L’immagine di sistema è tutto ciò che si percepisce dalla struttura fisica prodotta, completa di documentazione, istruzioni,significanti e ogni informazione accessibile dal sito web o dal servizio di assistenza clienti. Il modello concettuale dell’utente deriva dall’immagine di sistema, mediante l’in- terazione con il prodotto, mediante letture, ricerche online e manuali. Il progettista si aspetta che il modello concettuale dell’utente coincida col suo, ma, non essendo- ci comunicazione diretta fra lui e l’utente, tutto il peso della comunicazione grava invece sull’immagine di sistema. Questo spiega perché la comunicazione è un aspetto importante del buon desi- gn. Per quanto sia geniale il prodotto, se la gente non riesce ad usarlo l’accoglienza sarà cattiva. Tocca al progettista fornire le informazioni adeguate per rendere il prodotto comprensibile ed usabile. Quel che più conta è presentare un modello concettuale capace di guidare l’utente quando le cose non vanno come dovrebbero. Un buon modello concettuale è la chiave per avere prodotti comprensibili, di facile uso e gradevoli, e una buona comunicazione è importantissima per ottenere buoni modelli concettuali. Capitolo 6 Vincoli In che modo si riesce a capire una cosa che non abbiamo mai visto prima? Non c’è altro da fare che combinare l’informazione presente nel mondo esterno con quella che si ha in testa. L’insieme di conoscenze che si trovano nel mondo comprende le affordances, i significanti visibili, le corrispondenze fra quelle parti degli oggetti che sembrano comandi o punti da manipolare, le azioni risultanti e i vincoli fisici che limitano ciò che è possibile fare. La conoscenza si ha in mente comprende i modelli concettuali, i vincoli cultu- rali, semantici e logici del comportamento, le analogie fra la situazione attuale ed esperienze precedenti. Figura 6.1: Un modellino lego. Si prenda come esempio il modellino Lego presente in figura: ha 15 pezzi, solo alcuni specializzati, molti altri sono di grandezza e forma uguale ma di colori diversi. Combinando i vincoli fisici con quelli culturali, semantici e logici si riesce a costruire il modellino senza istruzioni, mettendo ogni pezzo nella sua giusta posizione. Vincoli fisici limitano le parti che possono andare insieme, i vincoli culturali e semantici impongono restrizioni precise a tutti i pezzi restanti e se rimane fuori qualche pezzo l’incastro è dettato dalla logica. I vincoli sono indizi potenti, che limitano l’insieme delle azioni possibili. L’uso intelligente dei vincoli in sede di design permette alle persone di decidere prontamente il giusto corso d’azione, anche in una situazione del tutto nuova. È possibile categorizzare i vincoli in quattro classi: Vincoli fisici: si affidano a proprietà del mondo fisico, senza alcun bisogno di istruzioni o di addestramento. Nell’esempio della motocicletta Lego ritroviamo questo vincolo nei pezzi che si incastrano solo in un determinato verso. 31 32 CAPITOLO 6. VINCOLI Vincoli culturali: si affidano alle abitudini culturali, sociali, comportamenta- li che possono cambiare nel tempo (si intendono anche le convenzioni). Nell’e- sempio della motocicletta Lego ritroviamo questo vincolo nel saper determinare la collocazione delle luci: bianco all’anteriore e rosso al posteriore. Vincoli semantici: si affidano al significato della situazione per circoscrivere l’insieme delle azioni possibili, si basano sulla conoscenza della situazione e del mondo. Nel caso della motocicletta, c’è un’unica collocazione sensata per il motociclista, deve stare seduto guardando in avanti. Vincoli logici: dettati dalla semplice e pura logica umana. Se avanzasse un un solo pezzo per assemblare la motocicletta, grazie alla logica sapremo dove collocarlo nella sua giusta posizione. Un buon designer può sfruttare questi vincoli per veicolare l’utente verso un modello mentale del prodotto che si avvicini il più possibile al modello concettuale desiderato e in tal modo garantirgli una UX gradevole. Vincoli e mapping a volte si confondono tra di loro. Una serie di interruttori mappati in maniera opportuna infondono un vincolo logico che permette all’utente di non sbagliare, si intuisce perfettamente cosa verrà azionato da quell’interruttore posto in quel determinato punto. Mapping forti possono diventare dei vin- coli logici. Come già ribadito più volte, l’assenza di vincoli e mapping genera frustrazione poiché crea una interfaccia poco chiara e difficile da comprendere. Figura 6.2: Un interruttore per le luci di una stanza che imita la piantina del locale. 6.1 Funzioni Obbliganti Le funzioni obbliganti sono una forma di vincolo fisico: consistono di situa- zioni in cui le azioni sono vincolate in modo che un passaggio mancato impedisca di procedere al successivo. Sono il caso estremo di vincoli atti ad impedire un comportamento inappropriato. Non tutte le situazioni permettono l’uso di vincoli così forti, ma il principio generale è applicabile negli ambiti più diversi. Si esaminano ora tre di questi metodi: 6.2. ACTIVITY-CENTERED CONTROL 33 Interlock: obbliga a eseguire una serie di operazioni (n maggiore di 1) nella sequenza dovuta prima di avviare l’azione richiesta. Gli interlock sono usati soprattutto come sistemi di sicurezza nei macchinari idnustriali ma anche nel mondo software come per esempio nel caso dei sistemi Captcha. Nelle figure che seguono si possono trovare due esempi di interlocks; un trapano a colonna professionale richiede che l’utente che lo usa esegua una serie di azioni nell’ordine corretto: chiudere lo sportello di sicurezza, armare il sistema premendo l’apposito bottone, attivare il motore ruotando l’interruttore rosso; se una volta attivato il sistema si apre lo sportello, il motore si spegne. (a) Esempio di interlock: captcha. (b) Esempio di interlock: trapano a colonna. Lock-in: mantiene attiva una funzione impedendo che qualcuno la interrompa prematuramente. È usato molto in ambito informatico (e.g. ogni tentativo di uscita da un’applicazione senza salvare è prevenuto da un messaggio di allerta che chiede la conferma dell’intenzione, “blocca dentro” l’utente). Per finire un task si deve compiere un’azione. Figura 6.4: Esempio di lock-in: save dialog. Lockout: impedisce l’ingresso in uno spazio pericoloso o impedisce che suc- ceda qualcosa. Può essere considerato l’opposto del lock-in. Due esempi di stampo informatico: gli alert VM 18 che si possono trovare su alcuni siti, bloccare un utente che ha immesso troppe volte credenziali sbagliate. Per accedere ad un task si deve compiere un’azione. Figura 6.5: Esempio di lockout: blocco di un utente. 6.2 Activity-Centered Control Il mapping spaziale dei comandi non sempre è il più opportuno. 34 CAPITOLO 6. VINCOLI In molti casi è meglio avere interruttori diversi per attività diverse: comandi centrati sulle attività. Azionando un semplice comando si impostano una serie di oggetti per svolgere una determinata attività, senza comandarli uno ad uno. In molti auditorium ci sono interruttori con indicazioni video, computer, piena luce e lezione che impostano il microfono, le luci della sala, il proiettore e quant’altro. Questo schema è eccellente in teoria e funziona particolarmente bene per utenti esperti o per alcuni software specifici, ma nella pratica è difficile da realizzare bene, soprattutto è necessario valutare gli imprevisti e le possibili risoluzioni. Per carità, il metodo è giusto, purché la gamma di attività sia scelta in modo da corrispondere alle situazioni reali. Ma anche in quel caso saranno pur neces- sari dei comandi manuali, perché si presenteranno sempre esigenze inattese, che richiederanno una regolazione particolare dei dispositivi. La Logitech ha prodotto una serie di telecomandi universali completamente pro- gettati attorno al concetto degli Activity Centered Control; un altro esempio sono i comandi disponibili su alcuni assistenti vocali (“Alexa, imposta modalità cinema”). Figura 6.6: Il telecomando universale Harmony di Logitech consente di controllare vari dispositivi attraverso un modello di interazione basato sugli activity centered controls. Non si seleziona più il dispositivo che si vuol controllare ma l’attività che si vuol fare: Play Game, Watch TV, etc.. Fondamentale ribadire che Activity-Centered Control e Forcing Functions non so- no uno dei principi dell’interazione (vincoli, feedback, affordance, significanti, map- ping, immagine di sistema, discoverability) ma applicazioni: sono un’evidenza di come strutture particolari di controllo fisico o presenti su una interfaccia derivino dal loro utilizzo. Capitolo 7 How do people do things È facile imparare alcune azioni elementari per far funzionare un dispositivo tecni- co. Ma cosa succede se le cose non vanno come dovrebbero? Come può l’utente accorgersene, e scoprire cosa fare? Per chiarire meglio tutto questo è bene soffermarsi prima sulla psicologia umana e sui modi con cui gli uomini scelgono e valutano le proprie azioni. Fatto ciò si passerà a esaminare il ruolo della cognizione e delle emozioni in tale processo: il piacere quando le cose funzionano senza intoppi e la frustrazione quando le aspettative iniziali degli utenti non sono realizzate. 7.1 I Golfi dell’Esecuzione e della Valutazione Quando usiamo un oggetto, ci si trova davanti due golfi: il golfo dell’esecuzione, nel quale si cerca di indovinare cosa fare, e il golfo della valutazione, in cui ci si sforza di capire cosa è successo. Il compito del progettista è quello di aiutare gli utenti a superare i due golfi e renderli il meno profondi possibili. Figura 7.1: Golfo dell’esecuzione e golfo della valutazione. Il golfo della valutazione corrisponde allo sforzo necessario per interpretare lo stato fisico del dispositivo e capire fino a che punto sono state realizzate le aspettative e le intenzioni iniziali. Il golfo è stretto quando il dispositivo fornisce informazioni sul proprio stato, in una forma facile da cogliere e interpretare. 35 36 CAPITOLO 7. HOW DO PEOPLE DO THINGS Quali sono gli elementi progettuali più importanti per superare il golfo della valutazione? Il feedback e un modello concettuale adeguato. Quali sono gli elementi progettuali più importanti per superare il golfo dell’ese- cuzione? Significanti, constraints, buon mapping e un modello concettuale adeguato. Entrambi i golfi sono presenti in molti apparati. Si incontrano spesso difficoltà, puntualmente liquidate accusando sè stessi. Di fronte alle difficoltà nell’uso di con- gegni che ci si aspetta di saper usare si finisce inevitabilmente col pensare di essere stupidi. Oppure, con dispositivi dall’aspetto più complicato, semplicemente ci si ar- rende, pensando di essere incapaci di utilizzarli. Queste spiegazioni sono entrambe sbagliate. Le difficoltà hanno origine nel design, non nell’utente. 7.2 I sette stadi dell’azione Compiere un’azione implica due fasi: esecuzione e valutazione degli effetti, fare e interpretare. Sia l’esecuzione che la valutazione richiedono che si capisca come funziona l’oggetto su cui si applica l’azione e quali risultati essa produce. Entrambe le fasi influiscono sullo stato emotivo dell’utente. Un progettista deve conciliare il compito che l’utente vorrebbe eseguire e tutte le possibili azioni fisiche che può compiere per eseguirlo. Una volta che l’utente specifica quali azioni compiere, bisogna far in modo le esegua concretamente: ciò costituisce lo stadio dell’esecuzione. Identificato il goal, o scopo, l’utente discende attraverso i tre stadi dell’esecuzione: pianificare, specificare ed eseguire. La valutazione si articola anch’essa in tre stadi: percepire, in- terpretazione, confrontare. Ecco così che si hanno i sette stadi dell’azione: uno per lo scopo, tre per l’esecuzione e tre per la valutazione. Figura 7.2: Sette stadi dell’azione Scopo: definire l’obiettivo. Progettare: definire l’azione da eseguire. Specificare: costruire una sequenza d’azione. Eseguire: eseguire la sequenza specificata. Percepire: osservare lo stato del mondo. Interpretare: elaborare la percezione. Confrontare: rapportare il risultato allo scopo. 7.3. I SETTE PRINCIPI FONDAMENTALI DELLA PROGETTAZIONE 37 La maggior parte delle azioni non richiede che si percorrano tutti i sette stadi in sequenza, ma quasi nessuna attività si risolve tramite un’azione singola. Di solito si applicano numerose sequenze e l’intera attività può durare ore o giorni. Ci sono molteplici circuiti di feedback, con cui i risultati di un’attività vengono usati per indirizzare l’utente verso altre, in cui uno scopo genera scopi accessori e ogni un progetto sotto-progetti. Ci sono attività in cui lo scopo originario è addirittura dimenticato, scartato o riformulato. I sette stadi offrono uno schema per sviluppare nuovi prodotti o servizi. I golfi dell’esecuzione e della valutazione sono i punti più ovvi da cui partire, offrendo entrambi spunti per migliorare il prodotto. I progettisti devono svilupparne capacità di osservazione. 7.3 I sette Principi Fondamentali della Progettazione Il modello a sette stadi del ciclo d’azione è un prezioso sussidio per il design, in quanto introduce una lista di domande fondamentali. In generale, ogni stadio dell’azione richiede specifiche strategie progettuali, e, viceversa, presenta occasioni proprie di disastro. Ne derivano dunque sette domande, a cui dovrebbe poter rispondere chiunque stia usando un determinato prodotto. Cosa voglio ottenere? Quali sono le sequenze d’azione alternative? Quale azione posso fare ora? Come faccio questa azione? Cosa è successo? Cosa significa? Va bene? Ho realizzato il mio scopo? Figura 7.3: Sette domande. 38 CAPITOLO 7. HOW DO PEOPLE DO THINGS Il progettista ha la responsabilità di garantire che a ogni stadio dell’azione il prodotto fornisca l’informazione necessaria per proseguire correttamente. L’informazione che serve a rispondere alle domande nelle fasi attuative è definita come feedforward. L’informazione che aiuta a capire quello che è successo nella fasi percettive è definita invece come feedback. Il feedforward si realizza mediante l’uso opportuno di significanti, vincoli e mapping, anche il modello concettuale ha un ruolo importante. Il feedback è dato dall’immediato cambiamento di stato che il prodotto de- ve mostrare all’utente e, anche qui, una parte importante è svolta dal modello concettuale. Sia il feedback sia il feedforward devono presentarsi in una forma facilmente interpretabile da chi utilizza il sistema. La presentazione deve corrispondere alla visione che le persone hanno dello scopo che vogliono realizzare e alle loro aspettative. L’informazione erogata deve essere immediatamente comprensibile. Dalle risposte relative ai sette stadi dell’azione si ricavano sette principi fonda- mentali del design: Visibilità: è bene che sia facile scoprire immediatamente quali azioni sono possibili e qual è lo stato attuale del dispositivo. Feedback: è opportuno che ci sia un’informazione completa e continua ri- guardo ai risultati delle azioni e allo stato attuale del prodotto o del servizio. Dopo aver eseguito un’azione, deve essere facile determinare il risultato. Modello Concettuale: il design dovrebbe fornire tutta l’informazione ne- cessaria per creare un buon modello concettuale del sistema, che favorisca la comprensione e la sensazione di controllo da parte dell’utente. Il modello concettuale potenzia sia la visibilità, sia la valutazione dei risultati. Affordance: è bene che le affordance siano fatte apposta per rendere possibili le azioni desiderate e impossibili quelle indesiderate. Significanti: un uso efficace dei significanti assicura la visibilità e la com- prensibilità dei comandi. Mapping: è necessario che la relazione fra i comandi e le rispettive azioni obbedisca ai principi del buon mapping, sostenuto, per quanto possibile, dalla disposizione spaziale e dalla contiguità temporale. Vincoli: bisogna fornire vincoli fisici, logici, semantici e culturali, in modo tale da guidare l’azione e facilitandone l’interpretazione. Questi sette principi sono mappati uno ad uno sugli stadi d’azione dell’utente. La maggior parte delle azioni svolte quotidianamente, goal e intenzioni non sono davvero specificati: sono opportunistici anziché pianificati. Le azioni opportuni- stiche sono quelle in cui il comportamento scaturisce delle circostanze; completia- mo le attività del giorno e facciamo certe cose a mano a mano che se ne presenta l’occasione invece che come conseguenza di un’attenta analisi e pianificazione. Gli utenti in questi casi agiscono in maniera non controllata e quindi non preve- dibile. È difficile fare buon design per queste situazioni, anche attenendosi a tutti i principi esposti fino ad ora: l’utente che agisce in maniera opportunistica romperà in ogni caso questi schemi. 7.4 Pensiero umano La mente umana è infatti molto complessa, non esiste un indicatore che separi pensiero subconscio (non ne siamo consapevoli, è “nascosto”, veloce, poco costoso in termini energetici, procede per pattern matching) e pensiero conscio (è “manuale”, 7.4. PENSIERO UMANO 39 lento, elaborato, dettagliato, orientato all’analisi e costoso in termini di energie, interviene quando non si riesce ad avere una corrispondenza). Il pensiero conscio interviene per l’apprendimento ma, al termine della fase ini- ziale, pratica e studio producono quello che gli psicologi chiamano “overlearning”: una volta che una abilità è stata “overlearned”, i gesti verranno svolti senza sforzi e automaticamente. Un esempio è quando, guidando una macchina, si vede qual- cosa attraversare la strada: a questo punto, frenare è un gesto automatico, avverrà ancora prima di aver capito cosa stesse veramente attraversando. Come ci ricordiamo le esperienze se la maggior parte delle azioni sono in mo- dalità subconscia? Lo facciamo attraverso la memoria esperienziale, i ricordi sono come un dipinto in cui sono evidenziati gli elementi che abbiamo ritenuto importan- ti; per recuperare quelli meno importanti, cerchiamo di ricordare quella esperienza. Distinguiamo due tipi di memoria: memoria dichiarativa, utilizzata per recu- perare informazioni fattuali; memoria procedurale, (utilizzata) per recuperare informazioni procedurali. Un altro elemento determinante per il passaggio da un pensiero subconscio a uno conscio è lo stato emozionale. Figura 7.4: Livelli di processing. La divisione in conscio e subconscio può essere ulteriormente affinata andando a dividere il modo in cui il cervello fa processing in tre livelli procedurali: viscerale (o 40 CAPITOLO 7. HOW DO PEOPLE DO THINGS rettiliano), comportamentale e riflessivo. Livello viscerale: è il livello più elementare, permette di rispondere pronta- mente in maniera subconscia, senza consapevolezza o controllo cosciente. Livello comportamentale: è la sede delle abilità apprese durante circostan- ze più o meno simili a quelle attuali. Durante l’esecuzione, il livello compor- tamentale è guidato dalle aspettative, e durante l’attesa di conferma di tali aspettative è invece guidato dalle emozioni. Il livello comportamentale stabili- sce in che modo si compie una determinata azione e in che modo si interpreta un determinato feedback. Livello riflessivo: è il livello della cognizione conscia, è qui che si sviluppa la comprensione profonda e hanno luogo il ragionamento e i processi decisionali. Qui fanno capo i livelli più alti di emotività: soddisfazione e orgoglio, ma anche frustrazione e senso di colpa. Veicolare informazioni all’utente mentre egli si trova nel livello rifles- sivo è estremamente efficace. Al livello riflessivo il suo pensiero è conscio e le emozioni che egli produce sono le più durature. Gli stimoli riflessivi sono parte integrante del ricordo degli eventi, è importante quindi creare nell’utente ricordi positivi mentre egli è in questo stadio dell’azione, perché tali ricordi sono i più duraturi. Inoltre è la riflessione, intesa come pensiero cosciente, che induce a consigliare un prodotto e raccomandarne l’uso o magari a sconsigliarlo. I tre livelli di elaborazione contribuiscono tutti insieme a determinare lo stato emotivo e cognitivo dell’utente. Funzioni riflessive di alto livello possono mettere in moto emozioni più elementari e queste, a loro volta, possono stimolare attività cognitive di tipo riflessivo. Capitolo 8 Errore Umano La maggior parte degli incidenti industriali è causata da errore umano: le stime si aggirano tra il 75% e il 95% del totale. Come è possibile che tante persone siano così incompetenti? La risposta è semplice! Non lo sono, il problema è nella mal progettazione e nel cattivo design. Si continuano a produrre dispositivi e software che richiedono, a chi li usa, di mantenere per ore un’attenzione ed una vigilanza complete, oppure di memorizzare procedure arcaiche, confuse e usate di rado, magari anche una sola volta nella vita. Si costringono le persone a stare in un ambiente monotono senza nulla da fare per ore e ore, salvo dovere improvvisamente rispondere con rapidità e precisione. Le si sottopone ad un ambiente di lavoro complesso e sovraccarico, dove sono continua- mente interrotte durante l’esecuzione di compiti simultanei. L’interruzione è una delle cause che più frequentemente portano all’errore umano. Uno dei più grandi problemi è l’atteggiamento delle persone verso gli errori commessi. Quando un errore causa perdite economiche o, peggio anco- ra, danni alle persone, si istituisce una speciale commissione d’inchiesta, che quasi immancabilmente trova i colpevoli. Il passo successivo è punirli con multe, il licenziamento o addirittura il carcere. Essi vengono incolpati e puniti o, nella migliore delle ipotesi, incolpati e riaddestrati. Tutto questo però non risolve il problema: lo stesso errore continuerà a presen- tarsi. Per evitare di incorrere nuovamente nell’errore, quando esso viene commesso, è bene studiarne le cause, per poi ridisegnare il prodotto o le procedure in modo che esso non si ripeta o, se dovesse ripetersi, che i danni siano ridotti al minimo. 8.1 Root Cause Analysis La Root Cause Analysis consiste nell’indagare l’incidente finché non si trova la singola causa che ne è l’origine. Ovvero il momento nel tempo quando effettivamente qualcuno ha preso decisioni o eseguito azioni sbagliate e, una volta fatto ciò, accertare da cosa è derivato lo sbaglio. Purtroppo, troppo spesso, il processo si ferma non appena si scopre che una persona ha agito in maniera impropria, additandola come colpevole. Cercare di trovare la causa di un incidente suona bene, ma ha due difetti. La maggior parte degli incidenti non ha una sola causa. Da qui il modello a groviera degli incidenti di James Reason. Solitamente l’analisi delle cause profonde si ferma non appena trovato un errore umano. 41 42 CAPITOLO 8. ERRORE UMANO Figura 8.1: Modello a groviera. Se una macchina smette di funzionare per un guasto o un malfunzionamento si cerca di capire come mai si è rotta o cosa l’ha portata a guastarsi. È opportuno fare lo stesso quando si scopre un errore umano: individuarne le cause. Quando durante l’analisi delle cause profonde si incontra, nella concatenazione di cause ed effetti, un errore umano, il lavoro è appena cominciato: bisogna capire perché l’errore è accaduto e cosa si può fare per prevenirlo. 8.2 I cinque perchè L’analisi delle cause profonde mira a determinare la causa prima di un evento, non la causa immediata. In Giappone da tempo si usa a questo scopo una procedura detta ”dei cinque perché” ideata da Sakichi Toyota e impiegata dalla Toyota nell’ambito del sistema di controllo qualità dei suoi prodotti. Fondamentalmente quindi quando si cerca la ragione di un evento non ci si deve fermare dopo averne trovata solo una, ma bisogna continuare ad indagare fino a che non si trovano le vere cause di fondo. Va ripetuta davvero cinque volte? No, ma chiamarla procedura dei cinque perché sottolinea la necessità di proseguire anche dopo aver trovano una causa apparente. Vediamo un esempio: il veicolo non si accende. Perché? La batteria è morta. Perché? L’alimentatore non funziona. Perché? La cinghia dell’alternatore non funziona. Perché? La cinghia dell’alternatore era ben oltre il suo tempo di servizio e non è stata sostituita. Perché? Il veicolo non è stato mantenuto secondo le tempistiche raccoman- date. Quando le persone sbagliano, bisogna cambiare il sistema in modo da evitare l’errore e, se non è possibile eliminarlo del tutto, almeno fare in modo di ridurne gli effetti. Se il sistema lascia sbagliare gli utenti è mal progettato, se il sistema induce all’errore, allora è progettato malissimo. Perchè le persone sbagliano? Perchè il design si concentra sulle esigenze del sistema e delle macchine, non su quelle degli utenti. Le macchine hanno bisogno in genere di comandi precisi, 8.3. DEFINIZIONE DI ERRORE 43 obbligando l’operatore a introdurre esatte informazioni numeriche. Gli esseri umani non sono adatti ad esercitare grande precisione e commettono spesso errori quando devono digitare lunghe sequenze di numeri o lettere. Gli umani sono creativi, curiosi, costruttivi, particolarmente bravi nel creare modi nuovi di fare le cose e nel cogliere nuove opportunità. Compiti monotoni, ripetitivi e precisi contraddicono tali qualità e vi entrano in conflitto. 8.3 Definizione di errore Si definisce errore umano ogni deviazione dal comportamento appropriato. Il termine appropriato è da prendere con le pinze, perché in molte circostanze si scopre quale fosse il comportamento giusto solo successivamente. Generalmente comunque si chiama errore ogni comportamento che si discosta da quello generalmente accettato come giusto o adeguato. Errore è il termine generale per tutte le situazioni sbagliate. È possibile dividere gli errori in due classi: Lapsus o Slips: si ha un lapsus quando s’intende eseguire un’azione e si finisce per eseguirne un’altra. Nel caso del lapsus, l’azione eseguita non è quella voluta. Ci sono due tipi principali di lapsus: – di azione: si esegue una azione sbagliata. Per esempio, si versa il latte nel caffé e si mette la tazza in frigo. – di memoria: si dimentica di eseguire una azione o di valutarne i risultati. Per esempio, si dimentica il fornello acceso dopo aver terminato la cottura. I lapsus si hanno nelle fasi attuative e percettive dell’azione. Mistakes: si ha un mistake quando è sbagliato il goal o lo scopo: da quel momento in poi le azioni, anche se eseguite a puntino, fanno parte dell’errore essendo di per sé inappropriate, in quanto parte di un progetto sbagliato. In questo tipo di errore l’azione è corretta ma l’intenzione no. I mistakes si suddividono in: – rule-based: la diagnosi della situazione è giusta, ma poi viene scelto un corso d’azione sbagliato, seguendo una regola operativa errata. Per esempio, un meccanico diagnostica un difetto nella batteria di una mac- china, decide di non sostituire la batteria perché funziona al 50% delle prestazioni attese. – knowledge-based: la diagnosi della situazione è sbagliata. Per esempio, il peso del carburante viene misurato in libbre anziché in chilogrammi. – memory-lapse: un passaggio viene dimenticato nel momento in cui si fissano gli obiettivi o si esegue una procedura o se ne valutano i risultati. Per esempio, un meccanico fallisce nella gestione di un errore perché salta un passaggio. I mistakes si hanno nelle fasi di pianificazione e valutazione dell’a- zione. 44 CAPITOLO 8. ERRORE UMANO 8.4 Prevenzione dell’errore Non dovrebbe essere possibile che un semplice errore provochi un danno diffuso. Ecco che cosa dovrebbe essere fatto in fase di prevenzione: Comprendere le cause dell’errore per minimizzarne il ripresentarsi. Effettuare controlli di sensibilità, ovvero, chiedersi se le azioni superano il test del buon senso. Rendere possibile annullare le azioni (undo) o rendere più difficile fare ciò che non può essere annullato (per esempio con uso di locks). Rendere più semplice la scoperta e la comprensione degli errori e semplificarne la risoluzione. Non trattare l’azione come errore, piuttosto aiutare l’utente a compiere correttamente l’azione. I novizi, gli utenti base, coloro meno esperti del sistema cadono in mistakes poiché non hanno una base di conoscenza adeguata e sufficientemente strutturata, viceversa, gli utenti esperti che usano il software o il sistema tutti i giorni e che lo conoscono bene commettono più errori di tipo lapsus poiché tendono ad eseguire i compiti in maniera automatica, quasi istintiva, affidandosi al controllo subconscio, mentre un principiante è costretto a fare molta attenzione, cosicché incorre meno nei lapsus. I mistakes nascono dalla scelta di scopi e piani d’azione inadeguati, oppure, in sede di valutazione, dal confronto errato tra risultati e scopi. In altre parole dipendono da informazioni ambigue o poco chiare sullo stato attuale del sistema e dalla mancanza di un buon modello concettuale. Si esamineranno adesso quali possono essere le cause di errore e come è possibile prevenirle. Le interruzioni sono una delle più grandi cause di errore, soprattutto i lap- sus. Quando un’attività viene interrotta da qualche evento, il costo in attenzione è molto maggiore della perdita di tempo causata dell’interruzione. Per riprendere il lavoro è necessario ricordare precisamente il precedente stato dell’attività: quale era l’obiettivo, a che punto del ciclo dell’azione si era rimasti e quale era lo stato del sistema. La maggior parte dei sistemi rende difficile la ripresa di un azione a seguito di un’interruzion