Il report di velocità di GA è sicuramente importante per capire quali pagine hanno dei problemi, ma per un’analisi più approfondita esistono anche altri tool, tra cui il plugin Yahoo!Slow (che ho usato spesso) e Google Page Speed Service (mai utilizzato, ma sembra interessante).

Da leggere per capire come lavora sul design un’aziendina che ha 300 milioni di utenti.

Riepilogo i punti salienti (tradotti da me):

1. I designer sono coinvolti sul prodotto dall’inizio alla fine
2. Il lavoro viene condiviso subito e con rapidità, tra i vari team e con gli utenti
3. I designer lavorano principalmete in codice (html/css e un pizzico di php)
4. Non si affezionano troppo al lavoro: il software cambia continuamente.

Prima lezione: velocità e iterazione, in un’azienda con 1000 dipendenti. Corollario: non regge la scusa per cui la vostra azienda è troppo grande per lavorare in maniera agile.

Interessante per me anche il punto 3: sebbene sia un sostenitore dei wireframe, per le startup o per i team interni è forse conveniente (e più naturale) lavorare sul design direttamente in codice. Si risparmia tempo e si ha la possibilità di testare su reali contenuti (cosa che di solito una design agency esterna ha difficoltà a fare).

Forse la cosa più strana alla fine sono i numeri: 25 designer su 1000 dipendenti. Sembrano pochi, solo il 2,5%: ma quali altre aziende che fanno business su web hanno questa % di designer? Dico seriamente, eh.

Mi colpisce particolarmente l’ultima parte, dove si illustra il funzionamento dello strumento di pubblicazione, la vera killer application di Facebook.

È una sorta di helper intuitivo e semplice da capire, costruito attorno ad uno scenario di utilizzo dell’utente:

• pubblichi un contenuto
• appare nel tuo profilo
• appare ai tuoi amici.

Un’efficace comunicazione visiva per i social network, dove è sempre difficile comunicare agli utenti “come funziona il sistema”.

Questo tipo di comunicazione si può deve usare anche in fase di progettazione, per comunicare con il cliente, il team di sviluppo, etc.

UPDATE (de noantri)

Mi ero ricordato che anche Bol aveva fatto qualcosa del genere tempo fa e adesso ho ritrovato il link. Qualche tempo prima avevano anche chiesto agli utenti “quale colore preferite?”.

Purtroppo sono abbastanza scettico su questo approccio, ma il vero problema è che ancora il design viene inteso come “puro stile grafico”, mentre in realtà è saper mettere assieme informanzioni, elementi visuali, interazioni e, infine, visual design.

Ecco un altro post che parla del fatto che non sempre le sitemap bastano, quando non funzionano. E presenta le due alternative naturali: concept model e screen flow.

Personalmente credo che sitemap e screen flow siano necessarie in ogni caso, anche perchè si completano a vicenda. Per questo spesso vengono usate assieme.

In pratica, mentre la sitemap documenta l‘architettura dell’informazione, lo screen flow documenta l’interaction design tra le pagine.

I concept model invece sono appunto una “variante trasversale” che documenta il “sistema”, le relazioni tra gli oggetti, le azioni, etc.

Ad ogni modo, mi pare che ci sia una certa convergenza verso questi 3 deliverable, con la concept map che sta diventando sempre più importante per i sistemi sempre più complessi che si stanno progettando in questi anni (social network in primis).

È interessante vedere come il percorso che utilizziamo a Doralab è praticamente lo stesso, anche se qui vengono rappresentati solo i vari deliverable e non le attività.

Rispetto alle nostre attivitià mancano i report di usabilità, che sono un deliverable fondamentale in base alla mia esperienza.

Manca anche la parte di visual design, che spesso viene considerata come un’attività a parte (anche dal sottoscritto) e invece dobbiamo trovare il modo di integrarla meglio all’interno del processo.

Poi ci sono altri deliverable che invece mi pare si stiano consolidando, come per esempio le concept map di cui ho già scritto qualcosa.

Il 75% della revisione è eliminazione di parole già scritte, il 25% è il miglioramento di quelle che sono rimaste.

In queste percentuali non l’avevo mai realizzato, ma a pensarci bene sono stime realistiche.

Btw, anche il resto del libro pare molto interessante.

Per Jared sia le mollichine che le mappe del sito sono delle “scappatoie” (“cop-out” in inglese), per gli utenti, ma specialmente per i progettisti:

A ‘design cop-out’ is when a designer works on treating a symptom instead of putting resources into solving the root problem. It’s choosing a quick fix over solving what could be a wicked problem.

