Presentazione AscariSlide 1 (Copertina)

Buongiorno, siamo qui su invito della Prof.sa Agostini per presentarvi il progetto che abbiamo fatto per il corso di Interaction Design dello scorso anno. -click-

Slide 2 (Obiettivi)

Come prova del corso era prevista la progettazione di un oggetto o sistema interattivo asupporto di un singolo e/o di una comunità di utenti.Non si era però liberi di utilizzare qualsiasi cosa, in particolare era permesso ed incentivato l’uso di dispositivi mobili - eventualmente con degli schermi - ma su di essi non era possibile rappresentare informazioni testuali; era inoltre caldamente consigliato progettare dispositivi completamente nuovi. -click-

Slide 3 (Come, non Cosa)

Pensiamo che presentarvi il risultato finale del progetto sia poco utile dal vostro punto di vista, crediamo invece che sia più interessante condividere con voi la nostra esperienza del processo che ha portato alla sua realizzazione. Per questo nel seguito della presentazione vedremo come, partendo dall’analisi del contesto ed utilizzando le tre cose scritte in mezzo - requisiti persone e scenari - siamo riusciti a passare dall’idea iniziale al prototipo. Iniziamo! Il punto di partenza del progetto è, ovviamente, la scelta del tema, o, meglio, del dominio. -click-

Slide 4 (Scelta Dominio)

Nel caso di questo progetto il dominio doveva comprendere una comunità operante in un’area geografica ben definita (ad esempio un edificio, un insieme di edifici, una città, eccetera), con cui era necessario prendere diretto contatto. Inoltre, ai fini del progetto, era importante che all’interno dell’attività della comunità stessa ci fossero aspetti migliorabili, in cui fosse insomma possibile inserirsi con strumenti tecnologici di supporto. -click-

Slide 5 (Scelta Dominio - Il nostro caso)

La nostra scelta è caduta sui commissari di percorso dell’Autodromo di Monza. Semplificando molto, i commissari sono delle persone che, durante le gare, sono posizionate ai lati della pista e segnalano ai piloti varie situazioni sventolando delle bandiere colorate; essi intervengono inoltre in pista a soccorrere i piloti in caso di incidente. In questo ambito sappiamo, perché Andrea è uno dei volontari che ne fanno parte, ci sono problemi dovuti alla difficoltà di comunicazione ed alla mancanza di informazioni. Il nostro progetto si propone appunto di risolvere questi problemi nel modo più completo possibile. Per darvi un’idea del tempo impiegato nello svolgere il progetto abbiamo messo nelle slide delle icone che contengono una stima delle ore impiegate per le varie fasi. -click-In questo caso, come potete vedere, per decidere il dominio abbiamo impiegato circa una giornata di lavoro, 6 ore. -click- Q: Puoi specificare meglio i problemi?A: Il problema principale che abbiamo riscontrato in questa comunità riguarda la comunicazione. Per il forte rumore e per la mancanza di convenzioni, i commissari di percorso fanno fatica a comunicare da una postazione all’altra, spesso ci sono incomprensioni oppure viene impiegato molto tempo prima che la comunicazione arrivi al destinatario.

L’altro problema, quello relativo alla mancanza di informazioni, è particolarmente rilevante quando è necessario fare certe segnalazioni. Spesso infatti sarebbe utile ai commissari conoscere la posizione delle vetture in classifica e sul tracciato, informazione che ad ora non hanno direttamente a disposizione.

Slide 6 (Analisi Dominio)

Una volta scelto il tema bisognava capire se gli aspetti migliorabili, per come percepiti da noi che non facciamo parte della comunità, valessero anche all’interno de essa. Era cioè necessario approfondire la conoscenza del dominio, chiedendo effettivamente conto di queste difficoltà alle persone che vi sono immerse.Gli strumenti principali di questa fase di raccolta informazioni sono ovviamente l’osservazione diretta e le interviste. In questo modo è possibile avere conferma delle problematiche presenti nel dominio. Per capire se queste problematiche valgono per tutta la comunità oppure soltanto per la parte che si è intervistata, si possono somministrare dei questionari in modo da raggiungere un maggior numero di persone. In ogni caso, l’obiettivo di questa fase è quello di capire con precisione che cosa funziona bene nel dominio, e che cosa invece è migliorabile; entrambi gli aspetti vanno capiti nel modo più chiaro possibile perché saranno fondamentali nei passi successivi. -click-

