blog: C’è vita nell’experience design

Non sto nemmeno a spiegarvi perchè sia importante capire a fondo le caratteristiche delle persone che andranno a visitare un sito o un servizio che stiamo progettando.

Se avete deciso di buttarvi sul nostro stesso approccio progettuale cioè quello centrato sugli utenti significa che è proprio da essi che dovete partire per procedere in tutte le vostre scelte attraverso le varie fasi del progetto: strategia, comunicazione, architettura informativa, interaction design, visual design e produzione.

Ma come si fa a capire le caratteristiche degli utenti e come si formalizzano per procedere nel lavoro?

Attraverso le cosiddette “Personas“.

Una personas non è altro che una pagina descrittiva di un personaggio che probabilmente avrà interesse nel visitare il nostro sito. Gli elementi più importanti e utili di questa pagina sono le motivazioni che l’utente ha per visitare il sito e i suoi bisogni.

Ma come si fa a sapere che caratteristiche ha l’utente e quali sono i suoi bisogni?

1. Attraverso il confronto con il cliente, semplicemente chiedendogliele. E’ importante chiedere direttamente al cliente perchè conosce in profondità le dinamiche del mercato o del contesto in cui vogliamo posizionare il sito. Bisogna tuttavia fare attenzione a distinguere i profili consegnati dal cliente dai profili effettivi degli utenti online: clienti reali e utenti del sito spesso non coincidono dal momento che i loro bisogni è possibile che siano diversi!

2. Se il progetto in cui siete coinvolti riguarda un sito che ha già una storia potete andare ad analizzare i file di log, ovvero tutte le informazioni che il server ha registrato riguardo i comportamenti degli utenti fino ad oggi: i backlinks (i siti su cui erano prima di accedere al nostro sito e dove hanno trovato il link d’ingresso), le parole chiave che hanno inserito nei motori di ricerca e che hanno permesso loro di trovarci, il tipo di browser e sistema operativo utilizzato, la località geografica di provenienza (stato, regione, città), il tempo di permanenza, le pagine di uscita, i percorsi navigazionali più gettonati, ecc..
Ecco tutte queste informazioni ci sono d’aiuto nel capire, o meglio, dedurre, le tipologie di persone che visitano il sito.

3. Direttamente attraverso delle belle analisi sul mercato e sull’utenza :)

4. Infine non vi resta che prendervi un collega e passare un pò di tempo con lui facendo un brainstorming sulle possibile caratteristiche.

Una volta che vi siete fatti un’idea e pensate di aver in mente tutte le possibili tipologie di utenti e bisogni è il momento di mettere nero su bianco ciò che avete raccolto e dare vita alle vostre Personas.
Vedrete che con lo scrivere vi verranno in mente tanti dettagli a cui ancora non avevate pensato ;)

Gli elementi da inserire nella personas di solito sono questi:

Foto
Mi raccomando di sceglierla bene perchè ogni volta che si parlerà della tipologia di utente descritta in questa personas verrà sempre in mente questa faccia ed è il caso che rappresenti in modo corretto la tipologia di personaggio.
In genere cercate dei primi piani o dei mezzi busti in modo che il carattere della persona si possa cogliere appieno.
Eventualmente sono utili anche inquadrature contestualizzate che rappresentano il personaggio nel suo contesto abituale.
Potete cercare le foto su flickr tra gli scatti con Creative Commons oppure cercate direttamente su google “head shot”.

Dati anagrafici
Servono per crearsi un’immagine ben precisa del personaggio. Informazioni reali e plausibili aiutano i collaboratori del progetto a farsi un’idea corretta dell’utente.

• Nome (serve soprattutto per potersi riferire a lui in fase di discussione)
• Professione (ruolo)
  
• Età

Background personale
In poche frasi dovete descrivere la storia e la situazione del personaggio concentrandovi su quei dettagli che possono venire utili per capire i bisogni che elencheremo in seguito. Attenzione che troppe informazioni posssono distrarre.

Abilità tecniche
Descrivete il confort tecnico che il personaggio ha con le tecnologie per far capire quanto potrebbe essere a suo agio con funzionalità più o meno complesse.

