Alberto Mucignat

Domenica ho letto tutto d'un fiato "Da cosa nasce cosa" di Bruno Munari. Libro illuminante per chi fa experience design, quindi anche per il web.

Tra le altre cose ho trovato una parte che ben si collega alle mie ricerche su web e gioco. In una parte del libro Munari parla dei giochi in questi termini:

Il giocattolo ideale deve poter essere capito dal bambino senza alcuna spiegazione. Si può lasciare il giocattolo in mano al bambino e lui lo dovrebbe capire, sia cosa è, sia come si usa.

Questa cosa è valida anche nel web e si chiama usabilità. Potrebbe bastare questa frase a farci pensare, ma continua Munari:

Spesso occorre spiegare questi semplici giocattoli agli adulti, poichè gli adulti sono qualche volta nell'impossibilità di capire per eccesso di cultura che, se non è assimilata ma solo immagazzinata, fa da filtro a tutte le novità, per cui se uno vede una cosa nuova, non avendo una mente elastica, resta bloccato e la rifiuta perchè gli crea un complesso di inferiorità.

Ecco spiegata la frustrazione degli utenti adulti davanti ai problemi di usabilità.

In conclusione, credo che nel web siamo tutti un po' adulti. Ovvero:
1. il web dovrebbe essere semplice e autoesplicativo
2. per quanto semplice, ci saranno degli utenti che lo troveranno inusabile o poco chiaro

L'idea del gioco mi aiuta a pensare a come progettare il web, è uno stimolo inesauribile. Se hai altre risorse sull'argomento, batti un colpo nei commenti, grazie.

Il mio amico Enrico Maria lancia una bella riflessione a proposito di come le interfacce web del futuro siano orientate sempre più allo storytelling.

In effetti, a guardare bene, i servizi web che oggi hanno successo sono quelli che consentono agli utenti di raccontare le proprie storie. Dai blog ai tumblog, da flickr a youtube, tutti mettono a disposizione un taccuino virtuale su cui appuntare pensieri, immagini, idee, riflessioni. Le interfacce di questi servizi sono sostanzialmente semplici e consentono di operare senza fatica e in pochi secondi.

