Alberto Mucignat - WebDev

Cosa togliere (less is more)

nospam@example.com (Alberto) — Thu, 17 Jul 2008 13:22:38 -0700

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

Scorecards per definire le priorità

nospam@example.com (Alberto) — Wed, 16 Jul 2008 15:50:01 -0700

Flow Interactive ha scritto un post su come raccogliere le priorità di un progetto web con le Scorecards.

Il post è molto interessante e, tra le altre cose, utilizzano la matrice di priorità che ho descritto in un precedente post.

Design Epicentrico

nospam@example.com (Alberto) — Thu, 10 Jul 2008 10:18:12 -0700

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.

Internet Explorer e i costi della compatibilità browser

nospam@example.com (Alberto) — Fri, 04 Jul 2008 17:02:05 -0700

In questi giorni, mentre esce IE8, c'è chi sta abbandonando il supporto per IE6, che peraltro è usato ancora molto rispetto a IE7. È il caso di 37 signals:

[...] IE 6 can't provide the same web experience that modern browsers can. Continued support of IE 6 means that we can't optimize our interfaces or provide an enhanced customer experience in our apps.Supporting IE 6 means slower progress, less progress, and, in some places, no progress.

Di recente ragionavamo sul fatto che mentre per Firefox e Safari i costi della compatibilità tra versione 2 e 3 possono considerarsi relativamente bassi, pensare di mantenere la compatibilità su 3 browser di casa Redmond equivale a un bagno di sangue (un 9a in termini arrampicatori).

A proposito negli ultimi giorni anche Yahoo ha aggiornato il proprio modello di supporto ai vari browser.

Form in linguaggio naturale

nospam@example.com (Alberto) — Thu, 26 Jun 2008 18:04:04 -0700

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.

Definire le priorità di un progetto

nospam@example.com (Alberto) — Tue, 13 May 2008 16:52:30 -0700

Negli ultimi giorni sto lavorando a un progetto con Jacopo e stiamo applicando un processo di sviluppo totalmente agile. Abbiamo discusso parecchio su come pianificare le priorità delle cose da fare e abbiamo sostanzialmente evidenziato due modelli che voglio condividere.

In questo modello, vengono fatte per prime le funzionalità ad alto valore e basso effort. Successivamente le funzionalità ad alto valore ed alto effort e per ultime le funzionalità a basso valore e basso effort.

E' utile quando si vogliono rilasciare velocemente delle nuove funzionalità, ma ha il rischio che funzionalità particolarmente complicate (ad alto effort, quindi anche a maggior rischio) comportino problemi quando è troppo tardi per porvi rimedio.

In realtà è più sicuro avere il seguente approccio.

Facendo prima le funzionalità ad alto valore ed alto effort, si scoprono subito i problemi e si lasciano le funzionalità a basso effort per tutta la seconda parte della realizzazione. Come dire: le rogne prima le affronti, meglio è.

Da notare che in entrambi i casi le funzionalità a basso valore e alto effort non dovrebbero essere fatte: non sono essenziali e costano tanto. Un buon motivo che aiuta il cliente a scegliere cosa non fare.

Può sembrare un modello semplice, ma spesso è complicato stabilire le priorità di un progetto e fare una valutazione dell'effort per ogni singola funzionalità.

La mancanza di tempo è la scusa più comune, una giustificazione più che altro verso se stessi. Con le metodologie agili esiste una facile pratica chiamata planning game che aiuta molto.

In alternativa, si rischia di considerare che tutto sia importante e tutto sia facile, mentre non è mai così.

Comunque questo è solo il primo macro-livello del modello di pianificazione che stiamo costruendo, ma fornisce le basi per una discussione iniziale.

Tu cosa ne pensi? Hai mai pianificato il lavoro sulla base del valore e del costo delle feature? Che problemi/benefit hai avuto?

Slide dell'IA Summit 08 americano e video del FOWD

nospam@example.com (Alberto) — Tue, 29 Apr 2008 17:57:57 -0700

Segnalo che sono online le slide del summit americano di architettura dell'informazione. Non sono ancora riuscito a darci un'occhiata, ma mi pare ci sia parecchia carne al fuoco e anche delle novità interessanti.

Andrea c'è stato ed è tornato con un sacco di idee per il summit italiano, quindi tieniti libero per novembre, che abbiamo in serbo numerose sorprese. Tipo si vocifera che avremo degli ospiti internazionali pazzeschi. No, Obama no. Neanche Al Gore. Surprise!

Poco fa invece sono usciti i video del FOWD di cui ho parlato pochi giorni fa. Worth a look!

Swimlanes: deliverable da collezione

nospam@example.com (Alberto) — Mon, 28 Apr 2008 19:47:00 -0700

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

Prima gli utenti (Last.fm blues)

nospam@example.com (Alberto) — Wed, 23 Apr 2008 18:29:09 -0700

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

Web giocoso e Bruno Munari

nospam@example.com (Alberto) — Mon, 07 Apr 2008 19:14:32 -0700

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.

Interfacce per lo storytelling

nospam@example.com (Alberto) — Wed, 02 Apr 2008 15:02:21 -0700

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?

Utenti o personaggi?

nospam@example.com (Alberto) — Mon, 03 Mar 2008 14:25:05 -0800

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

Conferenze in Italia 2008

nospam@example.com (Alberto) — Thu, 21 Feb 2008 10:30:29 -0800

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?

Homepage e potere di contrattazione

nospam@example.com (Alberto) — Thu, 07 Feb 2008 09:53:04 -0800

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.

Card sorting: cos'è e come funziona

nospam@example.com (Alberto) — Thu, 17 Jan 2008 15:22:14 -0800

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.