Corso di Design dell’Interazione, modulo 1, ovvero
Interaction Design
Lezione 3 / 18 marzo 2009
http://www.siti.disco.unimib.it/didattica/id2009
Marco Loregian
loregian@disco.unimib.it

Dove siamo...
L’interaction design nasce per risolvere
problemi, a partire da idee
Esistono approcci diversi alla progettazione
...e dove andiamo
La ricerca di design
Strumenti degli interaction designer
L’arte dell’interaction design

Ricerca di design

Per gli interaction designers è
essenziale sapere cosa succede
attorno a loro: innovazioni,
tendenze, ...
Molti designers non la fanno, invece è
essenziale per avere empatia
Ricerca di design: indagine del
potenziale di un prodotto o servizio,
degli utenti esistenti e dell’ambiente
Mix di metodi da antropologia, ricerca
scientifica e sociologica, teatro,
design, ...

Fare ricerca di design
Andare :: Parlare :: Annotare
Come fanno gli antropologi

Andare :: Parlare :: Annotare
Non forzare le persone in situazioni innaturali
Non fidarsi troppo di ricerche altrui
Non affidarsi a trascrizioni da riesaminare

Ricerca etica
Consenso informato
Spiegare rischi e benefici
Rispettare la privacy
Ricompensare
Fornire i risultati

Costi e tempi
Molti fattori di cui tenere conto:
Materiali di consumo (carta, ...),
materiale di test (video, prototipi),
materiale per il test (videocamere,
registratori), ...
Tempo di reclutamento, esecuzione,
analisi, raffinamento,
pubblicazione, ...

Cosa cercare e come registrarlo
Obiettivo chiaro a priori (hunt statement)
Schemi e fenomeni
Note sul campo per ricostruire l’osservazione

Osservazioni
Mosca sul muro
Shadowing
Metodi di ricerca
Indagine contestuale (perché?)
Agente sotto copertura
Interviste
Storytelling guidato
Unfocus group
Gioco di ruolo
Utenti estremi
Tour delle scrivanie/borsette/…
Attività
Collage
Modelli
Disegna l’esperienza
Auto-rapporto (diari, ...)

...e poi?
Analisi e brainstorming… e poi?

L’arte
dell’interaction design

Strumenti del mestiere

Scenario-based design

Introduzione
Requisiti (in senso lato): affermazioni sulle situazioni di uso, bisogni
dell’utente, opportunità offerte dal sistema, trasformazioni degli usi correnti, ...
Analisi dei requisiti:
Modelli tradizionali dell’ingegneria del Participatory design: lavoro congiunto
di utenti e progettisti, scambio
software (cascata, …): cicli di
richieste/offerte tra progettisti e di prospettive
clienti
approcci basati su risultato più accurato
decomposizione e controllo
i requisiti emergono nel corso
nuove features, tecnologie, … delle attività, e ogni attività evoca
viste differenti del problema, e si
elicitano requisiti di diverso tipo

