Interaction DesignLezione 3 / 18 marzo 2009

Marco Loregianloregian@disco.unimib.it

Corso di Design dell’Interazione, modulo 1, ovvero

http://www.siti.disco.unimib.it/didattica/id2009

Dove siamo...L’interaction design nasce per risolvere problemi, a partire da idee

Esistono approcci diversi alla progettazione

...e dove andiamoLa 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, ...

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

Molti designers non la fanno, invece è essenziale per avere empatia

Andare :: Parlare :: Annotare

Fare ricerca di design

Come fanno gli antropologi

Non forzare le persone in situazioni innaturali

Non fidarsi troppo di ricerche altrui

Non affidarsi a trascrizioni da riesaminare

Andare :: Parlare :: A

nnotare

Ricerca etica

Consenso informatoSpiegare rischi e beneficiRispettare la privacyRicompensareFornire 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 fenomeniNote sul campo per ricostruire l’osservazione

Met

odi d

i ric

erca

OsservazioniMosca sul muroShadowingIndagine contestuale (perché?)Agente sotto copertura

Interviste Storytelling guidato Unfocus group Gioco di ruolo Utenti estremi Tour delle scrivanie/borsette/…

AttivitàCollageModelliDisegna l’esperienzaAuto-rapporto (diari, ...)

...e poi?

Analisi e brainstorming… e poi?

L’artedell’interaction design

Strumenti del mestiere

Scenario-based design

Requisiti (in senso lato): affermazioni sulle situazioni di uso, bisogni dell’utente, opportunità offerte dal sistema, trasformazioni degli usi correnti, ...

Analisi dei requisiti:

Introduzione

Modelli tradizionali dell’ingegneria del software (cascata, …): cicli di richieste/offerte tra progettisti e clienti

approcci basati su decomposizione e controllo

nuove features, tecnologie, …

Participatory design: lavoro congiunto di utenti e progettisti, scambio di prospettive

risultato più accurato

i requisiti emergono nel corso delle attività, e ogni attività evoca viste differenti del problema, e si elicitano requisiti di diverso tipo

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)

Use cases

http://www.iua.upf.edu/~dgarcia/Codders/DotUmlUseCases.html

{ per

gli info

rmatic

i }

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

Scenarios are stories

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

Scenario-Based Design

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)

Scenari

Ambientazione

Agenti e attori, con i rispettivi (sub)goal e obiettivi

Trama: azioni ed eventi, con (eventuali) conseguenti cambi di obiettivi

Elementi caratteristici di uno scenario

Perso

na

IdeazioneScelta di una

tecnica narrativa

Sviluppo della

narrativa

Presentazione

...complicare a piacere

Prototipazione degli scenari

Testo

Storyboard, vignette

Video

Rappresentazione dal vivo (anche partecipata)

Tecniche narrative

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/

Sviluppo della narrativa,per esempio: CeltX

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

Le sfide della progettazione tramite scenari

I progettisti devono continuamente riflettere sia sul prodotto che sul loro ruolo nel processo

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”

Design e riflessione

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

Conoscenza tecnica e design

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à

Scenari e Fluidità

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

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

Fattori esterni e vincoli

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

Valutazione delle conseguenze

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)

Sintesi

interaction time!

Scenari

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

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

http://mobilepayment.typepad.com

Riferimenti & Creditshttp://ldt.stanford.edu/~gimiller/Scenario-Based/scenarioIndex2.htm

Dan Saffer, Design dell’interazione, Pearson Education (capitoli 4, 5)

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

Da leggere