Inoltre, spesso mettono a disposizione i cosiddetti bookmarklet (quello di Tumblr è eccezionale), che consentono con un click di farci compiere azioni sulla pagina che stiamo leggendo (ad esempio postare al volo alcune frasi in un blog o un'immagine che ci piace su un photo book).

Alcuni servizi, grazie alle API, consentono ai programmatori di sviluppare veri e propri tool di supporto al servizio (penso al flickr upload o a twitterrific). Questi tool permettono di raccontarci direttamente dal nostro computer, senza aprire il browser e dover andare sul sito web del servizio.

La mia impressione quindi è che le interfacce per lo storytelling stiano diventando sempre più immediate e facili da usare, fino a diventare quasi trasparenti per l'utente.

Inoltre, queste tendenze stanno facendo da traino anche per tutte le altre applicazioni web. Chi sviluppa web, specialmente in Italia, si trova quindi nella scomoda posizione di dover continuamente rincorrere questi "trends", con tutte le conseguenze del caso.

A tal proposito, hai qualche esperienza da condividere?

Nella progettazione centrata sull'utente (UCD, User-Centered Design) un passaggio chiave è quello di definire i personaggi (o personas), ovvero degli "utenti tipo" sui quali verrà centrata tutta la progettazione del servizio web. Alla fine del processo, di solito vengono prodotti un paio di personaggi per ogni progetto.

Ora la domanda è: come fanno questi 2 personaggi a rappresentare tutti gli utenti che avrà il mio servizio web? Come posso pensare di progettare un servizio per loro 2, quando in realtà può essere usato da milioni di utenti?

Flow Interactive ha postato a proposito una serie di risposte sensate che mi permetto di evolvere liberamente:

1. i personaggi sono tuttora il modo migliore che abbiamo per rappresentare gli utenti
2. i personaggi aiutano a definire gli utenti limite del sistema
3. non tentare di progettare per tutti gli utenti

In particolare, gli ultimi due punti si legano ad un piccolo sfogo di Stefano sugli utenti medi del web. Il punto è che spesso, nel definire i personaggi del nostro sistema, pensiamo proprio di dover definire l'utente medio, sul quale andiamo a costruire il nostro sistema web. In realtà, si dovrebbe definire un utente particolare, con esigenze particolari.

Faccio un piccolo esempio.

Di recente mi è capitato di vedere dei personaggi inventati di sana pianta. L'errore non è solo nel metodo, perchè di solito i personaggi vengono definiti dopo una fase di ricerca e analisi sul target degli utenti, supportata da attività concrete (interviste, focus group, ecc) (*). L'errore risiede soprattutto nel fatto che se ci inventiamo dei personaggi, inevitabilmente tendiamo a idealizzarli e a immaginarceli perfetti, perlomeno per il ruolo che devono ricoprire nel nostro scenario, nel nostro sito web.

Ma l'utente perfetto non esiste, come non esiste l'utente medio.

Per progettare un servizio web dobbiamo capire soprattutto per chi non stiamo progettando. È un pilastro della strategia: capire prima di tutto cosa non fare, a chi non rivolgersi. Ne consegue che non possiamo progettare per l'utente perfetto, ovvero per l'utente medio, ma dobbiamo invece definire gli utenti particolari del nostro sistema.

Questi utenti particolari hanno delle esigenze che sono evidentemente particolari. Soprattutto, queste esigenze devono combaciare quanto più possibile con i requisiti business. Questi ultimi, devono essere abbastanza circoscritti, altrimenti si ricade nel problema noto come WTGO ("Wannabe the Google of ...").

In conclusione, credo che il processo di definizione dei personaggi parta a monte, mentre si pensa al servizio da realizzare. Definiti i requisiti business, si definiscono di conseguenza i personaggi (gli utenti particolari!) a cui è rivolto il servizio. Questi ultimi non sono una semplice rappresentazione del target utenti, ma sono il prodotto di un'intensa attività di ricerca e analisi.

Mettiamola così: se non lavoriamo con criterio sui nostri personaggi, non stiamo nemmeno lavorando per i nostri 5 milioni di utenti.

(*) Penso che comunque sia una buona pratica immaginarsi i propri utenti, sicuramente meglio del non immaginarseli affatto

Segnalo un paio di conferenze mondiali che si terranno quest'anno in Italia:

CHI 2008
È la conferenza mondiale di computer-human interaction, che quest'anno sarà a Firenze il 5-10 aprile 2008. Il programma è pazzesco e ce n'è per tutti i gusti.

UPA Europe 2008
La prima conferenza europea organizzata dall'UPA (l'associazione mondiale dei professionisti dell'usabilità) e si terrà a Torino il 5-6 Dicembre 2008. Il programma è ancora da delineare, ma sarà sicuramente interessante.

Inoltre, segnalo un'iniziativa a Roma il 7-9 Maggio che ritengo molto bella e formativa: Web Senza Barriere 08 è una conferenza dove si parlerà principalmente di accessibilità, ma quest'anno ci saranno un bel po' di seminari interessanti su usabilità, architettura dell'informazione e user centered design.

Insomma, ci lamentiamo sempre, ma quest'anno ce n'è per tutti i gusti (e dobbiamo ancora annunciare l'IA Summit 2008!).

ps: sarò a Londra per FOWD, qualcuno viene?

Segnalo uno dei podcast più interessanti e che cerco di ascoltare nel tempo libero: Usability Tools Podcast della combriccola di Jared Spool. Il podcast è presente anche su iTunes, da sottoscrivere subito.

Ne parlo perchè ho recentemente riascoltato un podcast di agosto a proposito dell'home page design. Lo consiglio a tutti quelli che si impantanano a discutere col cliente cosa vuole (lui) in homepage.

Illuminante come Jared affronta l'annosa questione del presidente che arriva improvvisamente e vuole che una notizia appaia nella homepage, stravolgendo così il lavoro del design team. La risposta è nelle parole di Jared: "è un annuncio così importante da dover apparire in homepage? non è forse meglio inviarlo in newsletter?".

Poi Jared fa molti altri esempio e insomma è un podcast da ascoltare. Il fatto è che Jared Spool ha tanta esperienza e tanti argomenti, oltre a tanta capacità di contrattare con il cliente. Avendo spesso discusso di queste cose, mi rendo conto che alla fine conta la capacità di contrattare col cliente e di difendere le esigenze dell'utente.

Ecco quindi alcune mie regolette durante la fase di contrattazione della homepage:

- dobbiamo sempre impostare il lavoro in modo che sia chiaro chi accede alla homepage e per quali obiettivi. Per questo è importante presentare al cliente i personaggi e gli scenari, perchè mantengono il focus sull'utente finale e tolgono importanza alle estemporanee intuizioni del cliente ("è una cosa che cercano gli utenti in homepage?").

- è fondamentale separare l'aspetto funzionale/informativo dall'aspetto visuale. Un conto sono le informazioni che vengono visualizzate, che devono rispondere a delle precise esigenze dell'utente, un altro è lo stile grafico. Lo stile grafico per quanto mi riguarda viene sempre alla fine (ricordate i cinque piani di Garrett?)

- ci dobbiamo allenare per gestire le improvvise richieste del cliente. Dobbiamo avere delle risposte pronte per il 99% delle osservazioni che ci può fare. Il cliente va costantemente contenuto ed educato, che ci piaccia o meno.

Spesso succede di discutere della home page con un manager che mi riporta delle richieste di altri al di sopra di lui. Quello che accade è che spiego a lui le mie ragioni, ma lui non ha i miei stessi mezzi per spiegarle al capo.

La regola finale è quindi di identificare il responsabile più in alto in grado e di avere la sua approvazione, prima ancora di iniziare a lavorare. Quando ci sono richieste strampalate, devi poterne discutere con lui, altrimenti tutto il tuo lavoro è a rischio.

Maurizio Boscarol ha scritto un bellissimo articolo spiegando bene e in maniera semplice cos'è il card sorting e come si fa.

Il card sorting è un metodo di classificazione usato spesso nello user-centered design per definire architettura informativa o schema di navigazione di un sito. [...] È un metodo di coinvolgimento degli utenti per definire raggruppamenti (classificazioni, categorizzazioni) di contenuti. Si scrive ogni contenuto su un cartoncino e si chiede a diversi utenti di classificarli per somiglianza.

Il card sorting è uno strumento relativamente facile da utilizzare ed essenziale per chi progetta schemi di navigazione particolarmente complessi (come ad esempio le intranet), per cui l'articolo vale la lettura.

Hai mai giocato a qualche gioco sul web? Giocare è quello per cui il web è stato creato. -Weinberger

È da un po' che sto pensando a come integrare l'idea di gioco dentro la progettazione di un sito web, una community, un social network. Inizio un percorso di riflessione su questo tema, senza voler per forza arrivare da qualche parte.

Il primo tassello del puzzle è la presentazione Playful IA che il mio amico Kars Alfrink ha tenuto allo scorso Euro IA di Barcellona.

Il secondo tassello si intitola Engaging User Creativity: The Playful Experience, ed è apparso a dicembre su UX Matters.

Ora, se ripenso alla mia storia, ogni volta che ci siamo messi a progettare dei "siti sociali" cercavamo di trovare la "chiave del gioco". Come faccio a far interagire l'utente? Come faccio a coinvolgerlo? A farlo giocare? Anche la scorsa settimana mi sono trovato a parlare di gioco in questi termini, in due incontri con clienti, ma con due scenari diversi.

Trovo quindi illuminanti un paio di passaggi dell'articolo di UX Matters:

Play is not a passive quality, but one that demands interaction, exploration, and imagination. From this perspective, the playfulness of a complex user experience, while attributable in part to its design, is heavily reliant upon users and their level of engagement. In the end, users themselves create playfulness.

E ancora:

As applications evolve, all other factors being equal, people flock to the ones that are more fun to use—the ones that engage them. So, unless your application is indispensable—and even if it is—if it’s deadly boring, its days are numbered. Ultimately, it’s better if people spend time with our digital products because they want to, not because they have to.

Ecco, se penso al passato, trovo che forse avevamo la presunzione di dover individuare noi le chiavi del gioco, senza sapere invece su cosa gli utenti si sarebbero intrippati veramente.

Forse non è così importante trovare subito delle chiavi di gioco, è l'utente che decide il gioco, che piega l'applicazione web alle sue regole.

Diversamente, dobbiamo invece pensare di predisporre al gioco la nostra applicazione web, altrimenti è difficile che l'utente si senta coinvolto.

Direi che ce n'è abbastanza per iniziare, no?

I wireframe devono essere brutti, mi dice Mafe, che a sua volta gliel'hanno detto gli americani.

Da tempo progetto in bassa fedeltà, cerco di far entrare in gioco il visual design (colori, stili grafici, sfumature, rifiniture) solo nella fase finale del lavoro. Devo dire che funziona, anche se richiede un passaggio difficile per chi è abituato a visualizzare il prodotto come un insieme di colori ed effetti grafici.

Ripensando ai lavori passati, mi rendo conto di quanti mockup ad alta fedeltà venivano prodotti all'atto dell'offerta al cliente. Completamente inutili, perchè il cliente si fissava su un modello grafico e le successive modifiche venivano viste come una ritrattazione. E chi poteva dargli torto?

Soprattutto, le informazioni visualizzate nel mockup erano quasi sempre sbagliate, perchè il lavoro di progettazione doveva ancora essere fatto.

Per questo ci sono alcuni buoni motivi per lavorare in bassa fedeltà, almeno fino a un certo punto dello sviluppo di un progetto web:
- focalizzare l'attenzione su informazioni e funzionalità
- concentrarsi sulla struttura comunicativa e semantica
- rappresentare efficacemente le interazioni e l'architettura dell'informazione

Vi sono invece molti problemi a lavorare fin da subito in alta fedeltà. Ne cito solo alcuni:
- fissazione del cliente (ma anche dei designer) su un aspetto grafico prestabilito
- costi iniziali di sviluppo del design
- impossibilità di prevedere a priori tutte le informazioni da visualizzare
- difficoltà ai cambiamenti radicali di design
- difficoltà a concentrarsi sulle informazioni
- interminabili discussioni inutili sull'aspetto grafico
- poche discussioni costruttuive su come effettivamente deve funzionare il prodotto

Un collega anglosassone una volta aveva scritto "i wireframe migliori che ho visto erano schizzi disegnati sulla carta".

L'altro giorno un cliente ha visto i wireframe digitali di alcuni scenari di navigazione in media fedeltà. La reazione è stata abbastanza contenuta. Alla fine gli ho fatto vedere uno schizzo che non ero riuscito ancora a mettere in formato digitale, nel quale c'erano i miei commenti, scarabocchi vari e molte imperfezioni. La reazione è stata: stupendo, potresti darmi anche questo?!?

La morale è che in fase di progettazione funziona meglio un prototipo a bassa fedeltà.

Alcune risorse utili:
- High or low fidelity, paper or computer ("Low-fidelity prototypes have big advantages in cost and ease of iteration, and allow designers to focus on interaction design and information architecture")
- Balancing fidelity in prototyping ("fidelity has to be balanced and your clients should be told that high-fidelity is not the way to go if they want a well-designed product and a cost-effective design phase")
- High and low fidelity prototyping ("Low fidelity allows you to work rapidly and iterate quickly")
- Don't make the demo look done ("How 'done' something looks should match how 'done' something is.")

Mi piacerebbe anche conoscere la tua esperienza a proposito. Come funziona da te? Lavori in alta o bassa fedeltà? Cosa ne dicono i clienti? Come funziona al vostro interno? Quali sono i problemi?

In colpevole ritardo, segnalo un importante contributo italiano sul tema: Elementi teorici per la progettazione dei Social Network (pdf), documento redatto inizialmente da Gianandrea Giacoma e Davide Casali, rilasciato sotto licenza creative commons.

Anche se il documento è volutamente teorico, trovo degli spunti veramente interessanti, specie per quanto riguarda i gruppi sociali:

...possiamo pensare di integrare lo user centered design con una sorta di group centered design [...] si tratta infatti di identificare quali siano le tipologie di gruppi esistenti all'interno del social network e progettare in base alle necessità di ciascuno di questi [...] e di focalizzare una parte del design intorno alla semplificazione delle loro dinamiche.

Avevo trovato un'idea simile tempo fa, parlando di User Experience per applicazioni sociali:

Il "design sociale" è diverso dal fare design per il singolo individuo. Bisogna far interagire le persone, dargli modo di seguirsi a vicenda. Bisogna usare una sensibilità verso le funzioni sociali, piuttosto che verso le singole esigenze. -Rashmi Sinha

Direi che sta nascendo una nuova disciplina per progettare la user experience sociale, che per ora mi piace chiamare group-centered design.

Segnalo infine una specie di roadmap teorica per l'analisi di applicazioni sociali:

1. Identificare i Bisogni Funzionali autonomi e socialmente potenziati.
Questo punto è il più semplice perché dovrebbe essere in linea con gli scopi già esistenti del prodotto. La distinzione necessaria è quella fra bisogni funzionali autonomi e socialmente potenziati. Significa quindi definire quali funzionalità siano strettamente legate ad una dimensione sociale, in modo da esplicitarle con chiarezza.

2. Identificare come il servizio si inserisce nel Flusso di Attività Giornaliero delle persone.
Per fare questo è molto utile procedere tramite user case, secondo la metodologia dello user centered design. Così si esplicita quale sia il modo migliore per inserirsi nel flusso e come rendere questo processo operativamente semplice. La fase successiva consiste nel definire gli elementi di design che lo garantiscono.

3. Identificare le Pulsioni Aggreganti.
Seppure possa non essere semplice capire quali siano le motivazioni profonde che spingono le persone ad usare un determinato servizio, spesso è comunque possibile formulare delle ipotesi, a maggior ragione se si fa basandosi su osservazioni di utenti alle prese con lo strumento. Seppure quindi è molto probabile sbagliarsi quando si tenta di identificare tali pulsioni, si procede per prova ed errore in modo d'avere comunque un percorso indicativo. Riportando l'esempio delle pulsioni prima specificate: competizione, curiosità, appartenenza, narcisismo, evitamento della frustrazione, sublimazione. Si può partire da questi.

4. Identificare i Gruppi Sociali
Potremmo definire questo punto come 'group centered design': si tratta infatti di identificare quali siano le tipologie di gruppi esistenti all'interno del social network e progettare in base alle necessità di ciascuno di questi. Questo può essere fatto sia in fase di progettazione (con 'group cases', in modo analogo agli 'user cases'), sia analizzando gruppi realmente esistenti all'interno della rete sociale. L'osservazione diretta va comunque fatta nel tempo in modo che si possa adattare il servizio al mutare delle relazioni. Questo passo è importante perché i gruppi sociali sono relativamente semplici da identificarsi ed è possibile anche tradurli in elementi progettuali concreti, al contrario di elementi come le Pulsioni Aggreganti, che sono più astratti.

Insomma, la metodologia c'è, le pratiche anche (i group cases sono una gran bella idea!).

Ma non finisce qua, la ricerca resta aperta, grazie ad un wiki a cui tutti possono contribuire. Certo, fosse in inglese, avrebbe migliaia di contributors, mentre qui in Italia...

Infatti, la cosa strana è che questo documento ha avuto pochissimo eco nella blogosfera, che tuttavia si trastulla quotidianamente a parlare di social-cose. Peraltro, pochi di quei pochi che hanno segnalato il lavoro si sono presi la briga di commentarlo o leggerlo. C'è da pensarci su.

ps: sotto ritorsione segnalo che il link mi è stato passato da quel belin di Cristiano

Ho deciso di raccogliere un po' di pensieri in preparazione alla mia presentazione di Trento su SEO & IA. Da oggi alcuni post saranno espressamente sul tema SEO & IA.

Scarabocchiando su un foglio, mi è venuta fuori questa, che è un buon punto di partenza, almeno credo.



Tra utente e motore di ricerca, c'è una forte componente che chiamiamo SEM (search engine marketing). Questa non è da intendersi in senso stretto (leggasi "advertising"), ma è piuttosto un misto tra il posizionamento nella SERP (pagina dei risultati) e la scelta degli elementi caratterizzanti dei risultati (titolo, descrizione, parole chiave, ecc).

Per non complicare le cose, non considererò l'usabilità dei motori di ricerca, tema sul quale esiste un'ampia bibliografia in rete, dato che sono ormai interfacce consolidate.

Tra utente e sito, c'è ovviamente di mezzo l'esperienza utente e l'architettura delle informazioni. Mentre, tra sito e motore, c'è di mezzo la pratica dell'ottimizzazione per i motori, in arte SEO.

Ora, quello che cerco di capire è cosa lega tutte queste cose. E siccome ne sai più di me, perchè non mi dai una mano? Esiste qualcosa in mezzo? Cosa tiene unite tutte queste cose?