Bisogni
Questa informazione è importantissima! Dovete riuscire ad elencare i bisogni dell’utente indipendentemente dal sito. Per esempio nel caso di un sito di viaggi un possibile bisogno generico dell’utente potrebbe essere “organizzare un viaggio”. Sono gli obiettivi finali, i bisogni che devono soddisfare. Il fatto poi che il sito potrà aiutarli a soddisfare tali bisogni sarà il passo successivo.

Motivazioni
Sono gli scopi particolari che l’utente può avere sul sito. Per esempio a partire dal bisogno generico “organizzare un viaggio”, le motivazioni d’uso particolari rispetto al sito potrebbero essere “trovare tutti i voli last-minute del fine settimana” o “acquistare un biglietto del treno Milano-Venezia”.

Scenari
Potrebbe essere interessante associare ogni motivazione allo scenario corrispondente. Tale relazione può essere indicata direttamente nella personas ma sarà sviluppata e approfondita in un documento a parte e specifico per gli scenari d’uso. Le scenari in generale sono una descrizione del comportamento dell’utente. Segue i suoi movimenti, i suoi click e offre un’immagine precisa e realistica dell’esperienza d’uso.

Features
Infine potrebbe essere utile indicare per ogni motivazione le features (le funzionalità) coinvolte nel raggiungimento dello scopo. Se il nostro progetto non riguarda un sito già esistente queste informazioni sono ovviamente solo abbozzabili e immaginabili grazie ai brainstoming e alle analisi iniziali.

Ecco. E’ tutto. Come potete intuire le personas non servono ad altro che far riflettere tutti i partecipanti del progetto sugli utenti possibili e far innescare tutta una serie di riflessioni.
Mi raccomando, sono molto utili! Sono un ottimo punto di partenza per allineare le aspettative di tutti gli agenti coinvolti nel progetto.

E ora dateci dentro con la fantasia! Può essere un’attività molto divertente :)

E’ difficile immaginare Aristotele mentre cerca difetti nel software.

Eppure i suoi lontani sillogismi sono alla base di quella branca della logica che si occupa di verificare la correttezza del software, dove per correttezza non si intende il banale test finalizzato alla ricerca di difetti, ma la sicurezza assoluta che una applicazione funzioni come previsto.

Tradizionalmente, la correttezza formale del software è un requisito che viene considerato solo in ambiti molto specifici (militare, aero-spaziale, sistemi di controllo e sicurezza realtime), dove il prezzo di un singolo difetto può essere molto alto.

La storia dei bug è ricca di aneddoti, e sono in molti a ricordarsi del disastroso lancio dell’Ariane 5, in cui in 37 secondi bruciarono più di 370 milioni di dollari.

Quello che succede di solito, è che il costo di una verifica formale, è così alto che si preferiscono usare tecniche di debugging basate su test. Questo non perchè le università non diano ai propri studenti basi di logica del prim’ordine, teoria dei tipi e utilizzo di dimostratori automatici, ma perchè il processo di traduzione delle istruzioni software in linguaggio logico è una operazione che richiede competenze e tempi che non rientrano nel budget a disposizione.

Esiste però un progetto finanziato dall’unione europea, che si pone come obiettivo quello di portare la correttezza formale del software nel mondo del mobile (cellulare e PDA), creando un sistema che consenta agli sviluppatori di accedere a parti di codice certificate come corrette.

Il fatto che esistano progetti di questo tipo non implica automaticamente che in futuro potremo utilizzare in mobilità applicazioni esenti da bug (molto dipende da quanti sviluppatori vi aderiranno), ma ci fa comprendere come l’attenzione verso il mondo mobile, negli ultimi mesi, sia sempre più elevata, e coinvolga settori, come quello della ricerca, che spesso sono accusati di andare per conto proprio, senza seguire le necessità del mercato.

I confini fra inspiration-board e mood-board sono solitamente molto sfumati ed è per questo che spesso vengono confuse le une con le altre. Sono entrambi strumenti utilizzati da varie tipologie di progettisti, dai fashion ai visual agli interior.

La mood-board ha comunque un livello di dettaglio maggiore rispetto a quello della inspiration-board.
Ma basta tergiversare e pocediamo con i soliti 4 punti per definirme meglio l’identità:

