L'esperienza

Cos'è l'esperienza?

L'Oxford dictionary definisce il termine esperienza come

• contatto pratico con una osservazione di fatti o eventi
• La conoscenza o abilità acquisita dall'esperienza in un periodo di tempo, in particolare quella acquisita in una particolare professione da qualcuno sul lavoro
• Un evento o ricorrenza che lascia un'impressione su qualcuno

I tre significati si riferiscono a tre aspetti legati ma distinti:

• l'esperienza fenomenologica cosciente io-qui-adesso
• la memoria episodica di esperienze memorabili [@Pine1998]
• il processo di astrazione di episodi in pattern, schemi, script [@Sweegers2014]

Il primo significato rappresenta quello che io sto vivendo adesso, qui. Se non sto prestando attenzione a quello che mi sta succedendo, e non sta succedendo nulla di nuovo (ad esempio, se sto leggendo un libro mentre viaggio in treno per andare al lavoro) questo evento rinforza il mio schema di viaggio in treno, e mi dimenticherò l'evento specifico [@sweegers2015mental]. Se, al contrario, succede qualcosa di inaspettato o interessante, probabilmente ricorderò gli aspetti più salienti dell'episodio.

Definizione di esperienza

Una esperienza prototipica è la rappresentazioen soggettiva, conscia ed intenzionale di un evento episodico autobiografico:

• Ha una forte base fenomenologica, ed è vissuta come un flusso di coscienza non mediata ed immersiva;
• È di solito innescata da una motivazione
• Si può immaginare, ed anticipare mentalmente
• Può essere il risultato di un processo decisionale, una scelta
• Può essere pianificata, a diversi livelli di dettaglio
• Può essere ricordata
• È generalmente oggetto di valutazioni: prima, durante e dopo
• Può innescare un processo di apprendimento
• Può diventare un'abitudine

Le componenti dell'esperienza

L'esperienza è una finestra temporale di ciò che di saliente è successo o sta succedendo, ciò che è previsto succeda, e ciò che è stato pianificato (le azioni finalizzate agli scopi).

Delle esperienze ricordate (passate), presenti o immaginate (future) abbiamo delle rappresentazioni mentali. Queste rappresentazioni integrano una dimensione causale e motivazionale (perché), una dimensione temporale (quando) e una dimensione spaziale (dove), e sono formate da oggetti appartenenti a classi di concetti (cosa) ed eventualmente da altri attori (chi).

I concetti, sia quelli concreti (cosa) che quelli più astratti, sono organizzati sia in reti semantiche che in gerarchie (tassonomie).

Le dimensioni temporale, causale e spaziale sono organizzate gerarchicamente. Più in particolare, la dimensione causale degli scopi è organizzata in gerarchie di scopi e di compiti.

La memoria episodica, la memoria semantica e le funzioni esecutive sono alla base delle esperienze.

La user experience

User experience: definizione

ISO 9241-210 defines user experience as "a person's perceptions and responses that result from the use or anticipated use of a product, system or service". According to the ISO definition, user experience includes all the users' emotions, beliefs, preferences, perceptions, physical and psychological responses, behaviors and accomplishments that occur before, during and after use. The ISO also list three factors that influence user experience: system, user and the context of use. http://en.wikipedia.org/wiki/User_experience

La percezione e le risposte di una persona che risultano dall'uso o dall'anticipazione d'uso di un prodotto, sistema, servizio. La definizione ISO include gli aspetti emotivi, le credenze, le preferenze, gli aspetti percettivi, fisici, psicologici, i comportamenti e i risultati che hanno luogo prima, durante e dopo l'interazione [@wiki:User_experience].

In base ad un sondaggio pubblicato da @law2009understanding, secondo gli ux designer la ux si riferisce agli stati interni degli utenti, il sistema, il contesto.

Secondo @uxwhitepaper, il concetto di UX è un sottoinsieme del concetto di esperienza, è unica e soggettiva, è influenzata da esperienze precedenti ed aspettative, è contestualizzata, ed è focalizzata meno sulla tecnologia, più sulla componente psicologica, umana.

Prima, durante, dopo

@uxwhitepaper enfatizzano il fatto che l'esperienza utente non si limita al momento dell'interazione:

• prima dell'esperienza l'utente è condizionato dalle aspettative, dalle esperienze passate, dalla testimonianza di altri utenti
• dopo l'interazione l'utente tende a valutare l'esperienza e probabilmente a ricordarne alcuni aspetti.

Il fattore temporale (prima, durante, dopo) è enfatizzato anche dalla definizione di user experience secondo lo standard ISO 9241-210. La dimensione temporale -- i momenti prima, durante e dopo -- è centrale nella definizione di differenti tipologie di esperienze: la user experience, l'esperienza turistica, il service design.

Dimensione temporale

Nel service design, ad esempio, la dimensione temporale è descritta in vari modi:

• anticipazione, ingaggio, uscita, riflessione;
• scoperta, investigazione, preparazione, applicazione, uso;
• consapevolezza, scelta, acquisto, fruizione, condivisione.

Nell'ambito dell'esperienza turistica, le tre parti spesso sono definite:

• anticipazione e pianificazione;
• l'esperienza turistica.
• il ricordo e la condivisione.

L'approccio progettuale

L'UX design è sostanzialmente un approccio progettuale che vuole enfatizzare quegli aspetti dell'interazione che - negli approcci classici dell'HCI e dell'usabilità - avevano un'importanza minore: gli aspetti appunto esperienziali.

Quest'idea di ampliare l'orizzonte della HCI e dell'usabilità sembra alla base dell'introduzione del termine, da parte di Donald Norman, a metà degli anni '90:

“I invented the term because I thought human interface and usability were too narrow. I wanted to cover all aspects of the person’s experience with the system including industrial design graphics, the interface, the physical interaction and the manual. Since then the term has spread widely, so much so that it is starting to lose it’s meaning.”

Professionalità della UX

L'UX design è dunque un approccio mutidisciplinare, che raccoglie differenti professionalità:

• architettura dell’informazione
• usabilità
• accessibilità
• interaction design
• information design
• graphical design

<!--

Cosa non è UX (1)

La user experience non si occupa solo del design di interfacce.

L’interfaccia è una componente importante della user experience, ma non l’unica, c’è molto altro.

E, in ogni caso, lo user interface design non è una questione cosmetica o grafica, sebbene l’aspetto grafico sia importante.

UX non è (solo) tecnologia

È qualcosa che concerne la nostra vita, è intorno a noi, non solo nei nostri prodotti tecnologici.

Gli user experience designer spesso usano la tecnologia per aiutare le persone a fare quello che desiderano fare.

Ma l’obiettivo primario è essere di aiuto agli utenti, non quello di creare o usare la tecnologia più cool.

