Alberto Mucignat

Qualche settimana fa ho iniziato a collaborare con gli amici di Ideato a un progetto intranet.



Jacopo ha dettagliatamente descritto i primi due giorni di lavoro con il team e gli utenti.

In particolare, per favorire la scoperta delle User Stories, abbiamo adottato un approccio che prevede, assieme agli utenti/stakeholders:
- la scoperta dello scenario tipo di lavoro
- la definizione dei vari "step" dello scenario
- la generazione delle user stories a partire da ogni step dello scenario

Questo approccio ha favorito la comunicazione tra team di sviluppo e utenti, garantendo la copertura di tutti gli aspetti del sistema.

“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

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.

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.

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.

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.

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?

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!

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.