Cos’è una mood-board?

“Creating a mood board is a great way to visualise how the final room will look and will help you decide which colours complement or clash with each other.” bbc.co.uk homes

Come si capisce da questa semplice descrizione (sicuramente non tecnica) tratta da “bbc casa”, una mood-board è qualcosa che ci fa capire, ci fa rendere conto di quali sono effettivamente le componenti (anche se ad un livello assolutamente non di dettaglio) che vogliamo utilizzare in un progetto.
Raccogliere elementi che siano legati al progetto stesso, al suo stile, alle sue caratteristiche (forme, texture, colori, tipografia).
Nelle mood-board o “tavola degli umori” si esplicitano in maniera più evidente i valori legati ad un prodotto, il feeling, e il tono di voce che si vuole dare nel design. Se nella inspiration-board si trovano raggruppati tutti gli elementi che ci sembrano poter andare con quello che stiamo per fare, in questo secondo tipo di deliverable si trovano esempi, samle, palette cromatiche, immagini evocative, etc…

Dove? A che livello del processo va inserito il suo sviluppo?

In qualsiasi tipologia di “processo creativo” (scusate se uso questa parolaccia :P) sia prima che dopo la creazione di un’inspiration-board vengono fatti brainstorming, per ricavare concetti, valori, parole, colori, collegati a quello che si vuole esprimere. Da queste riflessioni si sviluppano anche le “tavole degli umori“.

La mood-board è una delle deliverable centrali del processo e come l’inspiration-board viene spesso sviluppata a 4 mani dai visual e dai communication designer. Per rendere più completa la progettazione ne possono venir sviluppate svariate in parallelo. I risultati di tale lavoro si fondono per arrivare ad una “soluzione”.

A chi serve? Per cosa?

È uno  strumento per procedere nella progettazione, ma può essere mostrato al cliente.
Naturalmente come tutte le deliverable intermedie è necessario che il cliente venga “istruito” su quello che sta per ricevere, altrimenti la conversazione potrebbe essere questa:

CNI = cliente (N.I) = Cliente Non Istruito
VDNHS = progettista = in questo caso “Visual Designer che Non Ha Spiegato”

VDNHS: “Ecco qua… questa è la moodboard realativa al suo servizio”
CNI: ” mmmmm …. mmmm …… mmmmm …..”
Il cliente ne discute con i collaboratori e passano alcuni minuti e una volta resuscitato inizia a sparare domande, osservazioni, a raffica
CNI: ” Cos’è?”
VDNHS: ” ehm …”
CNI: ” Sa questa pagina ci pare un po’ strana? Ma dove sono i contenuti? Queste immagini poi? mmm”
VDNHS: ” ehm … è una mood-board. Ci aiuta a capire come procedere … ”
CNI: ” Si ma … si mi piace questo viola, ma forse … mha non so e queste … ehmm ”
VDNHS: ” Sì questa non è la pagina, non è il visual  ”
CNI: ” Non è cosa? ”
E qui parte una specie di evangelizzazione… sulla teoria del design, della forma e della funzione, sulle varie deliverable, sulle mood-board, ecc…
CNI: ” mmm e lei ha impiegato due giorni per fare questo foglietto? ”
VDNHS: ” O_O ehmm si ma non è un foglietto… come le spiegavo …. ”

Risultato di tale conversazione: cliente non soddisfatto e visual designer arrabbiato

A volte lo spiegare non basta… quindi potrebbe essere una buona idea condividere deliverable intermedie in un secondo momento, od insieme ad altra documentazione di progetto :)

Passo successivo?

Dopo la/le mood-board il passo successivo saranno le style-board, delle quali parleremo la prossima volta :)

Recentemente sono dovuta intervenire nell’ambito di due progetti esterni sistemando alcuni wireframe ad “alta fedeltà” che purtroppo i visual designer e gli sviluppatori non comprendevano. Analizzandoli ho subito notato l’assenza di alcuni elementi essenziali per concretizzare il design e un’assenza totale di riferimenti verso i vari flussi funzionali.