Slide 7 (Analisi Dominio - il nostro caso)

Noi, che avevamo già un’idea delle problematiche, abbiamo utilizzato le interviste per saperne di più sul contesto e abbiamo poi utilizzato un questionario - somministrandolo ad un buon numero di commissari tramite Google Docs - per confermarle ed estenderle. -click-L’analisi di dominio è stata la parte più impegnativa del progetto, ci abbiamo messo 80 ore circa. -click-

Slide 8 (Requisiti - Cosa)

Una volta analizzato il dominio ci siamo concentrati sui requisiti del nuovo prodotto che saremmo andati a progettare.I requisiti sono un elenco di frasi molto semplici che descrivono ciò che il prodotto deve fare e non come deve farlo. In questa fase infatti è fondamentale schematizzare le funzionalità del prodotto nel modo più chiaro e conciso possibile per avere una solida base per le fasi successive. Poichè abbiamo fatto spesso riferimento ai requisiti nelle fasi seguenti abbiamo trovato comodo identificarli ognuno con un codice. Abbiamo capito che la cosa importante in questa fase è descrivere le cose ad alto livello cercando di concentrarsi più sulla vista d’insieme che sui dettagli, nei quali si rischia di perdersi. -click-

Slide 9 (Requisiti - Tipi)

Durante la stesura dei requisiti li abbiamo suddivisi, come spesso si fa, tra funzionali e non funzionali. I requisiti funzionali sono quelli che dicono qualcosa sui servizi che il prodotto deve erogare, cioè sono quelli che effettivamente dicono “cosa”. Invece i requisiti non funzionali sono delle aggiunte, che specificano ulteriori informazioni o aggiungono vincoli rispetto a quanto scritto nei requisiti funzionali. -click-

Slide 10 (Requisiti - Tipi - Il nostro caso)

Per spiegare meglio il concetto abbiamo riportiamo due esempi dal nostro progetto. Il primo è un requisito funzionale “Indicazione delle bandiere che la propria postazione, quella precedente e quella successiva stanno esponendo”. Indipendentemente dal testo in particolare, è possibile ritrovare tutte le caratteristiche che abbiamo elencato prima: la frase è semplice e concisa e dice qualcosa su che cosa il sistema deve fare.Il secondo è un requisito non funzionale “Resistenza alle intemperie”. Questo non ha ripercussioni sulle funzionalità del sistema ma ha a che fare con le condizioni in cui il prodotto andrà ad operare, pone dei vincoli su come il prodotto dovrà essere realizzato. -click-

Slide 11 (Requisiti - Specificazione)

Dopo aver stilato una lista essenziale dei requisiti li abbiamo considerati ognuno singolarmente e ne abbiamo data una descrizione dettagliata.Per capire se il requisito era effettivamente valido ci siamo sforzati di giustificarlo tramite una motivazione e lo abbiamo corredato con luna descrizione delle problematiche che risolve. È un compito impegnativo che però consente di passare alla fase successiva sapendo che tutto quello che è stato scritto non dovrà più essere messo in discussione. -click-

Slide 12 (Requisiti - Specificazione - Importante)

Durante questa fase è fondamentale formulare i requisiti stando attenti a non sovrapporsi con ciò che, nel dominio, funziona già bene. -click-

Slide 13 (Requisiti - Specificazione - Il nostro caso)

Per giustificare ogni requisito abbiamo cercato un esempio pertinente in cui fosse necessaria una certa informazione o una certa funzionalità stando sempre attenti a non togliere responsabilità e a non svalorizzare il compito degli utenti - cosa che, nel nostro ambito in particolare, era molto facile fare. -click-Per l’analisi dei requisiti, fra formulazione e specificazione, abbiamo impiegato circa 24 ore. -click- Q: Puoi specificare meglio come con un esempio?A: Potevamo impiantare dei pannelli luminosi che segnalavano automaticamente la bandiera da esporre.

Slide 14 (Costruzione delle Persone)

