HCI -> Human Computer Interaction

HCI >>> Human-Computer Interaction
Autore: Flavius Florin Harabor
e-mail: ffinformaticus@gmail.com
Credits image: http://openclassroom.stanford.edu/MainFolder/CoursePage.php?course=HCI

Introduzione
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.

HCI >>> Definizione
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.

HCI

ID >>> Interaction Design
Credits image: http://a2ru.org/knowledgebase/ixd-fundamentals/

Interaction Design
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

User Centric
Credits image: http://bayini.com/blog/clear-communication-through-ux-or-why-user-centric-design-matters-in-enterprise-mobility/

User Centric
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

User Centric >>> PACT
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.

Ciclo di progettazione >>> User Centric
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.

HCI NON È SOLO QUESTO
Credits image: http://www.unapsicologaroma.it/2013/03/20/quando-si-dice-unilluminazione/

Principi di design
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.

Esempi
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.

Usability

HCI >>> Usability {usabilità}
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.

Principi di usabilità
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à.

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;

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;

Leggi Qui >>> http://www.tomshw.it/cont/articolo/windows-8-l-interfaccia-e-il-peggior-difetto-e-la-migliore-scommessa/41244/1.html

User Experience

HCI >>> User Experience (UX)
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

User requirements

HCI >>> User requirements
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

Tipologie di requisiti
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;

Gli Utenti
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

User requirements: raccolta dati
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.

User requirements: Tecniche, Persone, Linee Guida

Le Tecniche & Le Persone giuste
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.

Linee Guida
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.

Abbiamo finito?

Mancano solo 5 semplici argomenti

1. Valutare l'usability
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.

1. Valutare l'usability (test)
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.

1. Valutare l'usability (tipologie di test)
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

1. Valutare l'usability (DECIDE)
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.

1. Valutare l'usability (raccolta e analisi)
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.

2. Design di interfacce visive
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.

3. Interviste e analisi dei dati
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...).

4. Questionari
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.

4. Questionari
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;

4. Processi cognitivi
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.

4. Processi cognitivi (Psicologia Gestalt)
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.

SI....... Ecco le conclusioni

Introduzione
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.

Link Utili
➔ 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

HCI -> Human Computer Interaction

More Related Content

Similar to HCI -> Human Computer Interaction

More from Flavius-Florin Harabor

HCI -> Human Computer Interaction