Con questo input ho pensato che fosse il momento giusto per ricapitolare le caratteristiche fondamentali che un buon wireframe ad alta fedeltà deve avere.

Partiamo però da cos’è un wireframe:
Un wireframe è ciò che si ottiene dalla progettazione di dettaglio dell’interfaccia in tutti i suoi stati. L’idea è quella di rappresentare nel modo più comodo e funzionale possibile le informazioni e le funzionalità pagina per pagina. In genere si rappresenta a differenti livelli di fedeltà (dalla bozza su carta, sketch, a quello finale) seguendo il processo naturale con cui nasce un’interfaccia.

Di fatto così otteniamo una solida base dell’interfaccia che contiene tutte le funzionalità del nostro prodotto/servizio il ché ci aiuta a comunicarlo a chi interverrà nelle parti successive del processo e ai clienti. Nonostante i wireframe siano strumenti che aiutano chiunque nella risoluzione del progetto, richiedono per il loro sviluppo competenze specifiche di UI e Interaction design.

Con questo post vorrei inziare con voi una riflessione che vorrei sviluppare nei prossimi mesi: come progettare architetture informative per ecosistemi digitali, ovvero architetture adattabili ad una molteplicità di device, a partire dal computer per arrivare ai supporti mobili come cellulari e iPhone.

Iniziamo però con il capire che cosa si intende per ecosistema digitale dal momento che d’ora in avanti si userà questo termine e forse non è entrato ancora con certezza nel nostro lessico quotidiano.
La definizione che vi propongo si riferisce ad ecosistemi di applicazioni e servizi online ed è di Massimo Giordani, docente di “Integrazione dei media” e di “Strumenti e metodi di interazione ipermediale” al Politecnico di Torino:

Un ecosistema digitale è concettualmente analogo a un ecosistema biologico, dove ogni singola parte cresce con il tutto. E’ una visione olistica della Rete che trova fondamenti scientifici nelle più recenti teorie sui sistemi complessi e sullo sviluppo delle reti a invarianza di scala (scale free network).

Da un punto di vista operativo, questo approccio consente di raggiungere risultati formidabili in termini di visibilità on-line e, quindi, di probabilità di essere trovati dai navigatori potenzialmente interessati a uno specifico tipo di informazione.

Elementi base di un ecosistema digitale sono, oltre al “classico” sito Internet, i nuovi strumenti resi possibili dal cosiddetto Web 2.0, tra cui blog, Podcast, YouTube, Flickr, MySpace, Second Life, le community di settore, i social network, i forum, i syndication, i Mashup, e tutti quei canali e luoghi digitali con cui è possibile “comunicare”, magari a target diversi ma in un’ottica fortemente integrata, pianificata accuratamente e gestita con continuità.

Il passo in più che vorrei fare riguarda il dominio a cui applichiamo la definizione di ecosistema e cioè vorrei parlare più che di ecosistema delle applicazioni, di ecosistema dei supporti e dei device (attraverso i quali tali applicazioni vengono fruite).

Mi sposto quindi verso il concetto di ecosistema di dispositivi digitali perchè la comunicazione integrata citata da Giordani possa sfondare i confini della connessione fra applicativi per approdare ad una più completa molteplicità che tenga in conto anche la varietà dei supporti fisici di fruzione.

Sto parlando di una problematica quanto mai attuale in questi ultimi mesi. Con l’avvento dell’iPhone a giugno di quest’anno i riflettori si sono spostati improvvisamente sul mobile (già a fine 2007 erano in molti ad elencare fra i buoni propositi dell’anno venturo l’ascesa del mobile).
Mai prima d’oggi la navigazione del web è diventata così accessibile al largo pubblico anche attraverso supporti diversi dal tradizionale monitor da 15 pollici (e inserisco anche gli 11 pollici degli Asus EEE & Co. fra i supporti tradizionali.. ).

La verità è che quest’anno un milione di persone solo in Italia ha navigato su Internet tramite cellulare.

Ma di tutti i siti a cui le persone accedono tramite telefonino o iPhone, quali sono strutturati in modo sufficientemente efficace per il nuovo dispositivo e abbastanza coerente al sito madre? Quali riescono ad offrire il giusto connubio fra contenuti offribili (quelli del sito madre) e contenuti offerti (quelli del sito mobile)?

