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

Getting Real è una bella lettura estiva. Il libro è uscito da un sacco di tempo, ma vale la pena rileggerlo perchè è sintetico, essenziale, zen.

E poi aiuta a mantenere i piedi per terra. Leggetelo anche a pezzi, ma leggetelo.

Nella sua semplicità, un capitolo fondamentale è Interface Design, dove si spiegano pochi chiari concetti che dovrebbero essere alla base della progettazione di ogni servizio web.

A mo' di mantra riporto i punti più importanti:

- Epicentric Design: iniziare (e focalizzare) il design a partire dal core della pagina. Ne parlo da diversi anni anche in termini di page paradigm.

- Context over Consistency: in ogni pagina ci vanno le informazioni giuste, sulla base di quello che l'utente può decidere di voler fare. Un esempio classico sono i menù: non è detto che uno stesso menù debba apparire in ogni pagina del sito, ma questa è invece una convenzione comune nel costruire siti web.

- Three state solution: disegnare le pagine web pensandole nei 3 stati: regular, error, blank. In particolare lo stato blank viene spesso tralasciato (anche dal sottoscritto, sigh). Si tratta di pensare la pagina a come appare la prima volta che un utente la visita. La prima impressione di un'applicazione web è spesso la cosa più importante (remember: "you never get a second chance").

- Get defensive: migliorare l'esperienza dell'utente in caso di errore o altri problemi. Questa regoletta è stata poi ampliata per bene dagli autori nel libro Defensive Design.

- Copywriting is Interface Design: per finire in bellezza, se non fai copywriting, non stai facendo design. Fondamentale.

In queste regole manca forse qualche accento in più sull'utente, sugli scenari di utilizzo e sui task, che sono fondamentali per stabilire quali cose siano centrali e funzionali a una data pagina. Ma per il resto, lo trovo formidabile.

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

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.

Secondo Todd Warfel, il primo obiettivo di un prototipo è di comunicare. Mi viene in mente che anche negli altri casi si tratta proprio di artefatti per la comunicazione.

Personalmente credo che non si possa dimenticare l'utilizzo del prototipo (anche a bassa fedeltà) per testare la reazione degli utenti.

In ogni caso, Todd sta scrivendo un libro sui prototipi per la Rosenfeld Media, che dev'essere molto interessante e dove appare anche un capitolo dedicato al testing.

La Bocconi ha lanciato una ricerca per capire perchè il software in Italia non va:

L'Università Bocconi, in collaborazione con 01net e Linea EDP, sta svolgendo una ricerca che ha l'obiettivo di analizzare e di individuare modalità sostenibili per fare crescere in Italia l'ecosistema del software, inteso come l'insieme delle aziende che offrono software e servizi informatici e delle aziende che utilizzano il software come leva competitiva.

La ricerca vuole approfondire le motivazioni per cui il settore da anni non cresce in Italia come invece accade in altri Paesi europei, laddove molti studi confermano che la mancata crescita della produttività italiana, causa della perdita di competitività delle nostre imprese sui mercati internazionali, è dovuta soprattutto allo scarso utilizzo dell'ICT da parte delle imprese del nostro Paese.

Nel mio piccolo azzardo una risposta: il mercato ICT italiano e l'utilizzo del software in Italia non crescono perchè spesso il software non funziona!

La prova è aver visto le aziende che comprano software passare la maggior parte del loro tempo al telefono con il customer care o a risolvere problemi (del software, ma anche del pc, dei formati dei file, della stampante, ecc), piuttosto che ad avere una vita semplificata dal software.

Il valore di un software, oggi, non è nella tecnologia, ma nella sua facilità d'uso. Vorrei dire "usabilità", perchè oggi l'utente dovrebbe essere al centro del processo di creazione di un software. E non viceversa.

Ecco, quindi, che lo "scarso utilizzo dell'ICT da parte delle imprese italiane" forse è più una conseguenza, che una causa.

Cioè, più che pensare alla percezione del software, in tutto il resto del mondo si sta cambiando il modo di sviluppare software (si pensi al redesign di Office 2007).

All'estero poi si parla sempre di più di User Centered Design e di User Experience per descrivere il nuovo processo di creazione del software.

Anzi del "prodotto". Che non è più ormai solo un pezzo di codice, ma la sapiente unione di tecnologia, design e -sediovuole- innovazione.