Progettare con la carta

Da qualche mese sto sperimentando con soddisfazione uno strumento diverso per quella fase di progettazione che segue la definizione della strategia online e precede la creazione di prototipi. Prendo un foglio di carta e realizzo a mano bozzetti che possono poi essere condivisi e valutati insieme al team di User Experience.

Nulla di nuovo o che non avessi mai provato, ma che avevo abbandonato troppo frettolosamente ritenendola una pratica poco professionale.

Mi hanno aiutato a cambiare idea due letture: Paper Prototyping di Carolyn Snyder e il più recente Prototyping scritto da Todd Zaki Warfel per i tipi di Rosenfeld Media. Entrambi i testi forniscono ottimi suggerimenti su come realizzare prototipi con la carta e il libro di Carolyn Snyder arriva anche a spiegare come utilizzare questi prototipi in veri e proprie sessioni di test di usabilità con gli utenti.

Non mi spingo quasi mai, con la carta, fino alla fase di creazione dei prototipi. La carta mi aiuta a fissare sottoforma di bozzetti (sketch) diverse idee di interfaccia e interazione che possono poi essere valutate, scartate, scelte insieme al team UX. Si tratta quindi di un approccio quantitativo, che mira a produrre in tempi molto brevi diversi bozzetti che possano poi essere analizzati dal team e soprattutto criticati senza la paura di aver mandato all’aria ore o giorni di lavoro. Ogni bozzetto non dovrebbe richiedere più di mezz’ora per la stesura.

Trovo l’uso della carta efficace anche lavorando con team remoti: basta uno scanner e in pochi minuti il bozzetto è condivisibile con il resto del mondo.

Normalmente non uso un foglio di carta bianca, ma mi faccio aiutare stampando dei semplici template che includono l’interfaccia del browser e qualche guida di supporto (per esempio le risoluzione più diffuse). In internet è possibile trovarne decine: personalmente mi trovo molto bene con il lavoro svolto da UIStencil (il template è disponibile in formato PDF).

I diversi bozzetti sono poi criticati insieme al resto del team UX, solitamente fissandoli a una parete o a una lavagna.

Zaki Warfel in Prototyping riassume bene come dovrebbe svolgersi questo processo.

PT001: Figure 2.1Diagram of the iterative design and critique process. Warfel, Todd Zaki. 2009. Prototyping: A Practitioner’s Guide. New York: Rosenfeld Media. http://www.rosenfeldmedia.com/books/prototyping/

Si tratta, come è facile vedere nello schema, di un processo iterativo.

Lo sketching (creazione dei bozzetti) è la parte generativa del processo, il cui obiettivo è proporre diverse idee senza prestare attenzione ai dettagli o alle inconsistenze (fast and furious).

Lo scopo della critica dei bozzetti è quello di trovare, tra le tante idee, la migliore. Chi ha realizzato il bozzetto ne elenca i punti di forza, i colleghi del team UX evidenziano lacune e richiedono approfondimenti. Questa fase dovrebbe durare pochi minuti, perché il dettaglio della proposta avviene nella fase di creazione dei prototipi vera e propria.

A questo punto, cioè per la creazione dei prototipi e per i testi di usabilità con gli utenti abbandono la carta. Preferisco infatti farmi aiutare da strumenti che permettano di simulare un po’ più nel dettaglio le transizioni tipiche di una pagina web, come le interazioni Ajax. In questo senso il mio strumento preferito è Axure RP: costoso, ma che permette di realizzare veri e propri prototipi piuttosto che wireframe, sui quali la carta vince ancora.

Così non va Delicious

Come tutti i web project manager degni di questo nome, ho incubi nei quali il progetto in corso si trasforma in una vera e propria odissea, spesso con le sembianze di una messa online in cui tutto quello che poteva è andato storto.

Questi incubi non si sono per fortuna mai del tutto trasformati in realtà (ho comunque commesso errori), ma purtroppo è quanto è accaduto con il rilascio del nuovo Delicious, il famoso sito di social boomarking di cui sono, o meglio ero, felice utente da anni.

Per i pochi che non lo sapessero, Delicious è un servizio acquisito nel 2005 da Yahoo! e, dopo anni di semi-abbandono, rilevato ad aprile di quest’anno da AVOS System, società dei fondatori di YouTube.

Già da tempo ero a conoscenza della cessione, avendo ricevuto e prontamente risposto a un’email che invitava ad accettare i termini del servizio e la politica di privacy del nuovo proprietario, pena la perdita di tutti i bookmark.

Quello che non mi sarei mai aspettato è di ritrovarmi, il 27 settembre, con un servizio completamente diverso da quello fino ad allora utilizzato, mancante delle caratteristiche basilari e pieno zeppo di errori di funzionamento tanto da sembrare, come ho scritto in Google +, una versione preliminare a uso interno.

Penso sia utile cercare di elencare gli errori principali commessi da AVOS nel proporre il servizio, perché questo tipo di supervisione è uno dei compiti principali del web project manager, anche nel caso di migrazione.

Errori di comunicazione

La prima cosa che mi sono chiesto, visto il risultato, è se fosse proprio necessario andare online con una nuova versione del servizio che stravolgeva la precedente. L’ho inizialmente vista come una mossa per dimostrare che quanto non è stato fatto da Yahoo! in 6 anni di proprietà per l’evoluzione del prodotto, la nuova società è stata in grado di farlo in pochi mesi.

