lezione interaction design 18 marzo 2009
Upcoming SlideShare
Loading in...5
×
 

lezione interaction design 18 marzo 2009

on

  • 1,839 views

lezione interaction design 18 marzo 2009

lezione interaction design 18 marzo 2009

Statistics

Views

Total Views
1,839
Views on SlideShare
1,839
Embed Views
0

Actions

Likes
0
Downloads
60
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    lezione interaction design 18 marzo 2009 lezione interaction design 18 marzo 2009 Presentation Transcript

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