Nella fase successiva abbiamo cercato di identificare i possibili utilizzatori del prodotto.Dall’analisi del dominio era emerso che, bene o male, gli utenti del sistema si dividevano in due gruppi omogenei per caratteristiche. Siamo partiti da questa idea e l’abbiamo sviluppata, costruendo una persona per ogni gruppo. Per farlo abbiamo preso una foto e abbiamo cercato di immaginare tutti gli aspetti della vita della persona ritratta, concentrandoci in particolar modo sui gusti, sulle abitudini e sul lato psicologico.In generale, la descrizione delle persone non deve essere estratta da una persona conosciuta ma deve essere frutto della nostra fantasia.Abbiamo visto che l’aver costruito le persone ci ha aiutato durante le scelte di design, tramite domande del tipo: “Che cosa farebbe Marco in questa situazione?” “Michele come interpreterebbe questo simbolo?” e simili. -click-

Slide 15 (Costruzione delle Persone - Il nostro caso)

Anche se inizialmente ci è sembrato un compito lungo e difficile, nello farlo ci siamo fatti coinvolgere dalle vite delle nostre persone al punto da esagerare con i dettagli in alcune parti. Come già detto abbiamo identificato due ruoli, personificati in Pietro, il commissario principiante, e Filippo, il commissario esperto. Per la costruzione ci siamo serviti del Persona Creation and Usage Toolkit di George Olsen, di cui trovate riferimenti in fondo alla presentazione. -click-La costruzione delle persone è stata piuttosto veloce, per farla ci abbiamo messo 18 ore circa. -click-

Slide 16 (Ideazione del prodotto)

Arrivati a questo punto avevamo già in mente cosa andare a sviluppare. Abbiamo visto che però le idee erano piuttosto confuse, e abbiamo quindi deciso che era meglio non perdersi nei dettagli, abbiamo raccolto le idee e siamo ripartiti dai requisiti per organizzarle. Il nostro consiglio in questa fase è di non essere troppo frettolosi ma prendersi il tempo necessario per definire con una certa precisione, anche se ad alto livello, il prodotto immaginato. -click-

Slide 17 (Ideazione del prodotto - Il nostro caso)

Nel nostro caso siamo arrivati all’ideazione di due dispositivi. Una specie di palmare touch screen che abbiamo chiamato Racelet e un dispositivo simile ad un tablet pc che abbiamo chiamato Raceon. Abbiamo diviso le varie funzionalità ai due dispositivi, ne abbiamo fatta una descrizione in termini generali e abbiamo cercato di immaginarci come fossero fisicamente. Per rendercene maggiormente conto abbiamo anche fatto dei semplici modelli 3D tramite Google Sketch Up. -click-L’ideazione del prodotto è maturata lentamente durante le fasi precedenti, a livello quasi inconscio, tanto che avevamo già praticamente in testa tutti la stessa cosa. La discussione collettiva per definire i particolari è durata non più di mezza giornata. -click-

Slide 18 (Prototipo di interazione - Scenario esistente)

Dopo aver tratteggiato il prodotto bisogna entrare nel dettaglio, andando ad analizzare tutte le interazioni possibili fra il prodotto e gli utenti. Nel nostro caso si trattava sostanzialmente di progettare un’interfaccia grafica per questi dispositivi. Abbiamo visto che partire direttamente con la progettazione dell’interfaccia risulta controproducente: è necessaria una guida che consenta di mantenere una certa direzione oppure ci si perderà facilmente. Perciò ci siamo serviti degli scenari; abbiamo iniziato identificando delle situazioni rilevanti e le abbiamo descritte accuratamente, mettendo in evidenza le problematiche. Si parla, in questa fase, di scenari che descrivono il dominio prima dell’introduzione del prodotto. -click-

Slide 19 (Prototipo di interazione - Scenario esistente - Il nostro caso)

Gli scenari non devono essere molti, l’importante è che coprano tutti i casi più rilevanti al giusto livello di dettaglio. Per il nostro progetto è stato sufficiente identificare tre casi, che insieme coprivano tutte le situazioni critiche. -click-

Slide 20 (Prototipo di interazione)