Ma soprattuto se esistono siti mobile efficaci, perchè lo sono? Come è stata costruita l’architettura informativa? In cosa differisce dall’architettura informativa del sito madre?

Ecco, nei prossimi mesi cercherò di rispondere a queste domande.

Prima di chiudere questo primo post introduttivo sulla progettazione per mobile vorrei comunque sottolineare che l’attuale relazione madre-figlio fra le architetture informative non è per nulla indicativa del futuro! Potrebbe benissimo accadere che le architetture madri saranno quelle delle versioni mobile oppure che le architetture saranno tutte sorelle e semplicemente adattate al singolo dispositivo.

Se qualcuno mi vuole dare una mano nel portare avanti queste riflessioni è il benvenuto :)

La settimana scorsa ho fatto da rappresentante degli Sketchini in terra portoghese, andando a sentire cosa si raccontava a Shift 2008. Due giorni di conferenza in lingua inglese più uno dedicato ai workshop, questo evento ha attratto a Lisbona persone provenienti da diversi paesi europei (più qualcuno dagli Stati Uniti).

Ora, non vorrei spendere troppe parole su Lisbona (se non ci siete mai stati, è da vedere), sul cibo (ottime mangiate di pesce a prezzi super contenuti!) o sulla location (che incanto…), ma passare direttamente a una tra le sessioni che ho seguito durante i due giorni di conferenza.

Prendiamo lo speech di Delphine Ménard, tenutosi tra pochi intimi in un clima di assoluta comprensione. Delphine si è presentata, ha detto di essere francese, ma di vivere in Germania, ma di essere stata a lungo negli Stati Uniti. Alla domanda “di dove sei?” alcune persone si sono guardate tra loro rimanendo interdette, che significa di dove sono? Dove sono nata? Dove vivo? Di quale nazione o città sento di far parte? E’ esattamente il tipo di domanda che mi lascia interdetta. A quanto pare, molti in quella sala erano nella stessa situazione.

Il discorso si è poi spostato sull’uso delle parole, Delphine ha preso come esempio la sua teoria della tazza, “bowl” in inglese, che a seconda del contesto culturale usiamo in modo differente. Per esempio, la traduzione francese, “bol”, prevede che vi sia messa, ad esempio, cioccolato, mentre un tedesco riderebbe di questo abbinamento perché nella “Schale” mette solo zuppa.

Di per sé l’argomento è simpatico e scatena curiosità linguistiche (tutti in sala annuivano e commentavano ogni parola), ma se trasferiamo questo tipo di discorso al design e ai contenuti di un sito web la faccenda diventa molto seria. Quando si progetta un sito è necessario tenere ben presenti le regole del bacino culturale di riferimento, mentre la mera traduzione linguistica tra culture molto diverse può portare al risultato della tazza di cui sopra. Il significato delle forme, dei colori, dei contenuti, dello stile sono diversi e devono essere riadattati mano a mano alle culture in cui vengono inseriti. Se da questo si passa alle persone, quindi alle community, l’importanza della gestione locale aumenta, fino a diventare indispensabile per cogliere le sfumature.

Ma se lo dovessimo fare lo stesso senza avere a disposizione le risorse necessarie? Alla richiesta di suggerimenti per come fare questa traduzione avendo a disposizione pochissime basi culturali, la parola d’ordine è stata minimalismo. Conviene dunque progettare l’essenziale e attendere che la community ci guidi all’inserimento contestuale del sito attraverso i feedback.

A voi è capitato di avere a che fare con problemi legati alla multiculturalità? E di dove siete? :P

Ieri si è tenuto il nostro primo meetup, tema: mobilità nelle applicazioni.
Ah! Grazie mille a chi ha partecipato alla discussione :D

Gli ottimamente splendidi salatini fatti in casa di Dafne

Eccoli qua :)

Meetuppisti pensanti

Meetuppisti ascoltanti

