Software e User-centered Design (UCD)

Presentazione sul tema: "Software e User-centered Design (UCD)"— Transcript della presentazione:

1 Software e User-centered Design (UCD)
Rielaborazione da appunti del Prof. Roberto Polillo Ed integrazione a cura di Michele Visciola

2 Contenuti La carta dei diritti dell’utente
L’usabilità del software ed i requisiti dell’usabilità Cosa vuol dire “Progettazione centrata sull’utente” (UCD)

3 La carta dei diritti dell’utente

4 La “Carta dei diritti dell’utente”
1. L’utente ha sempre ragione. Se c’è un problema nell’uso del sistema, il problema è il sistema, non l’utente 2. L’utente ha il diritto di istallare facilmente i sistemi software e hardware 3. L’utente ha diritto a un sistema che si comporti esattamente come promesso 4. L’utente ha diritto a istruzioni facili da usare, che gli consentano di comprendere e utilizzare un sistema per raggiungere gli obbiettivi desiderati 5. L’utente ha diritto ad avere il controllo del sistema e che il sistema risponda a una sua richiesta di attenzione

5 La “Carta dei diritti dell’utente” (cont)
6. L’utente ha diritto a un sistema che fornisca informazioni chiare, comprensibili ed accurate sul compito che sta effettuando e su quanto manca al suo completamento 7. L’utente ha il diritto di essere informato con chiarezza su tutti i requisiti necessari per usare il software e l’hardware con successo 8. L’utente ha il diritto di conoscere i limiti delle capacità del sistema 9. L’utente ha il diritto di comunicare con il fornitore di tecnologia e di ottenere una meditata e utile risposta alle sue preoccupazioni 10. L’utente dovrebbe essere il padrone della tecnologia hardware e software, e non viceversa. I prodotti dovrebbero essere naturali ed intuitivi da usare. (Clare-Marie Karat, “User’s Bill of Right”)

6 Usabilità del software
Cos’è l’usabilità del software e….. perchè è importante Le norme e gli standard “de facto” dell’usabilità Cosa si può fare per rendere un sistema usabile:

7 Cos’è l’usabilità del software…..
1. funzionalità 2. affidabilità 3. usabilità 4. efficienza 5. manutenibilità 6. portabilità ISO 9126 “La efficacia, efficienza e soddisfazione con cui specificati utenti possono raggiungere specificati obbiettivi in particolari ambienti” ISO 9241

8 Cos’è l’usabilità del software…..
Efficacia l’accuratezza e completezza con cui raggiungo il mio obbiettivo Efficienza le risorse spese per ottenere tale risultato Soddisfazione il comfort e la accettabilità del sistema

9 …. e perché è importante Le quattro cause principali della sottostima dei costi (secondo Communication of the ACM, 1992): richieste frequenti di modifica da utenti finali requisiti utenti sfuocati o non compresi comunicazione utenti-analisti insufficiente compiti e procedure non identificati

10 Ancora sull’usabilità del software (gli standard “de facto”)
Attributi generali dell’usabilità Facilità di apprendimento Efficienza d’uso Facilità di comprensione Reversibilità degli errori Soddisfazione d’uso Oltre le norme standard (che sono troppo generali e rappresentano un minimal agreement) esistono degli standard de facto che conviene conoscere

11 Facilità di apprendimento
attributo fondamentale per la gran parte degli utenti tendenza verso i sistemi “zero-learning time” le misure sui tempi di apprendimento sono basate sui tempi occorrenti per portare a termine proficuamente gli obiettivi/compiti previsti

12 Efficienza d’uso definisce la capacità di soddisfare pienamente i requisiti dopo che sia stato raggiunto il plateau nell’apprendimento per la misura occorrono esperti del compito-ambiente nella misura vengono prese in considerazione soprattutto le tipologie di errore

13 Facilità di comprensione
riguarda la capacità di ridurre al minimo indispensabile processi di recupero in memoria di informazione (non si dimentica una volta appreso) si verifica la prontezza d’uso dell’utente e le “affordances” (inviti all’azione) dell’interfaccia (che deve facilitare rievocazione e riconoscimento) la verifica viene effettuata soprattutto su utenti non esperti

14 Reversibilità degli errori
si riferisce alla capacità di ridurre le potenzialità di errore e di ridurre l’impatto dell’errore sul risultato finale si tratta di rendere reversibili le conseguenze degli errori la misura riguarda soprattutto quantità e tipologia di errori potenziali

15 Soddisfazione nell’uso
si riferisce alla capacità di rendere piacevole e confortevole l’interazione si misura il grado di soddisfazione con diverse tipologie di utenti la misura della soddisfazione può essere “relativizzata”, confrontandola con altri sistemi simili

16