Dopo aver descritto gli scenari nella situazione attuale li abbiamo ripresi in mano e ripercorsi punto per punto inserendovi le interazioni con il nuovo prodotto, a sostituire o integrare quello che già c’era nel sistema esistente.Nel farlo ci siamo trovati a discutere tutti i dettagli del rapporto fra il prodotto e gli utenti, abbiamo cioè descritto le interazioni nei minimi particolari, ad esempio: “l’utente preme il bottone X”, “il dispositivo reagisce con una breve vibrazione”, eccetera. Seguendo questa procedura ci sono venute subito in mente moltissime idee. L’inizio è stato concitato, ma in breve tempo ci siamo resi conto che stavamo facendo molta confusione. Non avevamo un modo chiaro per fissare le idee. Per risolvere questo problema... -click-

Slide 21 (Prototipo di interazione - Strumenti)

... siamo ricorsi a dei mockup cartacei. Abbiamo stampato un certo numero di maschere della dimensione degli schermi dei nostri due dispositivi e le abbiamo usate come base per disegnarvi l’interfaccia. Abbiamo scoperto che è un modo estremamente veloce ed efficace di dare forma alle proprie idee, che consente da subito di testare l’interfaccia, notarne i difetti e correggerli.Le domande tipiche che possono aiutare a capire le cose in questa fase sono: “Come faccio a fare questo?”, “Se faccio questa azione in questo momento cosa succede?”, eccetera. -click-

Slide 22 (Prototipo di interazione - Revisione)

Dopo aver ripercorso tutti gli scenari ed aver specificato le interazioni passo passo abbiamo ripreso in mano i requisiti per assicurarci di aver soddisfatto sia quelli funzionali che quelli non funzionali. Nel farlo ci siamo trovati a dover modificare, a volte anche radicalmente, l’interfaccia, tanto che questa fase di revisione è risultata alla fine pesare molto sul risultato finale. -click-

Slide 23 (Prototipo di interazione - Risultati)

Al termine della fase di progettazione avevamo quindi completato i nuovi scenari - che includono l’utilizzo del prodotto - ed un mockup completo e dettagliato del funzionamento del sistema.Gli scenari completi, a questo punto, rendono evidente l’impatto del nuovo prodotto sul dominio mettendo in luce anche la bontà dell’idea avuta. -click-Per sviluppare gli scenari, fra formulazione di quelli esistenti e aggiunta/integrazione con le interazioni ci sono volute circa 30 ore, mentre per lo sviluppo del mockup, con tutto quello che compete... -click-...circa 42 ore. A questo punto è sorto il problema di come presentare il nostro lavoro. I mockup cartacei sono infatti piedi di appunti e correzioni, non sono in sequenza e non sono navigabili da chi non abbia partecipato alla progettazione - a volte, neanche da chi vi ha partecipato. Inoltre, essendo un’interfaccia grafica e avendola noi pensata nei minimi dettagli - ad arrivare fino alle singole animazioni - non volevamo, nella presentazione, perdere nessuno di questi dettagli. Per questo motivo... -click-

Slide 24 (Prototipo di interazione - Strumenti di presentazione)

...siamo andati alla ricerca di uno strumento adeguato. In questa slide sono rappresentati i loghi degli strumenti che abbiamo velocemente valutato. Alcuni si adattano di più al compito, altri meno. Alla fine, un po’ per non perdere nessun dettaglio e un po’ per riuscire a realizzare velocemente il prototipo abbiamo scelto... -click-

Slide 25 (Prototipo di interazione - Strumenti di presentazione)

...Flash Catalyst. -click-

Slide 26 (Prototipo di interazione - Flash Catalyst)

Questo strumento ci ha permesso di costruire, senza uscire mai dal suo editor visuale, un prototipo di qualità in cui è possibile inserire transizioni e animazioni riproducendo fedelmente l’interfaccia definitiva che avevamo immaginato. Visti i tempi brevi in cui è possibile ottenere dei buoni risultati permette di testare la validità delle soluzioni sottoponendole agli utenti e variandole anche sul momento.Flash Catalyst presenta comunque alcune limitazioni con cui ci siamo dovuti scontrare, ma tutto sommato ci ha permesso di ottenere un risultato soddisfacente. -click-Abbiamo impegnato nella realizzazione del prototipo, compresa la breve fase di apprendimento del software, circa 60 ore. Apriamo ora un attimo il prototipo, giusto per darvi un’idea del risultato finale. -aprire prototipo raceon-