La UX design non è circoscritta al computer, o ad uno schermo. la User Experience è in qualsiasi interazione con qualsiasi prodotto, artefatto o sistema.

Norman parla dell’usabilità delle porte antincendio, di caffettiere e spremiagrumi. Ogni artefatto ha un’interfaccia e, quando usato, ingenera una user experience.

Cosa non è UX (2)

UX non è solo usabilità

Creare prodotti facili da usare ed intuitivi non è affatto l’unico obiettivo dell’UX design.

È necessario anche preoccuparsi che gli utenti abbiano voglia di usare i nostri prodotti.

Il limite dell’usabilità, soprattutto se intesa in senso ingegneristico, è che tende a focalizzarsi sull’efficienza ed efficacia, tendendo a sottovalutare gli aspetti emotivi ed edonici legati all’uso di un prodotto.

Peter Morville ci ricorda che le dimensioni da tenere in considerazione sono molte: utile, desiderabile, accessibile, credibile, trovabile, di valore.

UX non si preoccupa solo degli utenti

L’utente è necessariamente al centro della UX. Questo, però, non significa che si possano ignorare altre istanze: gli obiettivi degli stakeholder, ovvero dei committenti.

Il compito dell’UX designer è di trovare la sintesi dialettica fra le esigenze dell’utente e quelle del committente.

-->

Il design

Cos'è il design

Il design è un processo di produzione di rappresentazioni e modelli che guidano la realizzazione di prodotti e servizi finalizzati a realizzare degli scopi o soddisfare dei bisogni di una definita tipologia di utenti.

Secondo @munari1981cosa, la prima fase consiste nell'identificare il problema e, per quanto possibile, scomporlo in sottoproblemi.

Il problema di design nasce da un bisogno Archer, citato in @munari1981cosa

Le domande del design

Preliminare alla creazione dei modelli, il processo prevede una fase di ricerca ed una fase di rappresentazione/sintesi. Queste fasi sono finalizzate a rispondere ad una serie di domande:

