1. Interaction Design
23 marzo 2010
Marco Loregian
loregian@disco.unimib.it

2. Scenario-based design

3. 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
software (cascata, …): cicli di di utenti e progettisti, scambio
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

4. ic i}
at
e rg
li in
for
m
Use cases
{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

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

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

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

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

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

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

11. 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/

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

13. I progettisti devono continuamente
riflettere sia sul prodotto che sul loro
ruolo nel processo Design e
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”

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

15. 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), …

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

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

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

19. 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)

20. interaction
time!
Scenari

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

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

23. http://mobilepayment.typepad.com

24. 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)