Ascari Project (discorso)

479 views

Published on

Discorso di corredo alla presentazione "Ascari Project".

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
479
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Ascari Project (discorso)

  1. 1. Presentazione AscariSlide 1 (Copertina)Buongiorno, siamo qui su invito della Prof.sa Agostini per presentarvi il progetto che abbiamofatto per il corso di Interaction Design dello scorso anno.-click-
  2. 2. 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 incentivatol’uso di dispositivi mobili - eventualmente con degli schermi - ma su di essi non era possibilerappresentare informazioni testuali; era inoltre caldamente consigliato progettare dispositivicompletamente nuovi.-click-
  3. 3. 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 processoche ha portato alla sua realizzazione. Per questo nel seguito della presentazione vedremocome, partendo dall’analisi del contesto ed utilizzando le tre cose scritte in mezzo - requisitipersone 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, deldominio.-click-
  4. 4. Slide 4 (Scelta Dominio)Nel caso di questo progetto il dominio doveva comprendere una comunità operante in un’areageografica ben definita (ad esempio un edificio, un insieme di edifici, una città, eccetera), concui era necessario prendere diretto contatto. Inoltre, ai fini del progetto, era importante cheall’interno dell’attività della comunità stessa ci fossero aspetti migliorabili, in cui fosse insommapossibile inserirsi con strumenti tecnologici di supporto.-click-
  5. 5. 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 posizionateai lati della pista e segnalano ai piloti varie situazioni sventolando delle bandiere colorate; essiintervengono 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 dirisolvere questi problemi nel modo più completo possibile.Per darvi un’idea del tempo impiegato nello svolgere il progetto abbiamo messo nelle slide delleicone 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 unagiornata di lavoro, 6 ore.-click-Q: Puoi specificare meglio i problemi?A: Il problema principale che abbiamo riscontrato in questa comunità riguarda lacomunicazione. Per il forte rumore e per la mancanza di convenzioni, i commissari di percorsofanno fatica a comunicare da una postazione all’altra, spesso ci sono incomprensioni oppureviene impiegato molto tempo prima che la comunicazione arrivi al destinatario.
  6. 6. L’altro problema, quello relativo alla mancanza di informazioni, è particolarmente rilevantequando è necessario fare certe segnalazioni. Spesso infatti sarebbe utile ai commissariconoscere la posizione delle vetture in classifica e sul tracciato, informazione che ad ora nonhanno direttamente a disposizione.
  7. 7. Slide 6 (Analisi Dominio)Una volta scelto il tema bisognava capire se gli aspetti migliorabili, per come percepiti danoi che non facciamo parte della comunità, valessero anche all’interno de essa. Era cioènecessario approfondire la conoscenza del dominio, chiedendo effettivamente conto di questedifficoltà alle persone che vi sono immerse.Gli strumenti principali di questa fase di raccolta informazioni sono ovviamente l’osservazionediretta e le interviste. In questo modo è possibile avere conferma delle problematiche presentinel dominio. Per capire se queste problematiche valgono per tutta la comunità oppuresoltanto per la parte che si è intervistata, si possono somministrare dei questionari in modo daraggiungere un maggior numero di persone.In ogni caso, l’obiettivo di questa fase è quello di capire con precisione che cosa funziona benenel dominio, e che cosa invece è migliorabile; entrambi gli aspetti vanno capiti nel modo piùchiaro possibile perché saranno fondamentali nei passi successivi.-click-
  8. 8. Slide 7 (Analisi Dominio - il nostro caso)Noi, che avevamo già un’idea delle problematiche, abbiamo utilizzato le interviste per sapernedi più sul contesto e abbiamo poi utilizzato un questionario - somministrandolo ad un buonnumero 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 orecirca.-click-
  9. 9. Slide 8 (Requisiti - Cosa)Una volta analizzato il dominio ci siamo concentrati sui requisiti del nuovo prodotto chesaremmo andati a progettare.I requisiti sono un elenco di frasi molto semplici che descrivono ciò che il prodotto deve faree 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 fasisuccessive. Poichè abbiamo fatto spesso riferimento ai requisiti nelle fasi seguenti abbiamotrovato comodo identificarli ognuno con un codice.Abbiamo capito che la cosa importante in questa fase è descrivere le cose ad alto livellocercando di concentrarsi più sulla vista d’insieme che sui dettagli, nei quali si rischia di perdersi.-click-
  10. 10. Slide 9 (Requisiti - Tipi)Durante la stesura dei requisiti li abbiamo suddivisi, come spesso si fa, tra funzionali e nonfunzionali. I requisiti funzionali sono quelli che dicono qualcosa sui servizi che il prodotto deveerogare, cioè sono quelli che effettivamente dicono “cosa”. Invece i requisiti non funzionali sonodelle aggiunte, che specificano ulteriori informazioni o aggiungono vincoli rispetto a quantoscritto nei requisiti funzionali.-click-
  11. 11. 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 precedentee quella successiva stanno esponendo”. Indipendentemente dal testo in particolare, è possibileritrovare tutte le caratteristiche che abbiamo elencato prima: la frase è semplice e concisa edice qualcosa su che cosa il sistema deve fare.Il secondo è un requisito non funzionale “Resistenza alle intemperie”. Questo non haripercussioni sulle funzionalità del sistema ma ha a che fare con le condizioni in cui il prodottoandrà ad operare, pone dei vincoli su come il prodotto dovrà essere realizzato.-click-
  12. 12. Slide 11 (Requisiti - Specificazione)Dopo aver stilato una lista essenziale dei requisiti li abbiamo considerati ognuno singolarmentee ne abbiamo data una descrizione dettagliata.Per capire se il requisito era effettivamente valido ci siamo sforzati di giustificarlo tramite unamotivazione e lo abbiamo corredato con luna descrizione delle problematiche che risolve. Èun compito impegnativo che però consente di passare alla fase successiva sapendo che tuttoquello che è stato scritto non dovrà più essere messo in discussione.-click-
  13. 13. Slide 12 (Requisiti - Specificazione - Importante)Durante questa fase è fondamentale formulare i requisiti stando attenti a non sovrapporsi conciò che, nel dominio, funziona già bene.-click-
  14. 14. Slide 13 (Requisiti - Specificazione - Il nostro caso)Per giustificare ogni requisito abbiamo cercato un esempio pertinente in cui fosse necessariauna certa informazione o una certa funzionalità stando sempre attenti a non togliereresponsabilità e a non svalorizzare il compito degli utenti - cosa che, nel nostro ambito inparticolare, 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 daesporre.
  15. 15. 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 indue 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 cercatodi immaginare tutti gli aspetti della vita della persona ritratta, concentrandoci in particolar modosui gusti, sulle abitudini e sul lato psicologico.In generale, la descrizione delle persone non deve essere estratta da una persona conosciutama 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 comeinterpreterebbe questo simbolo?” e simili.-click-
  16. 16. Slide 15 (Costruzione delle Persone - Il nostro caso)Anche se inizialmente ci è sembrato un compito lungo e difficile, nello farlo ci siamo fatticoinvolgere 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, dicui trovate riferimenti in fondo alla presentazione.-click-La costruzione delle persone è stata piuttosto veloce, per farla ci abbiamo messo 18 ore circa.-click-
  17. 17. Slide 16 (Ideazione del prodotto)Arrivati a questo punto avevamo già in mente cosa andare a sviluppare. Abbiamo visto cheperò le idee erano piuttosto confuse, e abbiamo quindi deciso che era meglio non perdersinei dettagli, abbiamo raccolto le idee e siamo ripartiti dai requisiti per organizzarle. Il nostroconsiglio in questa fase è di non essere troppo frettolosi ma prendersi il tempo necessario perdefinire con una certa precisione, anche se ad alto livello, il prodotto immaginato.-click-
  18. 18. Slide 17 (Ideazione del prodotto - Il nostro caso)Nel nostro caso siamo arrivati all’ideazione di due dispositivi. Una specie di palmare touchscreen che abbiamo chiamato Racelet e un dispositivo simile ad un tablet pc che abbiamochiamato Raceon. Abbiamo diviso le varie funzionalità ai due dispositivi, ne abbiamo fatta unadescrizione in termini generali e abbiamo cercato di immaginarci come fossero fisicamente. Perrendercene maggiormente conto abbiamo anche fatto dei semplici modelli 3D tramite GoogleSketch Up.-click-L’ideazione del prodotto è maturata lentamente durante le fasi precedenti, a livello quasiinconscio, tanto che avevamo già praticamente in testa tutti la stessa cosa. La discussionecollettiva per definire i particolari è durata non più di mezza giornata.-click-
  19. 19. Slide 18 (Prototipo di interazione - Scenario esistente)Dopo aver tratteggiato il prodotto bisogna entrare nel dettaglio, andando ad analizzare tuttele interazioni possibili fra il prodotto e gli utenti. Nel nostro caso si trattava sostanzialmente diprogettare un’interfaccia grafica per questi dispositivi.Abbiamo visto che partire direttamente con la progettazione dell’interfaccia risultacontroproducente: è necessaria una guida che consenta di mantenere una certa direzioneoppure ci si perderà facilmente. Perciò ci siamo serviti degli scenari; abbiamo iniziatoidentificando delle situazioni rilevanti e le abbiamo descritte accuratamente, mettendo inevidenza le problematiche. Si parla, in questa fase, di scenari che descrivono il dominio primadell’introduzione del prodotto.-click-
  20. 20. 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 giustolivello di dettaglio. Per il nostro progetto è stato sufficiente identificare tre casi, che insiemecoprivano tutte le situazioni critiche.-click-
  21. 21. Slide 20 (Prototipo di interazione)Dopo aver descritto gli scenari nella situazione attuale li abbiamo ripresi in mano e ripercorsipunto per punto inserendovi le interazioni con il nuovo prodotto, a sostituire o integrare quelloche 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 ilbottone X”, “il dispositivo reagisce con una breve vibrazione”, eccetera.Seguendo questa procedura ci sono venute subito in mente moltissime idee. L’inizio è statoconcitato, 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-
  22. 22. Slide 21 (Prototipo di interazione - Strumenti)... siamo ricorsi a dei mockup cartacei. Abbiamo stampato un certo numero di mascheredella dimensione degli schermi dei nostri due dispositivi e le abbiamo usate come base perdisegnarvi l’interfaccia. Abbiamo scoperto che è un modo estremamente veloce ed efficace didare forma alle proprie idee, che consente da subito di testare l’interfaccia, notarne i difetti ecorreggerli.Le domande tipiche che possono aiutare a capire le cose in questa fase sono: “Come faccio afare questo?”, “Se faccio questa azione in questo momento cosa succede?”, eccetera.-click-
  23. 23. Slide 22 (Prototipo di interazione - Revisione)Dopo aver ripercorso tutti gli scenari ed aver specificato le interazioni passo passo abbiamoripreso in mano i requisiti per assicurarci di aver soddisfatto sia quelli funzionali che quelli nonfunzionali. 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-
  24. 24. Slide 23 (Prototipo di interazione - Risultati)Al termine della fase di progettazione avevamo quindi completato i nuovi scenari - cheincludono l’utilizzo del prodotto - ed un mockup completo e dettagliato del funzionamento delsistema.Gli scenari completi, a questo punto, rendono evidente l’impatto del nuovo prodotto sul dominiomettendo in luce anche la bontà dell’idea avuta.-click-Per sviluppare gli scenari, fra formulazione di quelli esistenti e aggiunta/integrazione con leinterazioni ci sono volute circa 30 ore, mentre per lo sviluppo del mockup, con tutto quello checompete...-click-...circa 42 ore.A questo punto è sorto il problema di come presentare il nostro lavoro. I mockup cartacei sonoinfatti piedi di appunti e correzioni, non sono in sequenza e non sono navigabili da chi nonabbia partecipato alla progettazione - a volte, neanche da chi vi ha partecipato. Inoltre, essendoun’interfaccia grafica e avendola noi pensata nei minimi dettagli - ad arrivare fino alle singoleanimazioni - non volevamo, nella presentazione, perdere nessuno di questi dettagli. Per questomotivo...-click-
  25. 25. Slide 24 (Prototipo di interazione - Strumenti di presentazione)...siamo andati alla ricerca di uno strumento adeguato. In questa slide sono rappresentati iloghi 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 realizzarevelocemente il prototipo abbiamo scelto...-click-
  26. 26. Slide 25 (Prototipo di interazione - Strumenti di presentazione)...Flash Catalyst.-click-
  27. 27. Slide 26 (Prototipo di interazione - Flash Catalyst)Questo strumento ci ha permesso di costruire, senza uscire mai dal suo editor visuale, unprototipo di qualità in cui è possibile inserire transizioni e animazioni riproducendo fedelmentel’interfaccia definitiva che avevamo immaginato. Visti i tempi brevi in cui è possibile otteneredei buoni risultati permette di testare la validità delle soluzioni sottoponendole agli utenti evariandole anche sul momento.Flash Catalyst presenta comunque alcune limitazioni con cui ci siamo dovuti scontrare, ma tuttosommato ci ha permesso di ottenere un risultato soddisfacente.-click-Abbiamo impegnato nella realizzazione del prototipo, compresa la breve fase di apprendimentodel software, circa 60 ore.Apriamo ora un attimo il prototipo, giusto per darvi un’idea del risultato finale.-aprire prototipo raceon-
  28. 28. Prototipo Raceon[fare login ed entrare in sessione]Come potete vedere abbiamo strutturato il prototipo mettendo sulla sinistra lo schermo deldispositivo, in questo caso il Raceon - quello tipo tablet, e sulla destra una serie di bottoni chenon fanno parte dell’interfaccia, ma che servono per visualizzare le reazioni dell’interfacciastessa a certi eventi esterni. Ad esempio se i commissari stanno intervenendo in pista [click sultasto appropriato] viene fuori il simbolo di pericolo, e durante questo periodo è possibile chevenga 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 proiettoreforse non si vedrà granché - e vi possiamo assicurare che è piuttosto semplice raggiungerequesto livello senza bisogno di particolari guide o lunghi periodi di apprendimento.Comunque è chiaro che il prototipo non implementa tutte le funzioni del dispositivo reale, quindiper 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-
  29. 29. 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 stilareun piano di massima per la prototipazione del prodotto, bisognava cioè descrivere le fasiche portano dal progetto alla messa in opera o alla diffusione del prodotto nella sua versione
  30. 30. 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 laconfigurazione 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 numerodi fasi e, nel farlo, ci è stato molto utile attribuire un obiettivo chiaro e preciso ad ogni fase.-click-
  31. 31. 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 ilpiù 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 sonoinferiori 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-
  32. 32. 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 labuona riuscita dello stesso...-click-
  33. 33. 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 moltedelle domande che sorgono durante la progettazione, dall’altra la lista e la descrizione deirequisiti agiscono come una continua guida rispetto alla direzione che si sta prendendo.-click-
  34. 34. Slide 31 (Fine)Noi avremmo finito, se avete domande siamo qui.. nella slide successiva trovate un po’ didocumentazione. Tutto il materiale del progetto vi sarà messo a disposizione quanto prima.-click-
  35. 35. Slide 32 (Riferimenti)

×