Alberto Mucignat

“La perfezione non si ottiene quando non c'è più nulla da aggiungere, bensì quando non c'è più nulla da togliere" -Antoine de Saint Exupery

"Sbarazzati della metà delle parole di ogni pagina, e poi sbarazzati della metà di quello che resta" -Steve Krug, Terza legge di Krug sull'usabilità

"Less is more" -Unknown

Togliere è un'attività fondamentale in ogni processo creativo.

La dimostrazione empirica è che da quando faccio test sugli utenti, mi accorgo che spesso non vogliono molte delle cose che ci vengono in mente.

Quindi, sintetizzando.

"Lavorare con gli utenti serve soprattutto a capire cosa togliere" -Alberto Mucignat

In Google Calendar io trovo molto utili i reminder. In pratica, esiste la possibilità di farsi inviare una mail, un sms (!) e di aprire un popup a una certa distanza dall'evento.

Il menù di selezione consente di scegliere a quale distanza temporale ricevere il reminder, con una vasta scelta di numerilli:



Backpack invece per i reminder utilizza il linguaggio naturale che è molto più semplice da comprendere:



"Later today" non è una cifra precisa, ma è quello che ci diciamo solitamente parlando tra di noi: "me lo ricordi più tardi?".

A piccoli passetti il linguaggio naturale sta prendendo piede sul web, perchè il web dev'essere più vicino alle persone, io credo.

Probabilmente, il linguaggio naturale aumenta la comprensione delle applicazioni web da parte delle persone, migliorando l'usabilità nel suo complesso.

Qualcun'altro ha altri esempi da consigliarmi? Mi interessa molto.

Segnalo che sono aperte le iscrizioni ai workshop del dconstruct (ci sono ancora pochi posti: sbrigatevi!).

Le iscrizioni della conferenza apriranno invece il 24 Giugno, quindi save the date e occhio che i ticket vanno a ruba in poche ore. Io mi sono iscritto ai workshop, quindi se lo fate, sentiamoci che poi ci becchiamo.

Sono aperte anche le iscrizioni a EuroIA, che quest'anno si terrà ad Amsterdam.

All'IA Summit americano, quelli di nForm hanno presentato un deliverable chiamato Swimlanes (ringrazio anche a nome di tutti gli ex nuotatori) e poi hanno anche spiegato meglio di cosa si tratta. Complimenti a loro che hanno così vinto il premio "Wall of Deliverable".

In pratica, si tratta di riunire in un unico deliverable una serie di documentazioni, in maniera che possa servire per la comunicazione a tutti i livelli di un'azienda. Per me è veramente un documento interessante e ringrazio gli amici di nForm per averlo condiviso. Ognuno poi ne faccia l'uso che vuole o lo modifichi a piacimento.



Ultima cosa: mi piacerebbe avere un angolo per votare il deliverable dell'anno anche al prossimo IA Summit italiano, per cui pingo i ragazzi del board su questo

"Are you creating something people actually want to use?" -Hannah Donovan

Al FOWD di Londra ho partecipato a un paio di workshop. Uno di questi con Hannah Donovan, direttore creativo di Last.fm.

Hannah ci ha spiegato i processi interni di design e di risoluzione dei conflitti tra le varie menti pensanti di last.fm. In breve: il design viene realizzato con i personaggi, che vengono appesi al muro e ognuno fa riferimento a loro quando si progettano o realizzano nuove funzionalità.

Quando c'è una nuova idea nell'aria, c'è una check list da utilizzare (la posto appena riesco ad avere le slide), ma prima di tutto viene verificato se c'è un personaggio che necessita della nuova funzionalità.

I personaggi sono basati su dati reali provenienti dalla loro base dati (20 milioni di utenti, a quanto pare) e quindi sono delle profilazioni su dati reali, altamente affidabili.

A questo punto, siccome tutti quelli che lavorano a Last.fm sono heavy users del loro sito, pensando a quello che spesso succede con i miei clienti, ho posto la domanda: come fate a bilanciare le vostre idee con i bisogni degli utenti?

Cioè: se a qualcuno di voi viene in mente una nuova funzionalità, chi decide se farla o meno visto che siete voi stessi utenti del sito?

Risposta di Hannah (da incidere sul marmo): valgono sempre e solo i nostri utenti. Se una cosa ha senso per loro allora viene pianificata, altrimenti semplicemente non la facciamo.

Il problema infatti è semplice. Per quanto tu possa essere l'inventore di un'applicazione web:

1. tu sei troppo coinvolto per poter decidere unilateralmente cosa serve ai tuoi utenti
2. tu stai progettando per l'utente finale, non per te

Ecco, a futura memoria di quelli che mi dicono "io conosco i miei utenti", senza avermi mai dato documentazione. Imparate la lezione, prima che sia troppo tardi.

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 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.

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?