i}
ic
at
Use cases
m
for
i in
l
rg
e
{p
Specifiche di possibili casi d’uso astratti,
possibili sequenze di eventi (istanze)
Espressi in UML in forma diagrammatica
Non esprimono gli aspetti di utilità e
usabilità di un sistema
Non sono articolati a livello cognitivo
(non esprimono gli obiettivi dell’utente,
aspettative, reazioni, ...)
Non sono parte del contesto per il
processo di design del prodotto (del
“design rationale”, poiché esprimono le
funzionalità, non le caratteristiche)
http://www.iua.upf.edu/~dgarcia/Codders/DotUmlUseCases.html

Scenarios are stories
Scenario: Textual description or narrative of a use episode
Described from the user point of view and may include social
background, resource (e.g. disk space, time) constraints and
background information
May describe a currently occuring use, or a potential use that is
being designed and may include text, video, pictures, story boards,
etc.
By using a narrative it is possible to capture more information
about the user's goals, and the context the user is operating in
The context might include details about the work place or social
situation, and information about resource constraints. This
provides some more help in understanding why users do what
they do. In much current design work the users goals and context
are often assumed implicitly, or may not be taken into account

Scenario-Based Design
The scenario becomes the design object or artifact and may be
augmented and rearranged as the design evolves
It can become a hypothetical interaction scenario for a new
design and allow better understanding of the new design
It is also desirable to maintain a history of past scenarios as a
way of capturing past design rationale
In one sense scenarios are not really new in design activity
It's extremely common in design to imagine “what if”
situations, or to walk through a design in ones mind or in a
group
Scenario-based design is an effort to make some of what we
do already more conscious and explicit

Scenari
Gli scenari evidenziano gli obiettivi
suggeriti dall’aspetto (interfaccia utente,
affordances) e dal comportamento (interno e
visibile) del sistema, e cosa gli utenti
cercano di fare col sistema stesso (quali
procedure sono adottate, quali scartate,
quali errori si commettono, ...)
Aiutano a spiegare i flussi di azioni
(workflow, vd. activity-centered design), e ad
evidenziare le situazioni critiche (breakdown)

Elementi caratteristici di
uno scenario
Ambientazione
Agenti e attori, con i
na
rispettivi (sub)goal e
sor
Pe
obiettivi
Trama: azioni ed eventi,
con (eventuali) conseguenti
cambi di obiettivi

Prototipazione degli scenari
Ideazione
Scelta di una
tecnica narrativa
Presentazione
Sviluppo
della
narrativa ...complicare a
piacere

Tecniche narrative
Testo
Storyboard, vignette
Video
Rappresentazione dal
vivo (anche partecipata)

Sviluppo della narrativa,
per esempio: CeltX
http://www.celtx.com
Software free e multipiattaforma per
scrivere (e condividere)
sceneggiature
Da usare per i primi step
Per il progetto, potete scegliere a
che livello fermarvi, o quale
approfondire
Screencasts:
http://www.celtx.com/walkthru/

Le sfide della progettazione
tramite scenari
La riflessione nel design
Le situazioni nel design sono
fluide
Le scelte di design hanno
molteplici conseguenze
Tecnologia al servizio del design,
non viceversa
Vincoli esterni (di lavoro) al
design

I progettisti devono continuamente
Design e
riflettere sia sul prodotto che sul loro
ruolo nel processo
riflessione
Gli scenari aiutano a confrontarsi con
persone con ruoli, esperienze, e percezioni
diverse
Ogni proposta è frutto di una visione
parziale del problema
La creazione collaborativa di scenari aiuta a
conciliare concretamente differenti visioni
La discussione degli scenari aiuta ad avere
awareness del processo
Gli scenari aiutano a superare le barriere
imposte dallo sviluppo di prototipi
“tecnologici”

Conoscenza tecnica e design
Rigore tecnologico vs. immaginazione di nuove soluzioni
Elaborare uno scenario non corrisponde alla definizione
precisa/algoitimica di una soluzione tecnica/tecnologica ma
solo dei requisiti e delle caratteristiche ad alto livello
Si descrive il comportamento di un sistema a macro-
passi, poi per l’implementazione nel dettaglio “si
vedrà” (fatto salvo che bisogna essere realistici, e
quindi avere idee precise sulla tecnologia)
Gli scenari possono essere astratti e categorizzati
L’elaborazione degli scenari (documentazione su diverse
istanze del problema) può portare nuova conoscenza tecnica

Scenari e Fluidità
L’analisi è sempre un po’ incerta, perché il mondo cambia di
continuo (grazie al design stesso)
Specialmente quando la progettazione incorpora tecnologie
in rapida evoluzione: più una proposta ha successo, maggiore
sarà la sua variabilità Ci sono aspetti positivi e negativi, esempi:
Positivi: continua spinta all’innovazione,
evoluzione del business e delle condizioni di
vita, ...
Negativi: impatto sull’ambiente a discapito della
sostenibilità, le skill possedute e richieste
cambiano di continuo (forte instabilità del
mercato del lavoro e della formazione); l’instabilità
si ripercuote spesso anche sul finanziamento dei
progetti (grandi flop), …

Scenari e
Fluidità
Gli scenari hanno il grande pregio di essere concreti
(soluzioni precise e specifiche per evitare il rischio di essere
assorbiti dall’indeterminatezza) e flessibili (rivisitazioni e
correzioni per adeguarsi al cambiamento) al tempo stesso
Prototipazione iterativa e raffinamento
Punti fissi nel processo (“milestones”)
Accessibili a persone con skill molto diverse

Fattori esterni e vincoli
La progettazione è basata sui vincoli, altrimenti ci sarebbero troppe cose da
fare
Ricordate: progettare vuol dire fare scelte precise e consapevoli
I requisiti, se identificati, sono la prima fonte di vincoli
La tecnologia rende alcune scelte impossibili (perché non esiste soluzione) ed
altre irresistibili (perché di moda o fortemente affermate)
Esistono vincoli reali ed altri solo fittizi/superabili
es., non far digitare i manager (lavoro da segretarie)
Bisogna evitare o valutare bene gli stereotipi per mantenere il processo di
progettazione nel caso reale
Gli scenari sono work-oriented: devono mostrare il sistema all’opera, con
l’utente
Tutti gli stakeholders devono essere rappresentati in uno scenario

Valutazione delle conseguenze
Ogni scelta progettuale ha delle
conseguenze: una caratteristica di
un prodotto influenza le altre
es. estetica vs. acustica vs. proprietà
meccaniche di uno strumento musicale
Gli scenari possono essere usati
per presentare prospettive diverse
es. annotazioni testuali vs. vocali ←→
overhead vs. frustrazione
Le relazioni fra i diversi fattori sono
lasciate implicite ma i possibili
aspetti critici possono essere molto
dettagliati

Sintesi
Il problema fondamentale è
incoraggiare, supportare e direzionare
in maniera produttiva la riflessione
presente nel processo di
progettazione
I progettisti riflettono, pur sapendo
che è impossibile ponderare tutto
(effetti, dipendenze, ...)
Gli scenari fanno progredire verso una
soluzione (almeno scartando alcune
opzioni)

interaction
time!
Scenari

http://www.onepuglaundry.com/dublin.htm

http://commons.wikimedia.org/wiki/File:Estacio_bicing_bcn.jpg

http://mobilepayment.typepad.com

Da leggere
Carroll, J. M. 1999. Five Reasons for Scenario-Based Design. In
Proceedings of the Thirty-Second Annual Hawaii international
Conference on System Sciences-Volume 3 - Volume 3 (January 05 - 08,
1999). HICSS. IEEE Computer Society, Washington, DC, 3051.
http://ieeexplore.ieee.org/iel5/6293/16783/00772890.pdf
Riferimenti & Credits
http://ldt.stanford.edu/~gimiller/Scenario-Based/scenarioIndex2.htm
Dan Saffer, Design dell’interazione, Pearson Education (capitoli 4, 5)