E’ l’ondata dell’impegno sociale e non possiamo proprio farne a meno. Dai media tradizionali ai new media, dai consumatori alle aziende, la tematica ecologica è ormai stata promossa a tutti gli effetti argomento di discussione e discussioni. Essere socialmente impegnati è diventato un must ma soprattutto un must show che riguarda sempre piú la vastità di comunicazioni mediate dalla rete. In questo contesto non basta fare scelte eticamente corrette nel privato ma diviene piú importante mostrare un’attenzione a tale tematica tramite profili virtuali e community. Questo atteggiamento oggi non si tramuta piú (o non necessariamente) in una serie di scelte politicamente coerenti, ma piú probabilmente appartiene al lungo elenco di appartenenze flebili che caratterizzano le identità da nuovo millennio. Sono queste appartenenze ad assumere la forma di cause cui partecipare su social network, blog e community.

Oggi voglio mostrarvi tre esempi che trovo interessanti e divertenti per la parte di produzione creativa e interazione sociale che prevedono.

Il primo è Everywun, che in pochi minuti permette di creare il proprio badge personalizzato da copiaincollare su profili, pagine personali e blog, pubblicizzando cause esistenti o creandone una propria. Permette inoltre di costruire un team per rappresentare la propria scuola o città tramite una causa. Corredato di forum e blog, prevede una donazione per ogni click e il monitoraggio dello stato della propria causa.

Il secondo esempio è Cause TV, la versione socialmente etica di You Tube, che permette di creare e diffondere un video che pubblicizzi la propria causa con allegata scheda descrittiva che spieghi la mission, la location, l’organizzazione o la persona di riferimento, il link del sito internet e i tags. Permette di recrutare persone e di vedere chi aderisce a una causa.  Mi piace particolarmente perchè si tratta di una vera e propria produzione mediale che puó generare risultati interessanti in relazione all’impegno personale dei singoli.

Il terzo esempio di oggi è Superuse, progetto che mi interessa particolarmente per la felice unione di design e impegno sociale. Si tratta di una community composta da designer, architetti e da chiunque sia interessanto a riciclare in maniera originale. Permette di postare idee e progetti che verranno poi discussi e votati generando nuove comunicazioni sul tema. L’ imperativo è utilizzare materiale di scarto per produrre dal letto matrimoniale in cartone al volo di farfalle uscito da lattine di birra, ma si tratta anche di uno spazio per parlare di concept, materiali, arte e media rigorosamente eco.

A questo punto non rimane che essere i prossimi eco-victims… ;o)

Tutti seduti, tutti pensanti, tutti concentrati per un Ping Wang … tranne me che sto scattando le foto :P

Leonora, Francesca, Diana e Dafne

Luca

Da qualche anno la potenza di calcolo disponibile sui personal computer ha permesso di portare sul web giochi ed applicazioni computazionalmente pesanti, senza che questo comprometta la normale fruizione di contenuti.

La grafica 3D e la fisica sono due degli ambiti che richiedono più potenza di calcolo, e l’uscita dal flash player 10, prima versione in grado di sfruttare la GPU per elaborare dati, ci fa comprendere come nei prossimi mesi sia lecito aspettarsi una diffussione su larga scala di applicazioni che includano grafica 3D, calcoli fisici, ed effetti applicati in tempo reale.

Dopo il post relativo a Gravitwit, ho ricevuto alcune e-mail che mi chiedevano spiegazioni sul motore fisico dell’applicazione; scrivo questo post per elencare gli indirizzi di alcuni dei motori fisici 2D esistenti per Flash/Flex (insomma, per ActionScript 3), sperando di fare cosa gradita a chiunque sia interessato all’argomento.

BOX2D - http://box2dflash.sourceforge.net/

Porting in AS3 di un motore fisico originariamente scritto in C/C++. Sul sito sono presenti alcuni esempi, le API, e un forum di supporto. Licenza zlib/libpng.

MOTOR - http://lab.polygonal.de/motor_physics/

Interessante evoluzione di Box2D da parte dei ragazzi di Polygonal. Licenza BSD.

APE - http://www.cove.org/ape/

Motore fisico creato da Alec Cove; purtroppo lo sviluppo è fermo da tempo.

FISIXENGINE - http://www.fisixengine.com/

Motore fisico 2D, licenza commerciale