17 Alcuni aspetti importanti di un progetto
Il ciclo compito - artefatto L’utente Le variabili del contesto d’uso

18 Lo strumento modifica il compito, che richiede nuovi strumenti !
IL CICLO “COMPITO - ARTEFATTO” Strumento Compito Lo strumento modifica il compito, che richiede nuovi strumenti !

19 “As tools are introduced and used, a co-evolution will occur between the tools and the people using them” D.C.Engelbart

20 E IL SOFTWARE? Strumento software Compito Il software soddisfa i bisogni dell’utente? Non solo…. Infatti li trasforma!

21 L’UTENTE

22 Che cosa guardiamo di solito
L’UTENTE Che cosa guardiamo di solito

23 L’UTENTE Che cosa dovremmo guardare

24 CONOSCERE L’UTENTE Memoria Percezione visiva Processi cognitivi

25 La complessità del contesto d’uso
ambienti obbiettivi utenti Uno specifico obbiettivo per uno specifico tipo di utente, per uno specifico contesto d’uso

26 La complessità del contesto d’uso
ambienti obbiettivi utenti Tante funzioni per uno specifico tipo di utente, in uno specifico contesto d’uso

27 La complessità del contesto d’uso
ambienti Tante funzioni per tanti diversi tipi di utenti, in tanti diversi contesti d’uso utenti obbiettivi

28 ALCUNI PUNTI FERMI - La usabilità va progettata dall’inizio, e tenuta costantemente sotto controllo nel processo di progettazione e sviluppo - Progettare sistemi usabili è difficile e costoso; richiede competenze e professionalità specifiche - La valutazione di usabilità di un sistema non può prescindere dall’utente

29 Sulla carta funziona, ma...

30 USABILITY LAB

31 LIVELLI DI MATURITÀ DELLA PROGETTAZIONE
PRIMO STADIO: Il prodotto funziona SECONDO STADIO: Il prodotto fornisce le funzioni richieste TERZO STADIO: Il prodotto è facile da imparare e da usare QUARTO STADIO: Il prodotto è invisibile durante l’uso

32 Un telefono mentre parlo...
Alcuni artefatti “invisibili”... Un telefono mentre parlo... Una penna mentre scrivo... Un’automobile mentre guido...

33 Un tipico ciclo di sviluppo del software
REQUI- SITI 15 % SPEC. FUNZIONALI ARCHITETTURA CODIFICA 20 % TEST 20 % La progettazione e la costruzione di un programma è attività gravosa e costosa: un programma piccolo si può costruire senza problemi, ma un sistema informativo bancario richiede centinaia di anni-persona (ad esempio, 1oo persone che ci lavorano per 3 anni) E’ importante allora organizzare i progetti ingegneristicamente, e in figura sono indicate fasi e i relativi costi percentuali tipici: definizione requisiti: specifica del problema da risolvere specifiche funzionali: specifica il comportamento del programma architettura: descrive come il programma sarà fatto codifica: la stesura dei programmi test: la verifica sperimentale che ogni programma si comporta come desiderato integrazione: mette insieme i programmi in un unico sistema test successivo. Verifica che i programmi integrati funzionino come richiesto E L’UTENTE FINALE? IN QUESTO MODELLO ( PROCESSO DI SVILUPPO A CASCATA) L’UTENTE FINALE NON C’E’ OPPURE QUANDO SI FANNO VERIFICHE è TROPPO TARDI PER APPORTARE MODIFICHE SIGNIFICATIVE. Lo UCD permette di superare queste barriere INTEGRAZIONE 25 % TEST 20 % RILA- SCIO

34 Il paradigma dello UCD Analisi dei requisiti utente e requisiti d’uso
Se chiediamo all’utente che cosa vuole, avremo una varietà di risposte, riconducibili a 2 patterns: non sa specificare (vaghezza) dirà le sue preferenze, tuttavia queste non risponderanno ai comportamenti contestuali (sappiamo più di quanto siamo in grado di dire!!) ...Conviene allora realizzare low-fi prototype: “paper-based prototype” e “usability test”

35 IL paradigma UCD

36 Storyboard

37 Per riassumere: Comprendere i requisiti d’uso ed i requisiti dell’utente, vuol dire chiedersi e fornire risposte su: Chi sono gli utenti finali (non confondere con cliente) Come lavorano (task analysis e metodi etnometodologici: osservazione sul posto) Come interagiscono (test di usabilità)

38 …. E quindi….. Pensare al mondo (progetto) secondo il punto di vista del tuo utente target Comprendere i processi lavorativi in cui l’artefatto (prodotto) verrà inserito Non farsi guidare dalla disponibilità di tecnologie (innovazione guidata da un’attenta analisi dei comportamenti)