Prototipo Raceon[fare login ed entrare in sessione]Come potete vedere abbiamo strutturato il prototipo mettendo sulla sinistra lo schermo del dispositivo, in questo caso il Raceon - quello tipo tablet, e sulla destra una serie di bottoni che non fanno parte dell’interfaccia, ma che servono per visualizzare le reazioni dell’interfaccia stessa a certi eventi esterni. Ad esempio se i commissari stanno intervenendo in pista [click sul tasto appropriato] viene fuori il simbolo di pericolo, e durante questo periodo è possibile che venga richiesto il supporto ad esempio dell’ambulanza [premere il tasto ambulanza].[chiudere intervento in pista, giochicchiare con il resto]Come potete vedere la qualità in generale del risultato è molto buona - anche se sul proiettore forse non si vedrà granché - e vi possiamo assicurare che è piuttosto semplice raggiungere questo livello senza bisogno di particolari guide o lunghi periodi di apprendimento.Comunque è chiaro che il prototipo non implementa tutte le funzioni del dispositivo reale, quindi per facilitare la navigazione al suo interno abbiamo stilato una breve traccia di esecuzione che è possibile seguire per vedere tutte le parti che sono state realizzate. -tornare alla presentazione-

Slide 26 bis (Prototipo di interazione - Flash Catalyst)

-click-

Slide 27 (Pianificazione della Prototipazione)

Bene, abbiamo quasi finito. L’ultima richiesta della consegna del progetto era quella di stilare un piano di massima per la prototipazione del prodotto, bisognava cioè descrivere le fasi che portano dal progetto alla messa in opera o alla diffusione del prodotto nella sua versione

definitiva.Per ogni fase si è trattato sostanzialmente di: indicare il livello dei prototipi da realizzare, cioè quali funzionalità includere e quali delegare alle fasi successive; indicare il numero e la configurazione dei dispositivi da considerare e, infine, stimare i possibili costi della fase stessa. La cosa che abbiamo trovato più difficile di questa parte del progetto è stato scegliere il numero di fasi e, nel farlo, ci è stato molto utile attribuire un obiettivo chiaro e preciso ad ogni fase. -click-

Slide 28 (Pianificazione della Prototipazione - Il nostro caso)

Abbiamo previsto tre fasi principali più una iniziale - fase 0 - di verifica dell’usabilità dell’interfaccia. Abbiamo attribuito un preciso obiettivo ad ogni fase cercando di ridurre i costi il più possibile nelle prime fasi per minimizzare l’investimento in caso di insuccesso.La fine della fase 1 - indicata come “punto di non ritorno” sulla slide - è il termine entro il quale è previsto che si capisca la validità del progetto. Le spese affrontate fino a quel momento sono inferiori al 5% del totale dei 292.000 euro e passa preventivati. -click-La divisione in fasi e la stima dei costi ci ha impegnato per un paio di giorni, circa 12 ore. -click-

Slide 29 (Riepilogo)

Siamo arrivati ormai alla fine della presentazione. Giusto per darvi un’idea del lavoro che è necessario abbiamo riportato su questa slide un riepilogo delle varie fasi con i relativi tempi.Dopo l’esperienza fatta con questo progetto possiamo dire che le fasi più importanti per la buona riuscita dello stesso... -click-

Slide 30 (Riepilogo - Enfasi)

...sono senza dubbio le fase iniziali: quella di analisi del dominio e di stesura dei requisiti. Da una parte una conoscenza approfondita del dominio permette di rispondere a molte delle domande che sorgono durante la progettazione, dall’altra la lista e la descrizione dei requisiti agiscono come una continua guida rispetto alla direzione che si sta prendendo. -click-

Slide 31 (Fine)

Noi avremmo finito, se avete domande siamo qui.. nella slide successiva trovate un po’ di documentazione. Tutto il materiale del progetto vi sarà messo a disposizione quanto prima. -click-

Slide 32 (Riferimenti)