Ho poi scoperto che non si è trattato di un vezzo, ma di una necessità, in quanto gran parte del codice di Delicious si basa su framework interni che Yahoo! non ha ceduto e questo ha richiesto una riscrittura significativa.

Mi sarebbe piaciuto saperlo in anticipo. Sono tornato per scrupolo a leggere l’email che invitava alla transizione, ma che si limita a recitare

To continue using Delicious, you must agree to let Yahoo! transfer your bookmarks and Delicious account information to AVOS

sottintendendo che l’operazione è immediata e si potrà continuare ad utilizzare Delicious, lo stesso Delicious di sempre.

Un po’ di trasparenza in più l’utente se la sarebbe meritata, magari anche solo per compiere un’esportazione di sicurezza, ma soprattutto per capire che avrebbe dovuto mettere in discussione la stabilità del prodotto (back to beta).

Errori di strategia

Siamo sicuri che gli utenti non aspettassero altro che l’introduzione degli “stack”, cioè una collezione di link costruita intorno a una tema comune? Ma, soprattutto, che a favore degli stack sacrificassero altre funzionalità prima presenti come i network di amici, i gruppi di tag, la cancellazione e la possibilità di rinominare i tag? La lista di funzionalità del vecchio sito ancora da migrare è parecchio corposa.

Errori di usabilità

Il problema di un sistema a folksonomy è che tende alla proliferazione di tag utilizzati poche volte. Per evitare in parte questa situazione è sufficiente che il tag venga completato dal sistema mentre si scrive, non fosse altro per evitare la generazione di termini sia al singolare sia al plurale. Ma questa semplice e ormai diffusa caratteristica non fa più parte del nuovo Delicious.

Nella vostra pagina compare l’elenco dei tag ordinati dai più utilizzati ai meno. Da qualche giorno è facile capirlo, perché a lato del tag è indicato il numero di volte che avete usato un tag, ma non era così al lancio. Ad aspettarvi c’era una lista, a prima vista disordinata, di tag, e per di più incompleta: non avevate modo di accedere ai tag meno usati.

Errori di programmazione

Dopo 5 minuti di navigazione nel nuovo sito mi sono accorto di un grave errore: mancava la navigazione su più pagine dei propri link una volta scelto un tag. Mi spiego meglio: se selezionavo “project management” tra i miei bookmark, il sistema mi restituiva la prima pagina con alcuni risultati… senza darmi modo di spostarmi ai meno recenti. Anche questa problematica è stata corretta dopo qualche giorno.

Ancora qualche giorno in più lo ha invece richiesto la correzione di problematiche sia relative alle API (impedendo, di fatto, a servizi terzi di accedere ai contenuti), sia agli RSS e alle procedure di esportazione. Trattandosi in tutti e 3 i casi di comunicazioni verso il mondo esterno, l’impressione di alcuni utenti è stata quella di trovarsi in una stanza in cui c’è un principio di incendio e le porte chiuse a chiave dall’esterno.

Errori di copywriting

Diversi utenti hanno scritto su Twitter di non riuscire più ad accedere alla lista dei propri bookmark. Dopo il panico iniziale, l’arcano è stato risolto. Nella nuova versione non si chiamano più “bookmark”, ma semplicemente “link”. Era necessario modificare questa convenzione?

P.S.: da qualche giorno Fucinaweb ha una pagina in Facebook, un esperimento, ma se avete modo passate per un saluto, vi trovate non solo l’elenco degli interventi di Fucinaweb quando sono pubblicati, ma anche link a risorse e articoli di interesse per chi si occupa di Project Management e User Experience.

Checklist per l’ultimo miglio

Come responsabile e project manager di progetti web ho aiutato nella messa online di più di 200 siti e applicazioni. Alcuni molti impegnativi e ad alto traffico, diversi di medie dimensioni, decine per piccole realtà.

Ogni progetto è diverso dagli altri, vuoi per le esigenze del cliente e le relazioni che si vengono a creare, vuoi per il progresso della tecnica, vuoi per le mutazioni che gli stessi team di lavoro subiscono negli anni.

Eppure, che il progetto sia piccolo o grande, quando il giorno per la messa online è arrivato nascono i patemi d’animo. Dobbiamo finire di verificare qualcosa? Quali sono i passi per portare “su” il progetto? È necessario ripetere qualche test?

Per rispondere a queste domande ho creato, nel corso degli anni, una checklist molto informale che io e il mio gruppo usiamo in questa circostanza, quando le cose da fare sono molte, il nervosismo è alle stelle, ma il tempo è poco.

Vorrei condividere con voi questa checklist. L’occasione è stata uno scambio di email con Miriam Bertoli sull’argomento “ultimo miglio”. Occasione che mi ha permesso da un lato di fare un po’ d’ordine tra gli appunti, dall’altro di inserire alcune considerazioni ed elementi suggeriti da Miriam.

La lista, come potete immaginare, è tutt’altro che completa e rappresenta un (timido) tentativo di organizzare gli ultimi giorni prima della messa online. Ho volutamente eliminato diversi elementi specifici per le realtà con cui lavoro o ho lavorato, perché inutili. Non vi si trovano inoltre, se non sparsi qua e là, espliciti riferimenti alle verifiche in fatto di accessibilità e usabilità, a cui solitamente dedico specifici documenti.

Siete anche invitati a indicarmi eventuali altri punti da tenere in considerazione.

Checklist per l’ultimo miglio – versione 1.0 (pdf, 52 Kbyte)