HCI -> Human Computer Interaction, questo 竪 il titolo dedicato al mio ultimo "lavoro". All'interno di queste slide si ha la possibilit di trovare un riassunto veloce riguardante il mondo HCI.
2. Introduzione
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Nuove slide e nuovo argomento, oggi nel mio piccolo vorrei aiutarvi a
capire che cosa c'竪 all'interno del mondo dell'Human-Computer
Interactione e il lavoro che c'竪 dietro la banale grafica delle vostro
sistema operativo, software (browser, skype, msn, etc) oppure dietro le
pi湛 utilizzate applicazioni per smartphone.
Va detto che queste regole e questi studi, sono comuni per tutte le
piattaforme che conoscete.
Queste slide sono anche il riassunto del corso che ha fatto parte del mio
percorso di studio all'interno dell'Universit di Trento.
Bene ma lasciamo le parole di troppo e andiamo a vedere la definizione.
3. HCI >>> Definizione
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
HCI 竪 l'acronimo di Human-Computer Interaction (tradotto in italiano 竪
l'Interazione Uomo-Computer), essa 竪 una disciplina che riguarda la
progettazione, la valutazione e l'implementazione di sistemi informatici
interattivi per l'utilizzo umano e con lo studio delle principali fenomeni
che li circondano.
5. ID >>> Interaction Design
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Credits image: http://a2ru.org/knowledgebase/ixd-fundamentals/
6. Interaction Design
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
ID 竪 l'acronimo di Interaction Design, che
竪 il processo di progettazione di prodotti
interattivi che supporteranno le persone
nella loro vita quotidiana e anche nella
loro giornata lavorativa.
L'ID (cos狸 lo chiamer嘆 da adesso in poi) 竪
influenzato da vari ambiti, sia tecnologici
(come l'informatica oppure l'ingegneria),
sia pratici (come il design grafico), sia
interdisciplinari (come nel caso dell'HCI).
Lo scopo principale dell'ID 竪 la
realizzazione di prodotti che abbiano una
buona usability (cio竪 facili da imparare e
utilizzare), che forniscano un'esperienza
piacevole e che coinvolgano l'utente.
L'ID 竪 molto importante, perch竪 un cattivo
design influisce pesantemente sulle
prestazione del prodotto (quindi tempi di
apprendimento alti, aumento degli errori e
frustrazione). Al contrario, un buon design
tiene conto di:
Persone
Attivit
Contesto
Tecnologie
Credits image: http://geekswithblogs.net/MarkPearl/archive/2011/11/07/interaction-design-course-summary.aspx
7. User Centric
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Credits image: http://bayini.com/blog/clear-communication-through-ux-or-why-user-centric-design-matters-in-enterprise-mobility/
8. User Centric
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Nella visione user-centric (filosofia che
si basata sull'utente, contrapposta alla
technology-driven) questa operazione 竪
chiamata analisi PACT (acronimo di: Persone
Attivit Contesto Teconologia).
Quest'ultima tiene conto delle singole
categorie e ci lavora attraverso.
L'analisi PACT 竪 particolarmente utile per
orientarsi nelle prime fasi di design del
proprio prodotto. Poi con l'avanzare della
realizzazione del prodotto finale si andr
sempre pi湛 a fondo nell'analisi.
Credits image: http://next-generation-communications.tmcnet.com/topics/business-critical-communications/articles/42431-user-centric-security-approach-the-dynamic-enterprise-new.htm
9. User Centric >>> PACT
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Ecco le categorie spiegate brevemente:
Persone: Sono tutti coloro che interagiscono con il
nostro prodotto.
Esistono tre livelli di utenti
Primario: Uso frequente del prodotto
Secondario: Uso occasionale o indiretto del
prodotto
Terziario: Sar influenzato e oppure influenzer il
nostro prodotto
importante tener conto delle diversit degli utenti,
a livello psicologico, fisiologico, sociale,
culturale, etc.
Attivit: Cio竪 lo scopo generale del prodotto.
Tenere conto degli aspetti temporali, complessit
sicurezza, natura dei contenuti, etc.
Contesto: Cio竪 dove avverr l'interazione col
prodotto. Bisogna tener conto del contesto fisico
(quindi dell'illuminazione, i rumori, il meteo, etc ),
contesto sociale (interazione di gruppo o
individuale, attivit, etc.) e contesto psicologico
(motivazione, attitudine).
Tecnologia: Tutti i contenuti tecnologici
coinvolti, input/output, comunicazione tra
dispositivi, etc.
10. Ciclo di progettazione >>> User Centric
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
E' fondamentale innanzitutto comprendere le esigenze
degli utenti.
Va detto sin da subito che un utente raramente sa con
esattezza ci嘆 che vuole e come si pu嘆 arrivare a tale
obiettivo.
quindi necessario raccogliere dati, tramite
osservazione diretta, domande e analisi varie.
Una volta fatto ci嘆 vanno considerate le alternative
possibili, aiutandosi nella scelta discutendone con
l'utente e valutando la realizzabilit pratica.
11. HCI NON SOLO QUESTO
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Credits image: http://www.unapsicologaroma.it/2013/03/20/quando-si-dice-unilluminazione/
12. Principi di design
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Principi:
Unit
Proporzione
Ritmo e movimento
Enfasi e contrasto
Equilibrio
Nel nostro caso sono sostanzialmente dei parametri di
valutazione del design di un dato prodotto o del
prodotto che noi andiamo a creare.
Sono delle astrazioni generalizzabili per pensare ai
diversi aspetti del design (per esempio: cosa mettere
o meno in un'interfaccia oppure come rendere
l'interfaccia pi湛 allegra).
Quindi questi principi altro non sono che il risultato
di un mix di buon senso, esperienza e conoscenza.
13. Esempi
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Esempi di principi di design:
Visibilit: mettere in risalto le parti importanti
del prodotto o dell'applicazione, e rendere ovvio
cosa bisogna fare;
Feedback: tenere informato l'utilizzatore su cosa 竪
stato fatto. Sfrutta vari sensi (cercare di
utilizzare le luci, le vibrazioni e i suoni);
Vincoli: limitare le azioni effettuabili al minimo
necessario, al fine di ridurre al massimo le
possibilit di errore;
Affordance (invito): rendere noto all'utente come
utilizzare il sistema/l'applicazione/il software/il
blog;
Coerenza: fare in modo che elementi simili
(dell'interfaccia) svolgano operazioni simili;
interfacce consistenti hanno un'usability pi湛 alta.
16. HCI >>> Usability {usabilit}
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Usability (tradotto usabilit) 竪 l'attributo
qualitativo che indica quanto un sistema o prodotto
sia facile da utilizzare da parte dell'utente.
Tale metrica si estende su pi湛 piani:
Semplicit di apprendimento;
Efficienza: quanto velocemente l'utente riesce ad
eseguire un dato compito utilizzando la nostra app?
Mnemonicit: Se non si utilizza il sistema per un
certo periodo dopo quanto si potr riutilizzarlo in
maniera efficiente?
Errori: Quanti e quanto gravi?
La qualit, definita come assenza di problemi, pu嘆
essere misurata, sia osservando sia attraverso dei
questionari autovalutativi.
Gerarchia dei bisogni dell'utente:
Funzionalit: il prodotto oppure l'applicazione
effettua il compito per cui 竪 stato creato;
Usabilit;
Piacere: il prodotto o l'applicazione 竪 di
piacevole utilizzo.
17. Principi di usabilit
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
I principi di usabilit sono molto simili ai principi
di design, ma pi湛 restrittivi.
Essi sono usati principalmente per la valutazione di
un sistema. Forniscono una base per le valutazioni
euristiche.
Questi principi di usabilit vengono valutati
attraverso l'Euristica.
L'Euristica: 竪 la valutazione per verificare che i
principi siano stati rispettati, nella progettazione
di una data interfaccia, una serie di principi
generali riguardanti l'usabilit.
18. Principi di usabilit
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Jacob Nielsen ha identificato cos狸 o 10 principi
generali dell'usabilit:
1) Visibilit dello stato del sistema;
2) Corrispondenza tra il sistema ed il mondo reale;
3) Controllo/libert dell'utente;
4) Coerenza;
5) Prevenzione dell'errore;
6) Riconoscimento piuttosto che ricordo (meno faticoso
a livello cognitivo);
7) Flessibilit ed efficienza;
8) Design estetico e minimalista;
9) Aiuto nel riconoscimento/risoluzione errori;
10) Help e documentazione;
19. Principi di usabilit
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Per quello che riguarda la Scala di severit di
Nielsen (questa scala va da 0 a 4) i principi
fondamentali sono:
0) Non 竪 un problema di usability;
1) Problema cosmetico >>> da risolvere solo se avanza
tempo;
2) Problema minore >>> bassa priorit;
3) Problema maggiore >>> alta priorit;
4) Catastrofe di usabilit >>> assolutamente da
risolvere prima di rilasciare il prodotto sul mercato;
20. Principi di usabilit
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Leggi Qui >>> http://www.tomshw.it/cont/articolo/windows-8-l-interfaccia-e-il-peggior-difetto-e-la-migliore-scommessa/41244/1.html
23. HCI >>> User Experience (UX)
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
La User Experience (UX), 竪 la risposta complessa
dell'interazione dell'utente con il sistema o la
nostra applicazione/software.
E' la conseguenza di:
a) Predisposizione dell'utente;
b) Caratteristiche del sistema;
c) Contesto generale;
La User Ecperience aggiunge alla valutazione del
design altri fattori (come ad esempio le emozioni,
il divertimento, etc) ed 竪 soggettiva.
Si tratta di un concetto olistico, che ha qualit
sia edeniche che pragmatiche.
Credits image: http://www.designexperiences.net/c/21100/967/i-principi-del-design--usabilita-e-user-experience.html
27. HCI >>> User requirements
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Prima fase di progettazione; si tratta di capire
cosa l'utente vuole che faccia il prodotto (vedi
la slide dedicata all'analisi PACT) e come vuole
che lo faccia. Ci嘆 avviene raccogliendo dati,
analizzandoli, ed esprimendoli sotto forma di
requisiti.
E' importante identificare bene le necessit
dell'utente, ed avere una serie di requisiti
stabili, che siano cio竪 sempre giustificati e
correlati ai dati raccolti.
Gli user requirements sono importanti perch竪 senza
obiettivi chiari si rischia di dover tornare sulla
semplice analisi del prodotto pi湛 volte, perdendo
tempo e risorse nel processo.
Credits image: http://www.designexperiences.net/c/21100/967/i-principi-del-design--usabilita-e-user-experience.html
28. Tipologie di requisiti
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
1) Funzionali: Caratteristiche fondamentali del
prodotto; descrivono ci嘆 che il prodotto deve fare e le
operazioni che compie.
Obiettivo principale dei requisiti.
2) Non funzionali: Propriet che le funzioni devono
avere; descrivono i vincoli posti sul sistema ed il suo
sviluppo.
Riguardano vari aspetti: aspetto, sicurezza,
prestazioni. Fondamentali quanto i requisiti funzionali.
3) Dati: tipologia, quantit, persistenza.
4) Contesto d'utilizzo: Fisico, sociale, organizzativo;
30. Gli Utenti
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Chi sono gli utilizzatori finali della sistema, del tuo
software oppure della tua applicazione?
Quanta e quale dimestichezza hanno con i sistemi
Interattivi?
Bene questi sono gli utenti, essi si dividono in queste
categorie:
Novizio == > Ha bisogno di procedure guidate,
informazioni chiare
Esperto == > Ha bisogno di potenza e flessibilit
Frequente == > Shortcut
Occasionale == > Istruzioni chiare
33. User requirements: raccolta dati
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Restando sempre nell'ambito o meglio parlando sempre delle User requirements,
vediamo come funziona la raccolta dati, tecnica indispensabile per lo sviluppo
di un buon sistema/applicazione/software
Ecco le Tecniche Possibili:
a) Studiare la documentazione: spesso sottovalutata come tecnica. Da
comunque un buon punto di partenza per farsi un'idea generale sui punti base e
la legislazione. Da non usare in isolamento. Vantaggio: non necessita di tempo
del stakeholder (tester). Leggi qui significato
b) Osservazione: si tratta di passare del tempo con lo stakeholder nel
contesto in cui verr inserito il prodotto. Aiuta a comprendere bene la natura
dei compiti che esso dovr svolgere. Richiede il tempo di almeno un membro del
team di sviluppo, e pu嘆 produrre una grande mole di dati.
c) Questionari: Una serie di domande, anche di diverso tipo (aperte oppure a
risposta multipla) di solito volte a raccogliere informazioni specifiche.
Ottima fonte di dati quantitativi e qualitativi. Spesso usati in combinazioni
con altre tecniche. Vantaggio: permettono di raccogliere dati specifici da un
grande gruppo di persone.
d) Interviste/Focus groups: Raccolta di dati diretta. Ottimo metodo per
esplorare punti specifici. In caso di focus groups, utile per raccogliere un
punto di vista globale, condiviso o conflittuale. Richiede tempo da entrambe
le parti. Possono essere usati scenari / utenti simulati.
35. User requirements: Tecniche, Persone, Linee Guida
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
36. Le Tecniche & Le Persone giuste
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Continuando a parlare delle User requirements, vediamo insieme
quali tecniche e che tipo di persone dobbiamo scegliere per il
nostro progetto/prodotto.
Le tecniche
La raccolta dati sar ed 竪 influenzata da vari aspetti:
Quantit di tempo a disposizione;
Esperienza dell'analista;
Importanza dell'aspetto studiato;
Livello di dettaglio richiesto;
Le persone:
E' fondamentale scegliere le persone giuste da cui estrapolare
dati.
Per esempio, 竪 pi湛 importante coinvolgere quelli che saranno gli
utenti reali, non i gestori. I soggetti interessati devono essere
coinvolti apertamente, confrontandosi con essi.
Attenzione ai problemi di disponibilit. Se si coinvolgono membri
di gruppi diversi andr usato un linguaggio (tecnico o meno) in
base al livello di esperienza degli stakeholders.
37. Linee Guida
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Linee guida per la raccolta dati sono le seguenti:
Coinvolgere pi湛 gruppi di possibilmente stakeholders, e diversi
rappresentati del gruppo.
Usare varie tecniche di raccolta dati.
Sostenere il processo con prototipi, oggetti, scenari.
Eseguire una sessione pilota.
Valutare bene la registrazione delle informazioni.
A tutto ci嘆 si aggiungono le Personas e Scenarios.
Personas: Si tratta di utenti fittizi, ma realistici, che
rappresentano l'utente finale tipo. Vanno fornite di un contesto di
vita e psicologico, e con diverse personalit.
Scenarios: Come le personas, ma riguardanti dei contesti di
utilizzo. Tecnica chiave ed interattiva, da usare per tutto il
processo di progettazione. Da integrare con user story.
41. 1. Valutare l'usability
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
E' importante capire quando e come 竪 possibile dare un giudizio sull'usability
del prodotto.
Quando fare questo?
In due momenti distinti:
1. Durante la fase di progettazione /sviluppo. (Valutazione formativa)
2. Dopo la distribuzione, per misurare l'efficacia, verificare gli standard e
raccogliere informazioni utili per sistemi futuri. (Valutazione sommativa)
La Valutazione
Anche la valutazione viene fatta sostanzialmente su tre livelli:
1. Esplorazione: Valutare cosa ci vorrebbe per un design adatto alle esigenze
degli utenti. In base a scenary/storyboard.
2. Sviluppo: Progettazione fisica, valutando alternative ed anticipando
guasti.
3. Distribuzione: Migliorare le versioni successive, raccogliendo esigenze per
gli utenti di sistemi futuri. Tecniche di valutazione: Metodologie usate per
raccogliere dati ed informazioni utili a valutare l'usability di un sistema.
42. 1. Valutare l'usability (test)
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Il Test di usability
Viene controllato da un supervisore. Gli utenti sono monitorati e registrati
su video, per verificare le azioni tipiche compiute. Produce diversi tipologie
di dati (performance temporali, errori, azioni svolte). Integrate da
questionari per sollecitare opinioni.
L'analisi pu嘆 essere grossolana o minuziosa. E' necessaria in ogni caso una
certa cura nella raccolta, onde evitare di "affogare" nei dati.
43. 1. Valutare l'usability (tipologie di test)
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Le Tipologie di test sono:
Osservazione semplice: viene dato all'utente un compito e lo si osserva
mentre lo svolge. Problema: l'osservatore controlla le reazioni dell'utente ma
non vede cosa fa.
Think aloud: Mentre l'utente esegue il compito dato dice ad alta voce cosa
sta facendo e cosa sta pensando. Pu嘆 alterare l'esperienza, in quanto causa
imbarazzo e difficolt nel coordinarsi tra l'esecuzione del compito e la sua
descrizione. Pu嘆 aiutare una registrazione video. Aiutare l'utente solo se 竪
strettamente necessario.
Interazione costruttiva: Due utenti svolgono il compito insieme. Rimuove
parzialmente l'imbarazzo. Utilizzando un utente semiesperto ed un novizio
permette di osservare due tipologie diverse di gruppi contemporaneamente (un
utente fa domande e l'altro risponde).
Studi sul campo: Per capire cosa fanno di solito gli utenti e che impatto
abbia la tecnologia su di loro. Particolarmente utile per capire come
introdurre nuove tecnologie e valutare quelle attuali. Metodo piuttosto
caotico: l'osservatore deve integrarsi bene nel contesto e tener conto delle
inevitabili interruzioni. Per aiutarsi pu嘆 forni
44. 1. Valutare l'usability
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
E' importante capire quando e come 竪 possibile dare un giudizio sull'usability
del prodotto.
Quando fare questo?
In due momenti distinti:
1. Durante la fase di progettazione /sviluppo. (Valutazione formativa)
2. Dopo la distribuzione, per misurare l'efficacia, verificare gli standard e
raccogliere informazioni utili per sistemi futuri. (Valutazione sommativa)
La Valutazione
Anche la valutazione viene fatta sostanzialmente su tre livelli:
1. Esplorazione: Valutare cosa ci vorrebbe per un design adatto alle esigenze
degli utenti. In base a scenary/storyboard.
2. Sviluppo: Progettazione fisica, valutando alternative ed anticipando
guasti.
3. Distribuzione: Migliorare le versioni successive, raccogliendo esigenze per
gli utenti di sistemi futuri. Tecniche di valutazione: Metodologie usate per
raccogliere dati ed informazioni utili a valutare l'usability di un sistema.
45. 1. Valutare l'usability (DECIDE)
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Il modello DECIDE:
Questo modello contiene i punti focali per la valutazione dell'usability.
D = Determinare gli obiettivi: Qual'竪 lo scopo della valutazione?
E = Esplorare le domande: Quali sono quelle pi湛 importanti, che meglio
rappresentano il mio studio specifico?
C = Choose: scegliere il paradigma di valutazione e le tecniche che
utilizzer嘆 per lo studio.
I = Identificare i problemi pratici: tempi e fondi a disposizione,
selezionare utenti e attrezzature, etc
D = Decidere sulle questioni etiche: rendere noti agli utenti gli scopi
del test, cosa verr fatto coi dati raccolti, come verranno trattati i loro
dati personali, etc.
E = Valutare i dati raccolti: come presentarli ed interpretarli. Dipende
dal paradigma e dalle tecniche usate.
46. 1. Valutare l'usability (raccolta e analisi)
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Raccolta dei dati:
Pu嘆 essere effettuata in diversi modi; con carta e penna, registrazioni
audio /video, diari degli utenti, etc.
Dipende sempre da cosa voglio Ottenere.
Analisi dei dati:
Qualitativi: classificato analizzandone il contenuto. Raccontano cosa 竪
stato osservato;
Quantitativi: Dati basati su numeri. Richiedono una modellizzazione per
trarne una conclusione.
48. 2. Design di interfacce visive
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Le interfacce dovrebbero essere basate su due principi fondamentali:
Eleganza: design minimale (perci嘆 economico) che per嘆 risolve completamente
il problema proposto;
Semplicit: Minimizzazione dei componenti e semplificazione delle
interazioni tra di essi.
Gli elementi del design dovrebbero essere unificati, per produrre un unico
lavoro coerente, e le parti rifinite per focalizzare l'attenzione dell'utente
sulle parti fondamentali.
Aspetti fondamentali:
Riduzione: Gli elementi devono essere ridotti al minimo indispensabile. Ci嘆
si ottiene analizzando il singolo elemento e chiedendosi se 竪 fondamentale o
se pu嘆 essere sostituito/integrato con un altro. Provare a rimuovere
l'elemento: che conseguenze ci sono sull'interfaccia?
Regolarizzazione: Quando non si pu嘆 pi湛 ridurre, cercare di uniformare gli
elementi, per esempio raggruppandoli per assi comuni (combinazione). Fatto
ci嘆, controllare se ci sono elementi ridondanti nel sistema e in generale
cerca di uniformare gli elementi dell'interfaccia.
50. 3. Interviste e analisi dei dati
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Ecco come sono divise le interviste e analisi dei dati:
Pianificare una serie di domande centrali, focalizzate sull'argomento
generale dell'intervista.
Incentrare l'intervista (anche sulle osservazioni dell'utente).
Iniziare con domande facili, e poi spostarsi verso quelle pi湛 difficili. In
ogni caso formulare domande semplici e chiare.
Evitare domande la cui risposta potrebbe essere solo s狸 /no.
Usare scenari, spunti, sondaggi.
Testing retrospettivi: Consistono nel far interagire un utente con un
prodotto, riprenderlo durante il compito e poi confrontarsi con esso,
mostrandogli il video e analizzando insieme le sue reazioni.
Analisi dei dati raccolti: Una volta raccolti i dati, andranno rielaborati
trascrivendo le interviste, aggiungendo note e commenti ed effettuando
semplici analisi qualitative (verifica incidenti critici, estrapolazione di
temi ricorrenti, categorizzazione dei dati, ecc...).
52. 4. Questionari
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
I questionari altro non sono che una serie predefinita di domande in un dato
ordine.
Vengono proposti sia per valutare l'usability che l'user experience. I
questionari possono essere self administrated o gestiti dal ricercatore.
Indagine: Analisi statistica fatta estraendo un campione da una data
popolazione. Utile per comprendere il comportamento medio di una popolazione,
ma non sempre realizzabile come metodo.
I dati ottenuti devono essere modellizzati secondo schemi statistici.
Questionari del design: Devono essere ben sviluppati per ottenere le risposte
che vuoi dall'intervistato. Tali risposte devono essere valide, e utili per il
ricercatore.
Bisogna cio竪 definire lo scopo dell'intervista, definire le aree tematiche,
comporre e controllare gli oggetti, etc.
53. 4. Questionari
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Aspetti focali:
Controllare tempo impiegato per rispondere, formulazione domande, ambiguit,
omissioni, chiarezza layout.
Domande: devono essere rilevanti ai fini del questionario e chiare
grammaticalmente; evitare domande negative e doppie (ad es. il sito 竪 chiaro E
affidabile?);
Evitare gergo o linguaggio troppo tecnico.
Formulare domande corte.
Evitare di veicolare le domande verso risposte che vorremmo sentire.
Tipologie dimande:
Aperte: Buone per ottenere informazioni generali, ma difficili da
analizzare.
Chiuse: Facili da analizzare, ma richiedono una certa attenzione
nell'interpretazione della risposta.
Scala di gradimento: Una data affermazione viene giudicata in una scala
numerica.
Scala differenziale: Coppie di aggettivi opposti, con una scala numerica
che
pende verso una o l'altra parte.
Aspetto del questionario:
Numerare le domande;
Evitare di dividere una domanda su pi湛 pagine;
Terminarlo con un ringraziamento, e stabilire la deadline in modo chiaro;
L'ordine delle domande deve essere logico e comprensibile, cos狸 come le
modalit di risposta ad esse;
Rendere il questionario piacevole;
55. 4. Processi cognitivi
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
L'interazione con la tecnologia richiede un certo numero di processi
cognitivi, che vanno tenuti in considerazione nella progettazione dei
prodotti.
In particolare, bisogna tener conto della diversit degli utenti
(caratteristiche e limitazioni), prevedere cosa essi si aspettano di poter
fare o non fare, cercare di identificare le cause e la natura dei problemi in
cui essi potranno incorrere, etc.
Processi cognitivi fondamentali:
Attenzione: Capacit di restare concentrati su un elemento specifico;
risorsa limitata; implicazione nel design: le informazioni dell'interfaccia
devono essere strutturate in modo da catturare l'attenzione degli utenti. Le
parti rilevanti devono essere rese evidenti tramite colori, spaziature e
simili. Evitare di appesantire/disordinare l'interfaccia.
Percezione: Come l'informazione viene acquisita dal mondo esterno e
trasformata in esperienza; implicazione nel design: rendere le informazioni,
indipendentemente dalla tipologia, il pi湛 possibile distinguibili.
56. 4. Processi cognitivi (Psicologia Gestalt)
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Quando degli elementi sono posti in gruppo per definire un oggetto,
tendiamo a vedere il gruppo nel suo insieme e non l'oggetto singolo.
La psicologia della forma (Gestalt in tedesco) studia i vari elementi
che compongono tale fenomeno.
Alcuni esempi:
Similarit: Elementi che condividono le stesse caratteristiche
visive vengono percepite come se fossero una cosa sola. Se c'竪 una
somiglianza ma
l'oggetto 竪 diverso, questo pu嘆 essere enfatizzato per distinguerlo;
in tal
modo attirer l'attenzione. Si parla in questo caso di anomalia.
Prossimit: Elementi messi vicini vengono percepiti come insieme
unico.
Destino comune: Elementi che si muovono nella stessa direzione
vengono
percepiti come un insieme unico.
Chiusura: Avviene quando un oggetto grafico 竪 incompleto. Se si
hanno abbastanza informazioni, la forma verr completata
automaticamente aggiungendo gli elementi mancanti.
In conclusione, la psicologia Gestalt pu嘆 essere utilizzata nello
sviluppo di interfacce utente, in particolare per quanto riguarda la
visibilit, la comprensibilit e la struttura logica della stessa.
58. Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
SI....... Ecco le conclusioni
59. Introduzione
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Eccoci giunti in fondo a queste slide, mi auguro come sempre di esservi
stato utile e soprattutto mi auguro che con le mie parole sia stato chiaro
nel spiegarvi i vari argomenti.
60. Link Utili
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
http://it.wikipedia.org/wiki/Interazione_uomo-computer
http://it.wikipedia.org/wiki/Jakob_Nielsen
http://it.wikipedia.org/wiki/Stakeholder
http://en.wikipedia.org/wiki/User_story