• Chi sono gli utenti del prodotto?
• Perché queste persone utilizzeranno il prodotto: quali sono gli scopi e i bisogni?
• Con cosa: con quali strumenti (materiali, non materiali, concettuali?
• Come dev'essere realizzato il prodotto o il servizio

La fase di ricerca utilizza una serie di metodi di elicitazione per indagare questi aspetti.
La fase di rappresentazione utilizza una serie di strumenti per sintetizzare i risultati della ricerca.

Principi di design

Dieter Rams

Secondo Dieter Rams il buon design:

• è innovativo
• rende utile il prodotto
• è esteticamente bello
• rende il prodotto comprensibile
• non è intrusivo (non ostacola l'uso del prodotto)
• è onesto: non fa apparire il prodotto più innovativo, potente o di valore di quello che è; non cerca di manipolare i consumatori con promesse che non può mantenere
• è duraturo
• è attento ai dettagli
• è attento all'ambiente
• è minimalista (as little design as possible)

iOS Design Principles (I)

Integrità estetica

L'integrità estetica si riferisce non alla bellezza o allo stile di una app, ma rappresenta la capacità di integrare l'apparenza estetica e il comportamento con la sua funzione, utilizzando un linguaggio coerente

Consistenza

Attraverso la consistenza gli utenti possono trasferire la conoscenza e gli skill acquisiti in un'area dell'interfaccia ad un'altra parte della stessa app, o ad applicazioni diverse. Un'app consistente non è banale, ma presta attenzione agli standard e ai paradigmi

Manipolazione diretta

Quando gli utenti possono manipolare gli oggetti direttamente sullo schermo, sono più concentrati sul compito, ed è per loro più facile capire i risultati delle loro azioni. (Feedback immediato)

iOS Design Principles (II)

Feedback

Alle azioni degli utenti l'applicazione deve dare un feedback immediato, mostrare i risultati e aggiornare lo stato dell'applicazione.

Metafore

Se gli oggetti virtuali e le azioni all'interno dell'app utilizzano metafore familiari (legate sia al mondo digitale che al mondo fisico) la comprensione dell'utente risulta facilitata. È però necessario evitare che la metafora suggerisca limitazioni o interpretazioni non appropriate

Controllo all'utente

Il controllo delle azioni dev'essere in mano agli utenti, non alle applicazioni. L'app può suggerire, notificare, o avvisare l'utente in caso di necessità, ma le decisioni spettano all'utente. Le app migliori trovano il corretto rapporto nell'offrire all'utente la possibilità di scelta e limitare la probabilità e l'impatto di risultati indesiderati.

Facebook design principles (I)

Design universale

La mission di Facebook è di permettere ad ognuno, ovunque, di utilizzare i loro servizi. Dunque, il design di Facebook deve funzionare per ognuno, in ogni cultura, ogni lingua, ogni device, per ogni età.
Per questa ragione Facebook preferisce concentrarsi su quelle funzioni che possono funzionare per il 90% degli utenti, ed eliminare quelle funzionalità che funzionano solo per una minoranza, a costo di rinunciare a qualcosa nel breve termine.

Umano

I nostri utenti usano Facebook per interagire con amici e conoscenti. È per questo che la nostra voce e il nostro stile grafico (visual style) rimane sullo sfondo, dietro alla voce, ai volti, alle espressioni delle persone.

Pulito

Il nostro visual style è pulito e dimesso, per crare una lavagna vuota dove gli utenti possono esprimersi. Uno spazio minimalista incoraggia la partecipazione e la comunicazione. Arrivare ad uno stile visuale pulito non è facile. L'attenzione ai dettagli diventa fondamentale se si riduce la gamma di stili visuali.

Facebook design principles (II)

Consistente

L'interazione di Facebook parla agli utenti con una voce univoca, che costruisce fiducia. Ridurre, riusare, non reinventare l'interazione, adottare pattern in cui interazioni simili sono disegnate in maniera simile.

Utile

Il prodotto Facebook non è intrattenimento, è una utility finalizzata all'uso quotidiano, ripetitivo, in cui l'efficienza è centrale. Per questa ragione le interazioni più importanti sono aerodinamiche (streamlined), ripulite da interazioni e cose inutili.

Veloce

Il tempo degli utenti è importante. Le esperienze veloci sono più efficienti e vengono percepite come meno faticose. Pertanto, la velocità del sito dev'essere qualcosa di cui l'utente non si accorge nemmeno.

Trasparente

Gli utenti si fidano di noi, affidandoci la loro identità, le loro foto, i loro pensieri e conversazioni. Facebook deve meritare questa fiducia con onestà e trasparenza.

I 10 principi di uk.gov (I)

Focalizzati sui bisogni

Gli utenti - clienti usano i nostri servizi digitali per portare a termine dei compiti, e soddisfare dei bisogni.

Identificare scopi e bisogni è la base del design.

Fai meno

Fai tutto quello che è necessario, ma evita la tentazione di voler fare tutto, e focalizzati su ciò che è veramente importante.

Progetta a partire dai dati

Prima di progettare, concentrati sulla ricerca. Analytics, benchmark, ricerca con gli utenti (qualitativa, quantitativa) sono i presupposti necessari per il successo di un prodotto digitale.

Impegnati per rendere le cose semplici

I tuoi servizi digitali devono essere utili e usabili. Per fare questo, adotta una progettazione orientata all'utente, identifica e rappresenta i loro modelli mentali, rispetta euristiche, pattern e linee guida, e testa spesso e iterativamente il tuo design.

I 10 principi di uk.gov (II)

Itera, poi itera ancora

L'approccio iterativo gestisce i rischi: rende meno probabili i grandi fallimenti, e trasforma i piccoli fallimenti in lezioni (e aggiustamenti di rotta).

Affinché l'iterazione abbia senso, testa ogni ciclo con gli utenti: con dei test di usabilità, rilasciando versioni alpha e misurando comportamenti e feedback, utilizzando strumenti come gli A/B test.

Progetta per l'inclusione

Impegnati affinché i tuoi servizi digitali possano essere utilizzati dal più ampio numero di persone: sia le persone con disabilità di vario genere, sia per coloro che non hanno molta dimestichezza con le tecnologie, ad esempio le persone anziane.

Tieni conto del contesto

Tieni conto del contesto d'uso, da parte dell'utente, che può fruire dei tuoi servizi attraverso strumenti diversi (pc, tablet, smartphone), in luoghi diversi (in ufficio, in casa, sull'autobus, per strada) e in momenti diversi (in fila alle poste, durante la pausa pranzo).

Tieni conto del contesto più ampio in cui i tuoi servizi si collocano (il mercato, i concorrenti, i clienti potenziali).

I 10 principi di uk.gov (III)

Costruisci servizi digitali, non siti web

Il sito web è soltanto uno dei possibili touchpoint fra la tua organizzazione e i tuoi utenti / clienti.

Progetta servizi digitali che possano essere fruiti attraverso differenti canali: web, mobile, call center, sportello, carta stampata.

Inizia progettando un sistema informativo unico, e poi crea differenti rappresentazioni per i diversi canali.

Sii consistente ma non uniforme

Adotta gli standard formali (html, css, accessibilità) e quelli di fatto nella progettazione di siti e applicazioni mobile (consistenza esterna).

Crea dei pattern e delle linee guida, ed usali in maniera consistente (consistenza interna)

Crea versioni consistenti ma adeguate delle linee guida per i diversi canali (consistenza multicanale)

Usa standard aperti e strumenti open

Usa standard aperti: html5, css

Se puoi, usa strumenti open

Se puoi, condividi quello che fai, ad esempio adottando una politica open data.

User Centered Design

Definizioni

User-centred design emphasizes that the purpose of the system is to serve the user, not to use a specific technology, not to be an elegant piece of programming. The needs of the users should dominate the design of the interface, and the needs of the interface should dominate the design of the rest of the system. (Norman 1986)

UCD is an iterative process whose goal is the development of usable systems, achieved through involvement of potential users of a system in system design. (Karat 1996)

Vediamo ora una lista di princîpi dell'UCD, tratti da @gulliksen2003key

Princîpi dell’UCD (I)

• Attitudine allo UCD - L’approccio UCD richiede una attitudine a focalizzarsi sull’utente che dev’essere condivisa da tutto il team di progetto, il gruppo di sviluppo e il cliente. Chiunque sia coinvolto nel progetto dev’essere consapevole dell’importanza di una progettazione centrata sull’utente, che coinvolga gli utenti, e con chiari standard di usabilità.
• Attenzione all’utente - gli scopi dell’attività, il contesto d’uso, gli scopi dell’utente, i suoi compiti e i suoi bisogni devono guidare da subito la progettazione e lo sviluppo.
• Coinvolgimento attivo dell’utente.
• Sviluppo evolutivo del sistema - lo sviluppo dovrebbe essere iterativo ed incrementale.
• Semplicità nella produzione di report e deliverables - la progettazione dev’essere comunicata e rappresentata in modo che possa essere compresa da utenti e stakeholders.
• Prototipare iterativamente - i prototipi dovrebbero esserutilizzati per visualizzare e valutare idee e soluzioni di progetto in cooperazione con gli utenti finali.

Princîpi dell’UCD (II)

• Valutazione d’uso nel contesto
• Multidisciplinarietà - il processo di progettazione e sviluppo dev’essere condotto da un team multidisciplinare
• Usabilità - esperti di usabilità devono essere coinvolti precocemente e continuamente nel ciclo di sviluppo.
• Approccio olistico - tutti gli aspetti che influenzano l’esperienza d’uso dovrebbero potenzialmente essere sviluppati in parallelo.
• Approccio flessibile al processo - Il processo alla base dello UCD deve essere specifico, adattabile al progetto e al contesto organizzativo.

Benefici dell’UCD

• Riduzione dei costi di sviluppo
• Aumento dei profitti
• Benefici organizzativi e di produttività all’interno di una organizzazione

Riduzione dei costi di sviluppo

• si sviluppano soltanto le funzionalità rilevanti per l’utente;
• è più facile diagnosticare e correggere precocemente i problemi di usabilità;
• si riduce la probabilità di redesign dovuti a problemi di usabilità o funzionalità non valutati durante la progettazione e sviluppo.
• diminuiscono i costi di documentazione: i prodotti facili da usare e con le sole funzioni utili richiedono meno documentazione;
• si riducono i rischi di fallimento del prodotto - servizio;

Aumento dei profitti

• l’utente riesce a trovare quello che sta cercando;
• l’utente trova facilmente informazioni complementari o di servizio;
• aumento della soddisfazione d’uso e conseguente fidelizzazione e passaparola positivo;
• aumento nella fiducia nel sito web e, per estensione, di chi il sito rappresenta;
• diminuzione dell’utilizzo dell’help desk - utilizzo del sito al posto del call center;
• aumento delle vendite su altri canali (offline).

Vantaggi organizzativi e produttivi

• apprendimento più veloce e meno superficiale del sistema informativo;
• riduzione dei tempi di processamento e conseguente aumento della produttività;
• riduzione degli errori, con benefici in termini di costi e di qualità del servizio;
• aumento della soddisfazione e della motivazione di dipendenti e collaboratori;
• ridotta necessità di assistenza e dei relativi costi economici e temporali.

Ritorno degli investimenti

Alcune statistiche valide per il mercato statunitense, siti for profit – e-commerce.

• Il singolo miglior predittore del numero di chiamate al call center è l’usabilità del vostro sito web.
• Se risolvere un problema di usabilità costa 10 dollari in fase di design, costerà 100 dollari se diagnosticato e corretto dopo che il sistema è stato implementato e messo in produzione.
• Per ogni dollaro speso nel migliorare la trovabilità e l’usabilità di un sito commerciale, si stima un incremento di vendite di 50 – 100 dollari. Lo stesso non vale per gli investimenti spesi nel perfezionare il visual design o lo stile del sito.

Design e performance di mercato

Il Design Council britannico ha analizzato le performance di numerose compagnie quotate al FTSE di Londra, identificando 63 aziende riconosciute per il loro impegno nell’ambito della progettazione centrata sull’utente.

La ricerca ha monitorato la performance di borsa delle 63 aziende, paragonandola all’indice di borsa, dal 1995 al 2004 (recentemente la statistica è stata aggiornata al 2008).

L’incremento medio del valore azionario delle 63 aziende era del 200% rispetto alla media della borsa londinese.

Ostacoli all’user centred design

• È spesso difficile indurre gli stakeholders ad assumere un approccio centrato sull’utente.
• spesso i progetti subiscono dei cambiamenti radicali decisi dall’alto che possono danneggiare l’user centred design;
• Gli sviluppatori tendono a focalizzarsi sugli obiettivi a breve termine, sui casi d’uso, perdendo di vista le esigenze degli utenti nei contesti reali;
• gli esperti di usabilità / user experience tendono a essere ignorati;

Il design partecipativo

Design partecipativo: origini

Il design partecipativo è un insieme di teorie, pratiche e studi che implicano il coinvolgimento degli utenti finali nella progettazione degli artefatti [@muller2003pdt].

Il design partecipativo nasce e si sviluppa fra gli anni ‘60 e gli anni ‘80 del secolo scorso in Scandinavia e negli Stati Uniti, nell’ambito della progettazione urbanistica e dello sviluppo del software

##Design partecipativo: motivazioni

Il coinvolgimento degli utenti finali nel processo decisionale e di pianificazione è finalizzato a sviluppare degli artefatti capaci di meglio rispondere alle esigenze degli utenti finali.

Inoltre, in alcuni contesti, l'approccio garantisce una maggior democraticità e una minor resistenza al cambiamento nei contesti in cui il prodotto verrà utilizzato.

Uno degli aspetti critici del design partecipativo è la capacità di far emergere i bisogni e le conoscenze implicite degli utenti, per quanto concerne sia le loro esigenze ed i loro desideri che le loro ipotesi di progettazione e realizzazione.

Design partecipativo: urbanistica

Negli Stati Uniti vi sono degli esempi di design partecipativo applicato allo sviluppo urbanistico decisamente interessanti.

Fra tutti, il Regional/Urban Design Assistance Team (R/UDAT) è una metodologia sviluppata dall’American Institute of Architects, in cui vengono applicati i principi del design partecipativo alla pianificazione urbanistica.

Per un interessante case history si veda il R/UDAT della città di Austin, Texas @johnson:dap.

Design partecipativo vs approccio non partecipativo

Ma qual’è il razionale che giustifica l’ipotesi dell’utilità, o della necessità, di coinvolgere gli utenti nella progettazione di un artefatto?

L’approccio tradizionale alla progettazione e quello partecipativo si basano su visioni filosofiche differenti.

L’approccio tradizionale ha una visione più platonica dell’artefatto: l’esperto detiene la conoscenza di come l’artefatto deve essere e nel suo lavoro infonde questa idea nel progetto.

L’approccio partecipativo, al contrario, assume una visione più costruttivista: l’artefatto non deve ricopiare un’idea platonica depositata nella mente dell’esperto.

La conoscenza è condivisa e il progetto va costruito nel confronto fra i vari attori in gioco, non ultimi gli utenti finali.

Scopi del design partecipativo

Il coinvolgimento degli utenti finali nella progettazione è dunque finalizzato principalmente a tre scopi:

• migliorare la progettazione, aumentando la base di conoscenza in fase di analisi progettuale
• fare in modo che le aspettative degli utenti finali siano realistiche ma positive, riducendo così la resistenza al cambiamento
• aumentare la democrazia sui luoghi di lavoro e sul territorio, garantendo ai cittadini il diritto di partecipare alle decisioni che avranno un impatto sul loro lavoro e sulla loro vita.

Tipologie di coinvolgimento

Nella pratica il livello di coinvolgimento degli utenti può variare.

In ogni caso è necessario che il coinvolgimento degli utenti abbia una qualche influenza sul processo progettuale.

Coinvolgere i committenti

L’approccio classico al design partecipativo tende ad escludere, o comunque a non coinvolgere attivamente i committenti nel processo partecipativo.

Questo perché il design partecipativo nasce - nei paesi scandinavi - a supporto dell’azione sindacale dei lavoratori; in quel contesto si temeva che l’intervento del management inibisse la partecipazione dei lavoratori.

Nell’ambito della hci e dell’interaction design è al contrario importante coinvolgere, nel processo di design, anche i committenti (stakeholder).

Rimane comunque opportuno identificare metodi e processi partecipativi distinti per committenti e utenti.

Processo comunicativo

Il design è anche un processo comunicativo.

È fondamentale, nell’ambito del design partecipativo, utilizzare le forme di rappresentazione che permettano di stabilire un processo comunicativo con gli utenti e gli altri stakeholders e permettano loro una comprensione del processo e della visione progettuale.

Progettazione nel contesto

Il designer non deve focalizzarsi esclusivamente sull’artefatto, ma anche sui cambiamenti organizzativi che l’introduzione dell’artefatto comporta.

È dunque necessario progettare e sviluppare contemporaneamente

• l’artefatto, nei suoi aspetti tecnici
• gli aspetti organizzativi
• gli aspetti sociali, anche attraverso la formazione degli utenti

Sostenibilità

Lo sviluppo sostenibile è esplicitamente partecipativo. Secondo Agenda 21 informazione, integrazione e partecipazione sono i punti di partenza dello sviluppo sostenibile.

Secondo le Nazioni unite lo sviluppo dev’essere sostenibile in termini ambientali, economici e sociali.

Dimensioni della sostenibilità

Il design partecipativo può aumentare sia la sostenibilità sociale (aumentando l'accettabilità del progetto) che quella economica (aumentando le probabilità di successo del progetto)

<!--

Model - representation - interaction

Model view control

Model view controller è un pattern di software design che separa i contenuti, la presentazione e l’interazione.
Sviluppato allo Xerox Parc PARK di Palo Alto ed implementato nel linguaggio ad oggetti Smalltalk-80.

“MVC was conceived as a general solution to the problem of users controlling a large and complex data set”.\

Secondo l’inventore di questo pattern “the essential purpose of MVC is to bridge the gap between the human user’s mental model and the digital model that exists in the computer”.

MVC e modelli mentali

• l'oggetto: il cane Fido, che esiste nel mondo reale
• il modello: una descrizione di fido in un file elettronico
• la vista: un programma che trasforma i dati del modello in una modalità che l'utente può vedere con i suoi occhi, interpretare, e manipolare
• il controller coordina una o più viste, ed aggiorna lo stato del modello in base all'interazione dell'utente

Da una descrizione di Trygve Reenskaug

Il flusso

1. Il modello codifica le informazioni e le offre attraverso delle interfacce.
2. Una vista elabora le informazioni e le presenta all’utente.
3. L’utente interagisce con l’interfaccia offerta dalla vista.
4. Il controller è in ascolto, in attesa degli eventi generati dall’utente. Quando l’utente genera un evento il controller lo gestisce avviando una azione, che generalmente aggiorna il modello e-o la vista.
5. La vista interroga il modello per disporre dei dati aggiornati in seguito all’input dell’utente.
6. Il controller si rimette in attesa degli input dell’utente.

MVC e software design

Questo pattern è utilizzato estensivamente nei più importanti framework di sviluppo software:

• SmallTalk
• Microsoft Foundation Classes (C++), .Net
• Java (Struts, Swing, SpringMVC, Cocoon)
• ActionScript
• Pyton (Zope, Plone)
• Ruby
• PHP (Drupal, Joomla!)

Programmazione a oggetti e modelli mentali

Gli oggetti (e le classi) si riferiscono ai concetti degli utenti e ai loro modelli mentali.

Il fine della programmazione orientata agli oggetti è quello di catturare i modelli mentali nel codice.

Il pattern model view controller è finalizzato a mappare i modelli mentali dell'utente nel software

Trygve Reenskaug and James O. Coplien (2009)

Model representation interaction

Il modello raccoglie le informazioni rilevanti di ogni oggetto di ogni classe (ontologia), richieste per la rappresentazione del sistema.

La rappresentazione proietta le informazioni rilevanti in un contesto

L'interazione raccoglie le informazioni - e le scelte - che l'utente deve esplicitamente comunicare al sistema.

Il modello

Identificare i percorsi che permettono all'utente di raggiungere l'obiettivo (o completare il compito).

Identificare le risorse di cui l'utente ha bisogno per portare a termine il compito, incluse le informazioni richieste per poter decidere).

Creare una ontologia: una rappresentazione (formale) delle classi dei concetti coinvolti nell'esperienza (oggetti, agenti, contesti, comportamenti ...).

Organizzare l'informazione: macro information architecture, reti semantiche, spazi cognitivi.

La rappresentazione

Crea le viste che permettano all'utente di formarsi una rappresentazione coerente e funzionale del sistema.

Si adatta la contesto (il quando): lo scopo corrente, lo stato corrente, il canale usato, e se possible lo stato dell'ambiente.

L'interazione

L'interazione si occupa di permettere all'utente di interagire con il sistema.

Linee guida:

• chiedi all'utente solo l'input realmente necessario
• quando possibile, raccogli i dati dall'ambiente o da altre sorgenti, ma lascia all'utente il controllo di questi dati
• adatta il design ai differenti sistemi di input: tastiere fisiche o virtuali, mouse, touchscreen, voce, gesture

Vantaggi

Quali sono i vantaggi di un approccio di questo genere?

• differenziare le competenze
• progettazione cross-canale
• interfacce innovative

Competenze

Il pattern permette una migliore differenziazione delle competenze:

• il modello sarebbe di esclusiva competenza dell’architettura dell’informaizione. Anzi, il modello rappresenterebbe il core dell’IA
• il controller sarebbe di competenza dell’interaction design (il core dell’ID)
• la vista sarebbe di competenza prevalente dell’information design - visual design, con la collaborazione dell’IA per la navigazione e dell’ID per gli aspetti legati all’interazione.

Progettazione cross-canale

Una più facile progettazione di sistemi informativi cross-canale, ovvero fruibili da web, da smartphone e da altri dispositivi: il modello rimane, la vista e il controller cambiano.

Design creativo

Lo sviluppo di viste differenti può permettere al designer di sviluppare, a fianco delle interfacce più tradizionali e codificate, soluzioni creative ed innovative. Se gli utenti hanno la possibilità di decidere quale fra le differenti interfacce usare, protranno scegliere quella che più si adatta alle loro caratteristiche, esigenze, prefrenze, tenuto conto anche del contesto.

Scenario 1: Gruppo editoriale

Editore di quotidiani (La Repubblica, Il Corriere, The New York Times). Attualmente questi gruppi distribuiscono le informazioni attraverso molteplici canali:

• il quotidiano cartaceo;
• il sito web;
• il sito per il dispositivo mobile / l’applicazione per iPhone-Android;
• broadcast via radio (Radio Capital, Radio24), TV, web TV;
• futuro prossimo: e-readers.

Stesse notizie, livello di approfondimento diverso.
Soluzione: un CMS capace di generare viste e interazioni diverse per le differenti piattaforme.

Scenario 2: Museo d’arte

Scenario: un museo organizza una mostra temporanea. Deve sviluppare - aggiornare:

• il sito internet del museo, con una sezione dedicata alla mostra;
• le guide interattive al museo, che utilizzano handhelds multimediali;
• gli opuscoli gratuiti distribuiti all’interno del museo;
• gli exibit interattivi;
• il catalogo delle opere.

Modello: le ontologie

Lo sviluppo del modello si focalizzerà su due tipologie di unità informative:

• gli artisti;
• le opere.

È possibile usare dei microformati per rappresentare queste informazioni. Esempio, per gli artisti, il microformato foaf (friend of a friend).
Definizione di faccette di interrogazione: linea del tempo, nazionalità, movimento artistico, stile ....
Collocazione dell’opera nello spazio fisico del museo.

Vista: il web

Nel sito web possiamo immaginare:

• una pagina per ogni artista, che elenca le informazioni bibliografiche e l’elenco delle opere;
• una pagina per ogni opera, con foto, autore, data, collezione, informazioni;
• una linea del tempo interattiva;
• una mappa che geotagga il luogo di creazione delle opere;
• una pianta del museo con la collocazione delle opere.

Vista: la guida interattiva

La guida interattiva può prevedere

• una schermata per ogni artista;
• una schermata per ogni opera, con foto, autore, data, collezione, informazioni; descrizione audio dell’opera in formato mp3, da ascoltare con cuffie;
• interazione: possibilità di riconoscere l’opera via qrcode, rfid, codice numerico, localizzazione wireless.

Vista: l’exibit interattivo

L’installazione interattiva può permettere all’utente di giocare con le opere esposte, ad esempio usando un programma di image editing per ritoccare una copia della fotografia dei quadri.

Oppure creare dei quiz e questionari sulla conoscenza delle opere e degli artisti, utilizzando in maniera flessibile le informazioni presenti a livello del model.

Può permettere agli utenti di visualizzare il processo di restauro di un quadro, visualizzando le differenze fra le condizioni pre e post restauro e i dettagli dell’intervento.

Anche in questo caso queste stesse attività possono essere presentate anche sul sito web.

Vista: il catalogo delle opere

Il catalogo può essere generato via pdf, e può prevedere

• le pagine degli artisti, con descrizione;
• le pagine per ogni opera, con fotografia ad alta risoluzione, scheda, descrizione;
• linea del tempo;
• indice degli autori e delle opere.

-->

Project management

Metodologia progettuale

La progettazione e lo sviluppo di un artefatto cognitivo è un processo complesso che coinvolge un team multidisciplinare.

È dunque necessario applicare una metodologia progettuale per minimizzare i rischi di fallimento del progetto.

Proviamo dunque ad analizzare due approcci, fra loro antitetici: il progetto a cascata e quello agile, analizzando pregi e limiti di ognuno.

Gestire un progetto

Gestire un progetto significa:

• identificare gli obiettivi e i risultati attesi, e se possibile quantificarli;
• identificare i vincoli;
• pianificare il processo in modo da raggiungere gli obiettivi rispettando i vincoli;
• monitorare il processo ed aggiustarlo quando necessario;
• mantenere un ambiente di lavoro calmo, positivo e produttivo.

##Gestione di progetto e aspetti salienti

Nella gestione di un progetto vanno tenuti in considerazione 4 aspetti [@Easterbrook2001]:

• il prodotto;
• le risorse;
• i tempi;
• i fattori di rischio;

Gestione del rischio

Nel processo progettuale possono emergere degli ostacoli e degli imprevisti che ritardano lo sviluppo o che costringono a modificarne delle parti.

Con gestione del rischio si intendono quelle pratiche finalizzate a prevenire l’insorgere degli ostacoli ed a minimizzarne gli effetti negativi.

Il principio sottostante è che la prevenzione del rischio è meno costosa che la gestione dell’evento negativo.

È utile rendere esplicita la stima del rischio nel momento in cui si fanno delle scelte progettuali.

Rischi più frequenti

• budget e tempistica non realistica: uno dei rischi più frequenti, nello sviluppo di un progetto, è quello di sforare i tempi o il budget. Questo evento rischia di mettere a repentaglio il successo del progetto. Per minimizzare questo rischio è indispensabile, all’inizio, fare stime corrette di tempi e costi.
• sviluppo di funzioni non necessarie
• continue modifiche dei requisiti: i requisiti iniziali vengono continuamente modificati dal committente oppure dal fatto che la situazione ambientale non è stabile
• problemi tecnici di implementazione: va evitato di disegnare prodotti molto belli sulla carta ma di fatto impossibili da realizzare, o la cui affidabilità tecnica li rende di fatto inutilizzabili
• problemi di performance del prodotto, ad esempio una applicazione troppo lenta; per prevenire questi problemi è utile fare delle simulazioni e dei benchmarks di performance, e monitorare il prodotto ed il loro uso, soprattutto nei primi tempi dopo la distribuzione
• problemi di usabilità, di accessibilità o di utilità che non erano stati preventivamente identificati

Il modello a cascata

Il modello a cascata

A process model is a description of the significant aspects of the tasks that are accomplished during the development of software, including the artifacts produced, the agents involved in the activities, and the relationships between these entities.
@Bohem1988

La modalità di progettazione tradizionale, sviluppata intorno agli anni settanta, è definita a cascata, in quanto presuppone una sequenza quasi lineare di passaggi.

La figura descrive graficamente il modello. Si inizia con l’analisi dei requisiti, si passa ad una fase di analisi, progettazione, implementazione, test e distribuzione.

##Le fasi nel modello a cascata

Nel modello che proporrò nei prossimi paragrafi, si distinguono le seguenti fasi:

• esplorazione
• ricerca
• rappresentazione
• progettazione
• test
• implementazione

Una rappresentazione piuttosto dettagliata del modello a cascata dell’User centered design è riassunta nel sito usabilitynet.org, che divide il processo in pianificazione, raccolta dei requisiti, design, implementazione, test e misurazione, post rilascio.

<!--

About face: il processo

• Research: studiare gli utenti e il dominio
• Modeling: utenti e contesto d’uso
• Requirements: definire i bisogni degli utenti, i requisiti di business, i requisiti tecnici
• Framework: definizione della struttura e dell’interazione
• Refinement: processo iterativo di rifinitura del design, es dai wireframes ai prototipi ad alta fedeltà
• Support: collaborazione con gli sviluppatori per venire incontro alle loro esigenze salvaguardando l’integrità del progetto.

-->

Vantaggi del modello a cascata

• Le persone hanno bisogno di pianificare il loro lavoro, per sapere come procedere e per evitare la sensazione di overwhelming.

• Una ragionevole analisi e pianificazione iniziale costituisce una buona base per la progettazione e l’implementazione, diminuendo il rischio di errori o la necessità di modifiche strategiche al progetto.

• L’adozione di standard procedurali può essere di aiuto soprattutto nella gestione contemporanea di più progetti, ma anche per affinare la metodologia fra un progetto e l’altro. Diviene inoltre più facile verificare il progetto, collaborare con altri team o con persone esterne, condividere materiale o software.

• Se si segue uno standard procedurale diventa più facile misurare i progressi fatti e gli eventuali problemi.

Limiti dell'approccio a cascata

L’approccio classico (a cascata) a volte fallisce, in quanto emergono una serie di problemi che costituiscono dei seri ostacoli al successo progettuale [@Parnas].

• Difficoltà nello stabilire i requisiti del cliente
• Difficoltà nell’analizzare i vincoli progettuali
• Difficoltà del team di comprendere il progetto
• Cambiamenti esterni
• Errori
• Rigidità cognitiva

Non tutto è analizzabile a priori

I fenomeni che rientrano nella progettazione non sono analizzabili con precisione, perché spesso vi sono vincoli, interni o esterni al progetto, che non possono essere analizzati con precisione a priori, e possono emergere solo in fase di test.

Testare troppo tardi

Se la fase di test avviene solo alla fine dello sviluppo, si aumentano i fattori di rischio:

• si dilatano i tempi di consegna;
• aumentano i costi di sviluppo, in quanto diventa necessario fare delle modifiche importanti ad un prodotto già sviluppato;
• se gli errori sono relativi all’analisi dei requisiti, bisogna sostanzialmente ripartire dall’inizio.

Approccio agile

Approccio agile

Per superare i limiti del modello a cascata è stato adottato un approccio, definito agile, che modifica in maniera piuttosto radicale la progettazione di software.

Questa modalità si basa sullo sviluppo iterativo ed è fondata su di una serie di linee guida (l’agile manifesto).

Approccio agile: il grafico

##Sviluppo iterativo e incrementale

Lo sviluppo agile assume un approccio iterativo e incrementale allo sviluppo iterativo.

L’idea di base di questo approccio è quella di sviluppare un sistema in maniera incrementale, per permettere al team di sviluppo di avvantaggiarsi di quello che si apprende durante lo sviluppo delle fasi precedenti.

Il team può fare tesoro dei feedback degli utenti che usano la versione implementata del prodotto, o quantomeno dei risultati dei test con utenti.

Minimum viable product ed evoluzione

L’idea è quella di iniziare con una implementazione di base, semplice, di un sottogruppo di funzioni e iterativamente far evolvere il progetto versione dopo versione.

Ad ogni iterazione è possibile apportare delle modifiche al design e aggiornare la lista dei requisiti.

La lista dei task

Il procedimento consiste in una fase di inizializzazione, di una serie di passaggi di iterazione e l’aggiornamento della project control list, la lista dei task che l’utente deve poter portare a termine.

La fase di inizializzazione crea una versione di base del sistema, per creare un prodotto con cui l’utente può interagire.

Dovrebbe offrire un esempio degli aspetti chiave del servizio, e fornire una soluzione abbastanza semplice da essere compresa ed implementata facilmente.

Nei progetti di piccole dimensioni l’implementazione costituisce la base della documentazione, e a volte la sostituisce. In progetti più grandi, o mission-critical, è comunque necessario utilizzare dei processi più formali di sviluppo.

Manifesto agile

Gli autori che hanno elaborato l’approccio agile hanno scritto un manifesto, che è costituito da un decalogo di principi da rispettare nello sviluppo agile [@Cockburn2000].

• soddisfare il committente (satisfy the customer): la priorità più alta è quella di soddisfare il committente, attraverso la distribuzione frequente e tempestiva di prodotti di valore (che funzionino)
• distribuzioni frequenti (frequent delivery): distribuire prodotti funzionanti con una frequenza che va da una volta ogni 2 settimane ad una volta ogni 2 mesi
  • continui feedback e pivot (cambiare in base ai feedback)
  • un mvp è già un prodotto
• software funzionante (working software): è la principale misura dello stato di avanzamento.
• accettare i cambiamenti di requisiti, anche quando arrivano tardi nella fase di sviluppo.
• collaborazione (work together) fra committenti, sviluppatori e team multidisciplinare
• persone motivate (motivated individuals): crea i progetti attorno a persone motivate, e dai loro l’ambiente ed il supporto di cui hanno bisogno, e fidati di loro per la realizzazione del lavoro
• comunicazione diretta (face-to-face conversation) e meno documentazione formale (documentazione lean)
• gruppi auto-organizzati (self-organizing teams): i progetti migliori emergono quando vi è la possibilità di contare su forme di auto-organizzazione.
• attenzione alla qualità (excellence and good design)
• sviluppo sostenibile (sustainable development)
• semplicità (simplicity), ovvero l'arte del non fare le cose inutili
• adattare il metodo (become more effective): ad intervalli regolari, il team cerca di capire come diventare più efficace, e cerca di aggiustare la propria metodologia. liorare non solo il prodotto ma anche il metodo.

L’approccio agile basa i suoi vincoli non su regole specifiche ma su principi generali: sviluppare e distribuire, presto e frequentemente, prodotti funzionanti, in stretto contatto con il committente e tenendo conto di eventuali mutamenti di contesto.

Vantaggi

• risultati parziali ma immediati: il committente può ottenere dei risultati, seppur parziali, piuttosto precocemente
• offre delle gratificazioni intermedie: sia il committente che il team di sviluppo che gli utenti vedono da subito qualche risultato.
• in caso di sopraggiunte difficoltà (ad esempio un periodo di difficoltà finanziaria del committente) vi è comunque un prodotto che funziona;
• in caso di cambiamento di condizioni in termini più favorevoli (maggior budget, oppure la disponibilità di nuove risorse tecniche, umane o di altro genere) è possibile non rendere più veloce lo sviluppo, oppure implementare delle idee più ambiziose che prima erano rimaste nel cassetto in quanto non sostenibili
• l'approccio iterativo permette un continuo miglioramento del prodotto, magari con delle tempistiche di distribuzioni più lente (una volta ogni sei mesi, ad esempio) e con un budget più ristretto.

Limiti dell’approccio agile

Nonostante i suoi vantaggi, anche lo sviluppo agile ha dei limiti, come evidenziati da @Bohem2002.

• documentazione: una documentazione informale non è adeguata a tutti i progetti, a tutti i team, a tutte le circostanze
• l'approccio agile implica il coinvolgimento dei committenti; quando questo tipo di coinvolgimento non è possibile, l’approccio agile aumenta il rischio di incomprensione con il cliente, in quanto manca sia la comunicazione conversazionale implicita nel metodo, che la documentazione più formale prevista dall’approccio tradizionale.
• l'approccio tradizionale è inoltre imprescindibile nei prodotti safety-critical: non possiamo immaginare uno sviluppo agile quando si parla di sistemi di controllo aereo, di centrali atomiche o di strumenti medici.

Requisiti

Secondo i fautori dell’approccio agile le organizzazioni sono sistemi adattativi complessi, in cui i requisiti sono emergenti durante il corso dello sviluppo e non sono facilmente prespecificabili.

L’approccio tradizionale funziona meglio quando i requisiti possono essere determinati a priori, anche attraverso la prototipazione, e rimangono stabili.

Se, al contrario, i requisiti cambiano spesso e molto, l’enfasi tradizionale verso una pianificazione precisa, completa, consistente, testabile e tracciabile diventa fortemente controproducente.

Dimensioni del progetto: lo sviluppo agile appare vincente in team piccoli, mentre lo sviluppo tradizionale, più pianificato, diventa essenziale in gruppi di lavoro di grandi dimensioni.

Bilanciare agilità e disciplina

Un eccesso di pianificazione porta ad un aumento dei tempi e dei costi. Troppo poca pianificazione porta ad un aumento dei rischi di errore. A seconda del contesto diventa essenziale trovare un buon rapporto fra agilità e disciplina.

Agile e UX: aspetti convergenti

Semplicità, buon design ed eccellenza, funzionalità sono obiettivi sia dell'agile che dell'ux team.

Lavorare in team co-locati, motivati, capaci di auto-organizzarsi, di adattarsi ai cambiamenti, di imparare dall'esperienza, sono pratiche che ben si adattano sia allo sviluppo agile che all'UX design, entrambi interessati ad uno sviluppo sostenibile.

Agile e UX: divergenze

• L'agile manifesto si concentra sul customer inteso come committente, non sull'utente finale. Ma senza il coinvolgimento degli utenti, non c'è User Experience design.

• Il software (funzionante) è il primario indice di progresso per lo sviluppo agile. Ma l'esperienza non è il software. Il software è un tassello nell'esperienza, e la fase di ricerca nell'UX deve prescindere dallo sviluppo del prodotto.

• Un approccio esclusivamente iterativo è incapace di gestire gli aspetti gerarchici dell'esperienza e della sua concettualizzazione. Ignorare le gerarchie concettuali non ci permette di distinguere gli elementi stabili, da progettare prima, e quelli più mutevoli, perché legati al contesto, dove un approccio agile è necessario.

Metodologia: fasi, piani, domande

In questa sezione introduciamo un quadro metodologico, distinguendo tre dimensioni:

• le fasi progettuali
• i piani di astrazione
• le domande di design

Le fasi progettuali

Il modello progettuale che propongo distingue le seguenti fasi

• esplorazione
• ricerca
• rappresentazione
• progettazione
• test
• implementazione

Le fasi del modello

Jesse James Garrett: 5 piani

Nel suo “The elements of user experience” @Garrett_2003 distingue 5 piani, che corrispondono a diversi livelli di astrazione della ricerca e rappresentazione:

• the strategy plane (la strategia);
• the scope plane (il dominio);
• the structure plane (la struttura);
• the skeleton plane (lo scheletro);
• the surface plane (l’aspetto visuale).

I Loci argumentorum

Ermagora di Temno, nel II secolo a.C. ha identificato 8 loci argomentorum, ripresi da Agostino e da Tommaso d'Aquino:

1. Quis - Chi - Who -> persona
2. Cur - Perché - Why -> causa
3. Quid - Cosa - What -> factum
4. Quomodo (quem ad modum) - In che modo (come) - How -> modus
5. Ubi - Dove - Where -> locus
6. Quantum - Quanto
7. Quando - Quando - When -> tempus
8. Quibus Auxiliis (quibus adminiculis) - Con quali mezzi -> facultas

I loci argomentorum possono servire da guida nel processo di design

Garrett vs Ermagora

I metodi

Chi (strategy)

Identificare gli utenti, segmentarli.

Esplorazione

Segmentazione dell'utenza

Ricerca

Interviste, questionari, osservazione partecipata ....

Documenti

Personaggi (personæ)

Perché (strategy)

Se progettiamo e realizziamo prodotti attraverso cui gli utenti possono soddisfare i propri scopi, quelle persone saranno soddisfatte, efficaci e felici, saranno soddisfatte di aver acquistato i nostri prodotti, li raccomanderanno agli amici, e questo si traduce in un successo di business @Cooper_1999.

Identificare le motivazioni (degli utenti, dei committenti) è il processo alla base del goal oriented design.

Si definiscono:

• i bisogni degli utenti che l’artefatto vuole soddisfare, attraverso l’analisi degli utenti attuali e potenziali;
• gli obiettivi dei committenti:
  • business goals: guadagnare soldi, risparmiare soldi, migliorare la produttività ...
  • branding, advertising: far conoscere il proprio marchio, i propri prodotti, i propri servizi a potenziali clienti e partner.

Perché: strumenti e documenti

Esplorazione

• analisi degli stakeholder

Ricerca

• intervista ai committenti
• ricerche di mercato
• interviste, questionari, repertory grid, laddering

Documenti

• segmentazione degli utenti su base motivazionale: bisogni, scopi, valori, interessi;
• aspetti motivazionali come elementi delle personæ.
• stakeholder analysis
• documento di strategia

Cosa (scope - il dominio)

A questo livello vengono definite

• le specifiche funzionali
  • quali funzioni vogliamo sviluppare, in che ordine di priorità, a che iterazione;
  • quali funzioni non vogliamo sviluppare;
• il dominio informativo (content requirements): quali informazioni.

Cosa: strumenti e documenti

Esplorazione

• analisi competitiva (benchmark)
• analisi contenuti esistenti

Ricerca

• richieste dei committenti:
  • interviste
  • focus group
  • affinity diagram
• coinvolgimento degli utenti:
  • repertory grid
  • free listing
  • valutazione di importanza
  • interviste strutturate
  • questionari

Documenti

• inventario contenuti e funzioni esistenti (as-is)
• elenco contenuti e funzioni desiderati, ordinato per importanza
• matrice competitiva
• mappe concettuali - ontologie

Quando

Nella progettazione della User Experience il quando mappa le fasi dell'esperienza (prima, durante, dopo). Vengono rappresentate le esperienze lungo l'asse temporale.

Esplorazione

• analisi e mappatura dei processi esistenti

Ricerca

• interviste: scenari / task analysis

Documenti

• mappa dell'esperienza
• customer journey
• service blueprint

Come (structure)

Vengono progettate, secondo @Garrett_2003:

• l’interaction design:
  • come il sistema si comporta in risposta ai comportamenti dell’utente;
  • definizione dei flussi di processo;
  • flussi dei compiti degli utenti
• l’architettura dell’informazione, la struttura dell’informazione nello spazio informativo:
  • la struttura gerarchica
  • le faccette
  • le (micro)ontologie.

Come: strumenti e documenti

Strumenti

• interaction design:
  • task analysis
• architettura informativa:
  • card sorting
  • affinity diagram

Documenti

• diagrammi di flusso (interazione)
• tassonomie
• alberi di navigazione
• filtri / navigazione a faccette

Dove: i canali

Nell'ambito dell'UX - IA possiamo identificare i mezzi nei vari canali:

• desktop o laptop;
• web;
• mobile (smartphone, tablet);
• chioschi interattivi;
• sistemi interattivi montati su veicoli e automobili;
• sistemi di home entertaimnent (console per giochi, TV interattive, home theater);
• strumenti professionali (scientifici, medicali).

Lo scheletro

@Garrett_2003 definisce 3 componenti:

• l’information design: la presentazione delle informazioni all’utente;
• l’interface design: la progettazione degli elementi dell’interfaccia per permettere agli utenti di interagire con l’applicazione;
• la progettazione della navigazione, che permette agli utenti di muoversi all’interno della struttura informativa.

Nella progettazione multicanale, è necessario progettare differenti scheletri per i diversi device.

Strumenti

• pattern
• linee guida

Documenti

• wireframes
• prototipi

La superfice

A questo livello si progettano gli aspetti visuali. Gli aspetti di cui tener conto sono molteplici:

• estetica;
• accessibilità;
• brand, identità;
• consistenza interna ed esterna;
• colori, tipografia, impaginazione.

Testi citati