Infatti, il problema non è nella sitemap, ma nel perchè l’utente ci arriva:

By itself, “site map” doesn’t give off scent — the clues that tell the user if the link will lead them to their desired content. It’s only in the absence of anything else that gives off scent that users start to think it’s a likely help. Therefore, the real problem is the pages that lead to the site map are missing important scent. Fixing the scent issues on those pages will eliminate the need for the site map. However, deciding to improve the site map doesn’t fix the scent problem — it’s only a cop-out.

Anche sulle breadcrumbs il problema è sempre il “profumo dell’informazione” e gli obiettivi degli utenti:

the user ignores them until they get to a page that isn’t quite what they wanted. They discover the trail of links and click on the one most likely to contain the correct path to what they were originally seeking. Because they can jump more than one level, they can view enough of the hierarchy to let them pick up better scent to the content they’re seeking.

Allora, le mollichine sono importanti o no? Quanto sforzo dobbiamo mettere nel lavorare sulle breadcrumbs?

if nobody is using them, then why spend the effort to build them? And, if there is enough demand to justify working on them, one has to ask where that demand is coming from? In the case of breadcrumbs, why are so many people lost on the site?

Di breadcrumbs ho parlato circa una volta l’anno negli ultimi anni, perchè è sempre stato un “problema” che mi ha appassionato. Cioè mi son sempre chiesto se veramente servono e non ne sono ancora convinto nonostante Giacobino Nielsen dica che sono importanti.

Personalmente continuo a credere che le breadcrumbs siano un aiuto alla navigazione per far trovare all’utente quello che cerca, nel momento in cui non lo trova. Cioè, la penso come Jared: il problema è che l’utente non trova quello che cerca, quindi si attacca a tutto, perfino alle mollichine, se gli fanno percepire un’avvicinamento all’obiettivo.

Ma insomma, le sitemaps e le breadcrumbs servono?

Idealmente, un sito progettato partendo da un’approfondita analisi degli utenti non dovrebbe avere bisogno della sitemap e delle breadcrumbs.

Nella mia esperienza, per risolvere i problemi di navigazione bisogna infatti partire più a monte: conoscere e analizzare i bisogni e le necessità degli utenti sono attività necessarie e fondamentali per impostare una corretta architettura dell’informazione.

Dopo aver sviluppato personaggi e scenari, l’idea è di raccogliere in un foglio excel tutti i bisogni degli utenti. Successivamente, accanto ai singoli bisogni, si devono scrivere gli obiettivi business che vengono soddisfatti. Infine, per ogni riga si possono proporre le funzionalità e le metriche di successo.

Per ultima cosa avviene la definizione della priorità, che a questo punto viene mediata naturalmente tra utenti e cliente.

Al di là della semplicità dello strumento, è un pratico esempio di come mappare bisogni e obiettivi business. In realtà, ricorda vagamente le fasi di allineamento tra i modelli mentali e i contenuti/servizi del sito (vedi Mental Models di Indi Young).

Comunque, ormai è chiaro che la definizione delle priorità non dipende più (solo) dal cliente, ma è un lavoro che va fatto considerando sia gli utenti che i clienti.

Ho anche un’altra osservazione importante: appare sempre più evidente come la definizione delle funzionalità e della loro priorità discenda direttamente dall’attività di user research, che va quindi pianificata e organizzata a monte di ogni progetto.

Il fatto è che non esiste un unico deliverable per i progetti web. Per lo più si usano sitemap, flowchart, wireframe, etc, ma nessuno di questi documenti “vale” per tutta la durata del lavoro di user experience design.

Solitamente la sitemap (mappa del sito) è quello che viene considerato come “base per il lavoro” per un sito editoriale. Ma chi si è occupato di community o siti di servizio sa che la sitemap documenta ben poco le interazioni e i percorsi degli utenti.

Insomma, i concept model servono a colmare quel gap che ogni designer percepisce mentre lavora a un prodotto web mediamente complesso.

Inoltre, i concept model possono essere utilizzati per tutta la durata del processo, perchè nascono in fase di strategia e ricerca, continuando ad evolversi iterativamente durante le fasi di design.

In più documentano i soggetti e le azioni, anzichè le pagine, garantendone l’uso come strumento per lo sviluppo dell’interaction design.

Da guardare la presentazione di Dan Brown a Interaction08 (qui le slide) dove spiega come funzionano e come si usano i concept models. Per un maggior approfondimento consiglio di leggere il suo libro Communicating Design.

Sarebbe da provare (lo dico anche per i miei partners che saranno sicuramente in ascolto).

Qualcuno lo conosce? Impressioni?

(via Gianf)