User Centered Design Economico
Progettazione centrata sull’utente
con l'impiego minimo di risorse
di Vincenzo Dentamaro 27/07/2012
Prefazione:
Lo User Centered Design (UCD) è un modo per progettare e costruire prodotti di qualsiasi genere tenendo conto del punto di vista e delle esigenze dell’utente. Lo UCD è un processo composto di più attività. Si basa sull’iterazione di diversi strumenti di analisi od osservazione, progettazione e verifica. In italiano questo processo è noto anche come “Progettazione Centrata sull’Utente”.
Il processo è stato definito e descritto da diversi autori e persino da alcune norme ISO, come l’ISO 13407, Human-centered design process, l’ISO 9241-110 Dialogue Principles (mod. 2006). Diverse fonti descrivono processi leggermente diversi, ma guidati dalla stessa filosofia: fondare il progetto sui reali bisogni degli utenti.
Secondo l’ISO 13407:
La progettazione centrata sull’essere umano (human-centred design) è un approccio allo sviluppo dei sistemi interattivi specificamente orientato alla creazione di sistemi usabili. È un’attività multi-disciplinare che incorpora la conoscenza e le tecniche dei fattori umani e dell’ergonomia. L’applicazione dei fattori umani e dell’ergonomia alla progettazione dei sistemi interattivi ne potenzia l’efficacia e l’efficienza, migliora le condizioni del lavoro umano e contrasta i possibili effetti avversi dell’uso sulla salute, sulla sicurezza e sulle prestazioni. Applicare l’ergonomia alla progettazione dei sistemi richiede che si tenga conto delle capacità, delle abilità, delle limitazioni e delle necessità umane. I sistemi human-centred supportano gli utenti e li motivano a imparare. I benefici possono includere una maggiore produttività, una migliore qualità del lavoro, riduzione dei costi di supporto e di addestramento e una migliore soddisfazione dell’utente.
In questa tesi presenterò un modello di User Centred Design che permetterà di sviluppare prodotti e servizi tenendo presente non solo le reali esigenze degli utenti, ma anche le esigenze di economicità in fase di sviluppo di un prodotto (o servizio) da parte delle aziende.
Conoscere l’utente
Tutto si basa sul coinvolgimento attivo dell'utente e sulla chiara comprensione dei requisiti degli utenti e dei task (quello che l’utente deve fare).
Bisogna comprendere quello che l’utente fa, come lo fa e cosa si aspetta come output.
Analizzare gli utenti basandosi sui seguenti punti:
- Capacità e bisogni reali
- Contesto
- Lavoro
- Tasks
- Necessità di prodotti usabili
Golden rule del progetto di interfacce: Conoscere l’utente.
Per conoscere l’utente bisogna osservarlo mentre compie il suo lavoro (non ancora automatizzato e privo della nostra soluzione), cosa si aspetta in output e capire come tutto può essere automatizzato o semplificato mediante l’uso di una soluzione (prodotto o servizio) differente.
E’ conveniente descrivere uno scenario, cioè scrivere, in maniera semi-formale, una storia di come gli utenti usano la soluzione attuale per compiere i loro task.
Approfondendo aspetti caratteristici degli utenti come il loro background cognitivo (quanto conoscono di una certa cosa), le loro abilità motorie e mentali (se hanno deficit cognitivi o motori), l’età (un prodotto per bambini deve poter essere usato diversamente da come lo userebbe un adulto), l’ambiente in cui vive, la cultura, la propria storia.
Fondamentalmente dopo questa analisi vengono fuori due grandi categorie di utenti:
Gli utenti comuni e gli utenti speciali.
Gli utenti comuni sono quegli utenti che non hanno particolari deficit motori o cognitivi e che rappresentano la maggiorparte degli utenti del nostro prodotto.
Gli utenti speciali sono quegli utenti che per necessità d’uso o per deficit cognitivi o motori hanno bisogno di una qualche progettazione speciale per adattare il prodotto ancora da sviluppare alle loro esigenze.
Se si desidera creare un prodotto usabile (cioè il grado con cui un essere umano può utilizzarlo con il massimo profitto e il minimo sforzo) anche per gli utenti speciali, è sempre conveniente pensare alla soluzione prima di iniziare lo sviluppo:
Molte aziende creano un prodotto per l’utente comune e poi applica degli adattamenti per l’utente speciale (tipo plugin), questo rende il prodotto poco usabile per l’utente speciale.
Si dovrebbe quindi prevedere la progettazione orientata all’utente speciale sin dall’inizio.
La più recente ricerca sull’usabilità dimostra che la soluzione migliore per creare un sitema usabile per l’utente speciale è quella di progettare un sistema in grado di adattarsi alle caratteristiche dell’utente man mano che l’utente lo usa.
Quindi pensare a chi è destinato l’uso del prodotto da sviluppare.
Osservare l’utente mentre svolge il task
Continuare la descrizione dello scenario inserendo una descrizione abbastanza approfondita di quello che l’utente fa per arrivare al suo scopo, come lo fa, usando quali strumenti e se è soddisfatto o meno.
Questa analisi ci permetterà di capire il dominio applicativo del prodotto da sviluppare e addirittura di collocare il prodotto da sviluppare in uno preciso contesto lavorativo.
L’analisi deve produrre come output una lista strutturata di task che l’utente compie per raggiungere lo scopo. Poi il progettista annota ciascun task come necessario, non importante, importante, auspicabile ed ecc.
Ecco un esempio riguardo l’analisi dei task per un progetto sul financial forecasting:
F.S. è un responsabile del gruppo Emea di IBM Italia e desidera conoscere quando vendere le azioni di IBM in suo possesso da 10 anni.
Francesco, come qualsiasi altro dipendente di IBM, riceve annualmente come premio delle Stock Options, ovvero dei pacchetti di azioni dell’azienda presso cui presta servizio. Vuole sapere qual’è il momento migliore per vendere le proprie azioni e ricavare denaro fisico da investire per comprare una casa ad Ostia ai figli. Francesco conosce molto bene l’uso delle tecnologie informatiche ed è un curioso sperimentatore di nuovi strumenti software. Utilizza giornalmente Yahoo Finance! per vedere qual’è il valore corrente delle azioni di IBM Inc. ed inoltre usa altri siti di brokerage online (come www.interactivebrokers.com) per trovare dei compratori per le proprie azioni e realizzare la cifra di cui necessita per acquistare la casa al mare ai figli.
Nello specifico Francesco legge sulla sua pagina personale di IBM il numero di azioni da lui detenute e il valore corrente del titolo “IBM” e quindi il valore totale delle sue azioni.
Poi si reca su Yahoo! Finance, cerca e seleziona il titolo “IBM” e visualizza l’andamento storico del titolo “IBM” inerente ai mesi passati. L’andamento è presentato in maniera grafica mediante un diagramma. Una volta osservato il diagramma, se il grafico è in crescita o è stabile Francesco si reca su alcuni siti di brokerage online per vendere le proprie azioni.
Vorrebbe conoscere l’andamento futuro del valore del titolo di IBM ma proprio non ha alcuna idea di come predire il futuro.
Nei siti di brokerage usa spesso lo strumento in modalità demo per simulare l’acquisto e la vendita di azioni. E’ diffidente nell’uso di strumenti di vendita di azioni online, perché consapevole dei rischi di frode che potrebbero esserci. Però non vuole neanche affidarsi a dei costosi e a volte poco onesti, brokers fisici (persone) che svolgono quel lavoro come professione. Per questo motivo rimanda sempre la vendita delle sue azioni sperando di non arrivare mai a raggiungere valori minimi di quotazione oppure raggiungere la scadenza delle stock options in suo possesso. Conoscere l’andamento futuro delle proprie azioni gli permetterebbe di capire qunado vendere le sue azioni e quanto guadagnerà o perderà continuando a tenersele senza venderle.
Francesco è un utente diretto del sistema, primario, perché quotidianamente valuterà l’andamento presente e futuro dei titoli ed è un utente esperto di tecnologie informatiche ma non esperto di finanza.
Francesco, rappresenta la categoria di utenti che usa frequentemente sistemi online per monitorare l’andamento delle azioni, però, a differenza della categoria precedente, lo fa per cogliere il momento giusto per venderle e guadagnare di più.
Sotto task individuati:
- Lettura del valore corrente del titolo
- Importante e Frequente
- Da includere assolutamente
- Lettura del valore totale delle stock options di cui si è in possesso
- Importante per Francesco
- Non frequente
- Recarsi su Yahoo! Finance
- Relativamente frequente
- Importante
- Non importante in un software che ha le stesse funzionalità di Yahoo! Finance.
- Ricerca dell’azienda
- Importante e Frequente
- Da includere assolutamente
- Selezione dell’azienda
- Da includere assolutamente
- Frequente e importante
- Selezione dell’intervallo (la data di inizio e la data di fine) in cui prelevare i valori giornalmente
- Molto importante e Frequente
- In futuro renderlo opzionale potrebbe diminuire la complessità del sistema
- Visualizzazione di un grafico dell’andamento dei valori storici
- Frequente ed importante
- Da includere assolutamente
- Vendita di azioni mediante strumenti online
- Frequente
- Possibile implementazione futura
- Simulazione di vendita online
- Non frequente
- Non importante
- Rinuncia alla vendita/acquisto
- Frequente
- Importante
- Possibile implementazione futura
Come potete notare non si accenna minimamente alla soluzione da progettare, queste analisi dei task hanno il solo scopo di individuare gli utenti, cosa fanno e come lo fanno.
Sta al progettista poi capire cosa includere e cosa non includere.
Analizzare più utenti significa avere un quadro completo di ciò che gli utenti desiderano dal prodotto.
Analisi dei requisiti
Un requisito (dal latino requisitus, richiesto) è una proprietà richiesta, oppure auspicabile, del prodotto.
Il documento dei requisiti ha allora lo scopo di raccogliere in forma organica una descrizione di tutte le proprietà desiderate. Dalla sua formulazione dovrebbe essere chiaro se un requisito esprime una proprietà obbligatoria, oppure soltanto suggerita o auspicabile.
I principali metodi di raccolta dei requisiti del progetto sono:
- - Questionari: Rispondere a domande specifiche. Si possono raggiungere molte persone con poco sforzo. Vanno progettati con grande accuratezza, in caso contrario le risposte potrebbero risultare poco informative. Il tasso di risposta può essere basso;
- - Interviste individuali: Esplorare determinati aspetti del problema e determinati punti di vista. L’intervistatore può controllare il corso dell’intervista, orientandola verso quei temi sui quali l’intervistato è in grado di fornire i contributi più utili. Richiedono molto tempo. Gli intervistati potrebbero evitare di esprimersi con franchezza su alcuni aspetti delicati.
- - Focus group: Mettere a fuoco un determinato argomento, sul quale possono esserci diversi punti di vista. Fanno emergere le aree di consenso e di conflitto. Possono far emergere soluzioni condivise dal gruppo.La loro conduzione richiede esperienza. Possono emergere figure dominanti che monopolizzano la discussione.
- - Osservazioni sul campo: Comprendere il contesto delle attività dell’utente. Permettono di ottenere una consapevolezza sull’uso reale del prodotto che le altre tecniche non danno. Possono essere difficili da effettuare e richiedere molto tempo e risorse.
- - Suggerimenti spontanei degli utenti: Individuare specifiche necessità di miglioramento di un prodotto. Hanno bassi costi di raccolta. Possono essere molto specifici. Hanno normalmente carattere episodico.
- - Analisi della concorrenza e delle best practices: Individuare le soluzioni migliori adottate nel settore di interesse: evitare di “reinventare la ruota” e ottenere vantaggio competitivo L’analisi di solito è costosa(tempo e risorse)
Valutare quali sono i più economici per il prodotto che si intende sviluppare ed applicarli.
E' consigliato creare una tabella dei requisiti dove viene specificato, per ogni requisito, anche la proprietà se obbligatoria, suggerita o auspicabile.
Creazione dei prototipi: pensare all’interfaccia!
La fase di progettazione dei prototipi è molto importante per una buona progettazione user centered. E’ fortemente sconsigliato pensare alle funzionalità che il prodotto dovrà fornire in questa fase della progettazione. E’ invece consigliato pensare a come l’utente deve interagire con il prodotto.
A questo punto si consiglia di seguire le norme dello standard ISO 9241 per la progettazione di interfacce usabili.
Innanzitutto bisogna tenere presenti le difficoltà che l’utente può affrontare nell’uso del prodotto.
Una rappresentazione semplicistica di come funziona la mente umana è stata resa disponibile da Norman nel 1986:
Il golfo della esecuzione è la differenza tra le intenzioni e le possibili azioni che si possono effettuare sul sistema.
Il golfo della valutazione è la quantità di sforzo necessaria ad interpretare lo stato fisico del sistema e determinare fino a che punti corrisponde alle aspettative.
Il nostro scopo è minimizzare i due golfi.
Secondo l’ISO 9241 l’usabilità di un prodotto è definita come il grado con cui può essere usato da specifici utenti per raggiungere specificati obiettivi con efficacia, efficienza e soddisfazione.
E’ quindi una definizione multidimensionale.
E’ necessario sviluppare un’interfaccia secondo i principi del dialogo dell’ISO 9241-110
- Adeguatezza al compito: Un dialogo è adeguato al compito nella misura in cui supporta l’utente nell’efficace ed efficiente completamento del compito: dialogo essenziale, passi adeguati al compito, informazione adeguata al compito, formati di input adeguati al compito ed ecc...
- Auto-Descrizione: Un dialogo è auto-descrittivo se agli utenti risulta evidente, in ogni momento, in che dialogo si trovano, a che punto si trovano all’interno del dialogo, quali azioni possono compiere e come queste possono essere eseguite.
- Guida all’utente (inf. Operative, Inf. Su stato del sistema, feedback)
- Interazione evidente (legato all'effordance)
- Manualistica minima
- Stato visibile (attende input? Elabora? Ha finito?)
- Descrizione dell’input atteso (legato al vincolo d'uso)
- Formati descritti
- Conformità alle aspettative: Un dialogo è conforme alle aspettative se corrisponde alle necessità dell’utente, prevedibili in base al contesto e a convenzioni comunemente accettate.
Linguaggio familiare (molto importante: testo, icone,...)
Aderenza alle convenzioni (Dubai: lettura da destra a sinistra)
Organizzazione abituale
Dialogo consistente
Feedback conforme alle aspettative
Tempi di risposta conformi alle aspettative
Messaggi adeguati al contesto
Messaggi in posizione adeguata
Input in posizione attesa
Stile coerente dei messaggi
- Adeguatezza all’apprendimento: Un dialogo è adeguato all’apprendimento se supporta e guida l’utente nell’apprendimento del sistema.
Bassa soglia di apprendimento
Aiuto alla familiarizzazione
Aiuto online
Feedback intermedio
Modello concettuale evidente (quale logica?)
Spermentazione sicura (undo nei sistemi)
Riapprendimento facilitato
- Controllabilità: Un dialogo è controllabile se l’utente è in grado di iniziare e tenere sotto controllo la direzione e i tempi dell’interazione fino al raggiungimento dell’obiettivo.
Tempi di interazione controllati dall'utente (no time-out se non
necessari)
Proseguimento del dialogo controllato dall'utente
Punto di ripartenza controllato dall'utente
Reversibilità delle operazioni (undo)
Modalità di visualizzazione dei dati controllata dall'utente
Dispositivo di interazione scelto dall'utente
Personalizzazione dei valori di default
Disponibilità dei dati originali
- Tolleranza verso l’errore: Un dialogo tollera gli errori se, nonostante evidenti errori negli input, i risultati desiderati possono essere ottenuti senza o con minime azioni correttive. La tolleranza per gli errori si ottiene attraverso
a) prevenzione;
b) segnalazione e
c)- azioni correttive automatiche
Assistenza all'utente
Verifica e convalida dei dati
Prevenzione di azioni non valide
Richieste di conferma
Spiegazione dell'errore
Spiegazione aggiuntiva
Assistenza per il recupero
Minimo sforzo di correzione
Correzione differibile
Correzione automatica modificabile
- Adeguatezza all’individualizzazione: Un dialogo è adeguato all’individualizzazione se l’utente può modificare l’interazione e la presentazione dell’informazione per adattarle alle proprie necessità e capacità individuali.
Scelta di rappresentazioni alternative
Scelta del formato dei dati di input e output
Vocabolario personalizzabile
Scelta del livello delle spiegazioni
Personalizzazione dei tempi di risposta
Scelta del metodo di interazione
Personalizzazione del dialogo
Ripristinabilità dei valori precedenti
Ora bisogna pensare all’interfaccia tenendo presenti le precedenti norme per il corretto sviluppo di sistemi usabili.
Consiglio di sviluppare i prototipi dell’interfaccia in maniera low fidelity su carta, come degli schizzi di ogni interfaccia. Senza svilupparli nel dettaglio (cioè compresi di funzionalità), ma dare una struttura generale che consenta di simulare un minimo di interazione con il sistema.
Pianificazione e conduzione del test di usabilità con l’utente, applicazione dei test formativi
Qui si prepara il documento per la valutazione dell’usabilità delle interfaccie implementate sui prototipi.
Pianificazione:
1 – quali parti del sistema devono essere valutate?
2 – come devono essere valutate?
3 – quali prototipi saranno realizzati?
4 – come deve essere eseguita la valutazione? Con quali risorse?
5 – quali dovranno essere le interazioni con gli utenti?
6 – come dovrà essere condotta l'analisi dei risultati?
Istruzioni per lo svolgimento del test
L’utente inizia il test con le interfacce dei prototipi precedentemente sviluppati. Il progettista mostra le varie interfacce progettate a seconda di come interagisce l’utente con il sistema: cioè alla pressione di un tasto, mostra l’interfaccia collegata.
Viene chiesto ad ogni utente, in modo separato, di spiegare cosa vede nell’interfaccia; chiedere secondo loro cosa faccia ogni controllo e cosa ci farebbero loro con quel controllo. Da questo tiriamo fuori un modello concettuale per ogni utente, formato sulla propria esperienza pregressa e sulla sua interpretazione dei controlli che vede. In questo modo iniziamo a capire i punti errati e/o non sviluppati del sistema. Finita questa parte, si procede col prendere in considerazione il primo utente (da solo) e lo si sottopone agli esempi di task tipici, spiegando come sarà svolto il test vero e proprio, e chiedendo di pensare a voce alta, eseguendo i vari passi che sta facendo a voce alta e ragionando a voce alta (metodo del tink aloud) l’osservatore deve annotare tutto, ricordando, se l’utente non lo fa, di parlare e dire cosa fa o cosa pensa. Finita questa fase, si prende in considerazione anche l’utente 2 e insieme all’utente 1, lo si sottopone al terzo esempio di task (esempio di task numero 3), In questo caso si utilizza il metodo dell’interazione costruttiva, cioè il secondo utente testa in prima persona il sistema, affiancato dall’utente che l’ha testato precedentemente, eseguendo il task ricevuto. Durante i test i progettisti devono prendere appunti, e compileranno anche la modulistica relativa al raccoglimento delle varie misure. I valutatori non devono intervenire se non per ricordare agli utenti che devono pensare e ragionare a voce alta e per tranquillizzarli, così da diminuire la normale tensione da esame che potrebbe non far proseguire in modo corretto il test.
Si potrebbe anche far usare l’interfaccia un utente per volta, l’importante è videoregistrare cosa dice l’utente, cosa fa e come lo fa e quali difficoltà incontra.
Le misure da rilevare sono: il success rate (ovvero la percentuale di compiti risolti senza problemi) e il tempo impiegato per svolgere ogni compito impartito.
Queste misure ci danno una buona idea sulla reale usabilità del sistema da sviluppare.
Questi test, anche chiamati test formativi, servono a dare forma al progetto: infatti i progettisti capiscono i probabili difetti di interazione, modificano l’interfaccia (on the fly) del prototipo su carta anche facendosi aiutare dagli utenti stessi e poi continuano con la valutazione.
Durante il test con l’utente modificare l’interfaccia (test formativi):
I test formativi sono utilizzati durante il ciclo iterativo di progettazione, per sottoporre i vari prototipi a prove d’uso con gli utenti, allo scopo di identificarne i difetti e migliorarne l’usabilità. Si chiamano formativi perché, appunto, contribuiscono a “dare forma” al prodotto: il loro scopo è individuare il maggior numero possibile di problemi. Essi sono particolarmente utili nelle fasi iniziali della progettazione, quando il design concept è appena abbozzato.
Completare il test con un questionario da sottoporre agli utenti. Ecco alcune possibili domande:
- Quale parte del sistema o quale caratteristica e/o funzionalità ritieni meno soddisfacenti? Perchè?
- Quale parte del sito e/o funzionalità avrebbe bisogno di miglioramenti?
- Cosa hai trovato confuso o frustrante con le opzioni di interfaccia utente?
- Aggiungeresi qualche opzione o funzionalità? Se si, quale?
- Che cosa potremmo fare per migliorare il prodotto?
Il rapporto di valutazione derivante dall’analisi dei documenti e delle registrazioni ci daranno un quadro completo di come modificare l’interfaccia.
Sviluppo del prodotto o servizio
Questa è la fase in cui il prodotto deve essere sviluppato il più fedelmente possibile con i prototipi modificati.
In questa fase si può pensare alle funzionalità ma MAI MODIFICARE LE INTERFACCE PER ADATTARLE ALLE FUNZIONALITA’ DEL PRODOTTO: sono le funzionalità che devono adattarsi alle interfacce e non viceversa.
Questa è la vera differenza tra la progettazione classica e la progettazione user centered.
Valutazione euristica e test sommativi
Jakob Nielsen
Per valutazione basata su euristiche si denota un procedimento non rigoroso che consente di prevedere o rendere plausibile un determinato risultato, che in un secondo tempo dovrà essere controllato e convalidato con metodi rigorosi. Nell’ingegneria dell’usabilità, si chiamano euristiche quelle valutazioni di usabilità effettuate da esperti, analizzando sistematicamente il comportamento di un sistema e verificandone la conformità a specifiche “regole d’oro” (chiamate, appunto, euristiche), derivanti da principi o linee guida generalmente accettati. In pratica, per eseguire una valutazione euristica, l’esperto di usabilità dovrebbe considerare una regola euristica alla volta, ed esaminare dettagliatamente le funzioni del sistema, per verificarne la conformità.
La valutazione euristica ha il vantaggio di essere relativamente poco costosa. Tuttavia fornisce risultati piuttosto soggettivi. Quanto più le euristiche sono generali, tanto più il risultato della valutazione dipenderà dall’esperienza, dalla sensibilità e, a volte, dalle preferenze personali del valutatore.
Un'euristica e' quindi una linea guida o un principio generale che puo' guidare l'attivita' di design o puo' essere usata per analizzare una scelta gia' fatta. La valutazione euristica, sviluppata da Nielsen e Molich, si avvale di un insieme di semplici e generali euristiche per valutare un sistema. L'idea generale e' che piu' valutatori analizzano indipendentemente il sistema, piu' problemi di usabilita' vengono individuati. Nielsen afferma che un numero ragionevole di valutatori e' tra 3 e 5 con un risultato finale del 75 % degli errori di usabilita' riconosciuti.
Nielsen raccomanda le seguenti 10 caratteristiche (Le 10 Euristiche di Nielsen oppure Il Decalogo di Nielsen):
- Visibilità dello stato del sistema Il sistema dovrebbe sempre informare gli utenti su ciò che sta accadendo, mediante feedback appropriati in un tempo ragionevole.
- Corrispondenza fra il mondo reale e il sistema. Il sistema dovrebbe parlare il linguaggio dell’utente, con parole, frasi e concetti familiari all’utente, piuttosto che termini orientati al sistema. Seguire le convenzioni del mondo reale, facendo apparire le informazioni secondo un ordine logico e naturale.
- Libertà e controllo da parte degli utenti Gli utenti spesso selezionano delle funzioni del sistema per errore e hanno bisogno di una “uscita di emergenza” segnalat con chiarezza per uscire da uno stato non desiderato senza dover passare attraverso un lungo dialogo. Fornire all’utente le funzioni di undo e redo
- Consistenza e standard Gli utenti non dovrebbero aver bisogno di chiedersi se parole, situazioni o azioni differenti hanno lo stesso significato. Seguire l convenzioni della piattaforma di calcolo utilizzata.
- Prevenzione degli errori Ancora meglio di buoni messaggi di errore è un’attenta progettazione che eviti innanzitutto l’insorgere del problema. Eliminare le situazioni che possono provocare errori da parte dell’utente, e chiedergli conferma prima di eseguire le azioni richieste.
- Riconoscere piuttosto che ricordare Minimizzare il ricorso alla memoria dell’utente, rendendo visibili gli oggetti, le azioni e le opzioni. L’utente non dovrebbe aver bisogno di ricordare delle informazioni, nel passare da una fase del dialogo a un’altra. Le istruzioni per l’uso del sistema dovrebbero essere visibili o facilmente recuperabili quando servono.
- Flessibilità ed efficienza d’uso Acceleratori – invisibili all’utente novizio – posson spesso rendere veloce l’interazione dell’utente esperto, in modo che il sistema possa soddisfare sia l’utente esperto sia quello inesperto. Permettere all’utente di personalizzare le azioni frequenti.
- Design minimalista ed estetico I dialoghi non dovrebbero contenere informazioni irrilevanti o necessarie solo di rado. Ogni informazione aggiuntiva in un dialogo compete con le unità di informazione rilevanti e diminuisce la loro visibilità relativa.
- Aiutare gli utenti a riconoscere gli errori, diagnosticarli e correggerli. I messaggi di errore dovrebbero essere espressi in linguaggio semplice (senza codici), indicare il problema con precisione e suggerire una soluzione in modo costruttivo.
- Guida e documentazione Anche se è preferibile che il sistema sia utilizzabile senza documentazione, può essere necessario fornire aiuto e documentazione. Ogni tale informazione dovrebbe essere facilmente raggiungibile, focalizzata sul compito dell’utente, e dovrebbe elencare i passi concreti da fare, senza essere troppo ampia.
Uso dei test sommativi:
I test sommativi indicano una valutazione più complessiva del prodotto, al di fuori – o al termine – del processo di progettazione e sviluppo. Sono test più completi di quelli formativi, che non hanno lo scopo di fornire indicazioni ai progettisti, ma di valutare in modo sistematico pregi e difetti del prodotto, o sue particolari caratteristiche. Sono di solito condotti quando il sistema è completamente funzionante, per esempio per indicarne i punti deboli e valutare l’opportunità di un redesign migliorativo. Oppure per confrontarne le caratteristiche con quelle di sistemi concorrenti.
Per effettuare un test sommativo, si analizza il sistema dal punto di vista della conformità agli standard ISO 9241 o ISO 13407 e si analizza il sistema analizzando la conformità alle euristiche precedentemente descritte.
I livelli di maturità di un prodotto sono:
- 1° livello: il prodotto funziona (fattibilità), risolve problemi di natura tecnologica; si ha un sistema rudimentale con funzioni base.
- 2° livello: il prodotto fornisce le funzionalità necessarie(fattibilità, prestazioni, flessibilità e alcune indagini di usabilità); livello del task-centered design, completezza e qualità delle funzioni.
- 3° livello: il prodotto è facile da usare (livello dell’user centered design)
- 4° livello: il prodotto è invisibile durante l’uso (funziona, è usabile e si integra perfettamente nelle attività dell’utente).
Conclusioni
L’user centred design è una tecnica che ha permesso di sviluppare sistemi usabili di grande successo come le interfacce utente degli iPhone, iPad (interessante visitare il sito http://www.andreapicchi.it/) oppure come quasi tutti i servizi Google infatti la stessa Google in un’intervista (questa) dice: “Key point stressed several times: User-centered design ; User-centered design means building products that people really want and start with users needs and desires for designing products and services.”
Google Search è infatti un’ottimo esempio di UCD invece Yahoo! Search lo è meno:
Anche prodotti Microsoft come Windows Phone sono il risultato di un notevole studio sull’user centered design.
A questo indirizzo c’è una guida (per i Manager) dal titolo “Selling the value of user centered design” che dimostra sia mediante percentuali (si parla di ROI return on investment) che di qualità del prodotto , il perché dell’importanza dell’uso dei processi di UCD durante le fasi di progettazione.
Buon UCD!
Domande frequenti
In che senso la progettazione human-centred è diversa dalla progettazione intesa in senso tradizionale (progettazione centrata sul sistema)?
La progettazione centrata sull’essere umano (human-centred design) è un approccio allo sviluppo dei sistemi interattivi specificamente orientato alla creazione di sistemi usabili. È un’attività multi-disciplinare che incorpora la conoscenza e le tecniche dei fattori umani e dell’ergonomia. L’applicazione dei fattori umani e dell’ergonomia alla progettazione dei sistemi interattivi ne potenzia l’efficacia e l’efficienza, migliora le condizioni del lavoro umano e contrasta i possibili effetti avversi dell’uso sulla salute, sulla sicurezza e sulle prestazioni. Applicare l’ergonomia alla progettazione dei sistemi richiede che si tenga conto delle capacità, delle abilità, delle limitazioni e delle necessità umane. I sistemi human-centred supportano gli utenti e li motivano a imparare. I benefici possono includere una maggiore produttività, una migliore qualità del lavoro, riduzione dei costi di supporto e di addestramento e una migliore soddisfazione dell’utente. Mentre la progettazione centrata sul sistema l’oggetto principale dell’attenzione è il sistema da progettare. Il processo di progettazione parte dalla definizione dei suoi requisiti funzionali, cioè dall’identificazione delle funzionalità (o delle funzioni) che esso deve fornire al suo utente, che vengono descritte in dettaglio in un documento di specifiche funzionali, a partire dal quale il sistema viene progettato e quindi realizzato. In questo approccio, l’utente del sistema ha un ruolo, tutto sommato, abbastanza marginale: il progettista concentra la sua attenzione sulle funzionalità, e sugli aspetti tecnici connessi alla loro realizzazione, per arrivare a soddisfare le specifiche con un rapporto costo/qualità accettabile.
Che cosa si intende per design pattern?
Si intende una soluzione generale a un problema di progettazione che si ripropone in molte situazioni, anche diverse fra loro. Non una soluzione “finita”, ma piuttosto un modello, un template da adattare allo specifico contesto.
Quali sono i principali standard prodotti dal Technical Committee 159/SC 4 dell’ISO?
I principali standard prodotti dal Technical Committee 159/SC4 dell’ISO sono:
- ISO 13407 (Human-centred design processes for interactive systems);
- ISO 9241 (Human-computer interaction), suddiviso in otto serie tematiche:
- Serie 100: software ergonomics;
- Serie 200: Human system interaction processes;
- Serie 300: Displays and display related hardware;
- Serie 400: Physical input devices - ergonomics principles;
- Serie 500: Workplace ergonomics;
- Serie 600: Environment ergonomics;
- Serie 700: Application domains - Control rooms;
- Serie 900: Tactile and haptic interactions.
- ISO 14915 (Software ergonomics for multimedia user-interfaces), composto da tre documenti:
- Part 1: Design principles and framework;
- Part 2: Multimedia navigation and control;
- Part 3: Media selection and combination.
Oltre agli International Standard, l’ISO può produrre altri tipi di documenti, con un livello di consenso inferiore: ISO Technical Specification (ISO/TS), ISO Public Available Specification (ISO/PAS) e ISO Technical Report (ISO/TR). In particolare, il TC/159 SC 4 ha prodotto questi documenti aggiuntivi:
- ISO/TR 16982: Ergonomics of human-systems interaction – Usability methods supporting human-centred design;
- ISO/PAS 18152: Ergonomics of human-systems interaction – Specification for the process assessment of human-system issues;
- ISO/TR 18529: Human-centred lifecycle process descriptions.
Vincenzo Dentamaro
Software Engineer
