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.

Cito il maestro:

Cerco sempre di scrivere secondo il principio dell’iceberg: i sette ottavi di ogni parte visibile sono sempre sommersi.
Tutto quel che conosco è materiale che posso eliminare, lasciare sott’acqua, così il mio iceberg sarà sempre più solido. L’ importante è quel che non si vede. Ma se uno scrittore omette qualcosa perchè ne è all’oscuro, allora le lacune si noteranno.

Genio d’un Hemingway: puoi togliere solo ciò che conosci bene, altrimenti si capisce che non scrivi qualcosa perchè non la sai. Raffinatissimo.

La sicurezza per riuscire a togliere è data dalla consapevolezza che, per quanto poco è rimasto, sotto sotto c’è un solido iceberg di conoscenza.

Corollario applicato al web design: per praticare l’arte del less is more è necessario conoscere molto bene e in profondità quello di cui si scrive o di cui si progetta. Se non abbiamo solide basi, rischiamo di togliere senza riuscire a dare qualcosa in più.

Corollario finale: più sai, più le tue basi sono solide, più riesci a togliere.

Fino a scrivere un libro di poche righe, o raccontare storie brevi.

Come proponeva Calvino nelle Lezioni americane. Libro importante per me, che Luisa ha opportunamente e sapientemente accostato all’attività di scrittura per il web.

E così chiudo il mio personalissimo cerchio. Pazzesco.

ps: nello stesso articolo, manco a farlo apposta, una citazione di Marquez:

Un bravo scrittore non si riconosce tanto da quello che pubblica quanto da quello che butta nel cestino della carta.

In english
I really don’t get the point about the new so-called “Account management” page on GA. It’s confusing me with many details and definitely not a good design concept.

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.

Peraltro ho scoperto grazie al suo blog perle inarrivabili quali i Gnognosaurs e le maiute tal friul, che rilanciano nel mondo il messaggio furlan: “Make frico not war”.

Il friulano lo capisco abbastanza (almeno supero il test), ma l’ho parlato raramente, solo da piccolo, con il nonno o a scuola. Il Folpo, ovviamente, dialetto friulano di Cordenons.

Mi piace un sacco leggerlo a voce alta, poesie per lo più. Lo facevo alle elementari e lo faccio ancora oggi agli amici che rimangono incantati dai versi di Pasolini e poi mi dicono “ma che vor dì?”.

È una lingua bellissima, che i friulani chiamano teneramente la marilenghe, parola dal suono dolcissimo.

Insomma, oggi mi è scesa la lacrimuccia, perchè a Dree gli devo sicuramente un tai di chel bon. Anche perchè stasera mi ha fatto venire una voglia di frico e di brovada…

Un grues mandi ai letôrs che jo o definìs “normâi”, che il blog al è massût par lôr: chei che magari no comentin par la ataviche pore di “no savê scrivi”. Chei che chest blog al à contribuît a fâi scuvierzi tantis robis sul furlan che no savevin e che cheste lenghe e pues jessi trancuilamentri doprade te modernitât.
Anzit: lis ideis furlanistis a si dimostrin puntualmentri ches plui indevant rispiet a la mentalitât provincialote dai sorestans locâi, no nome politics.

Vonde. Si viodin, Dree. Mandi!

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.

Happiness only real when shared -Christopher McCandless

Ieri sera ho visto Into the wild. Film bellissimo, da vedere al cinema. Da vedere in ogni caso, specie se te lo sei perso.

Di Krakauer -l’autore da cui Sean Penn ha tratto “Into the wild”- avevo letto solo Aria sottile, una sua storia vera sulla più grande tragedia dell’Everest. Ottimo regalo di natale, peraltro.

Dopo il film però mi è venuto in mente Messner. In uno dei suoi ultimi libri, Messner dice che i propri limiti bisogna cercare di superarli ogni volta un pochino di più, ma senza voler andare subito troppo oltre.

Più o meno come un saltatore in alto sposta l’asticella di pochissimi centrimetri ogni volta che tenta un record. Lavorare sul limite, non pretendere di superarlo di brutto (uno come Bolt forse è un’eccezione, ma non se ne va a spasso in mezzo agli orsi polari).

Ok, vengo al dunque. Per me c’è un momento particolare in cui mi accorgo di aver superato il limite: sono in mezzo alla natura selvaggia e a un certo punto mi prende un attacco di panico-euforia. So che da quel momento in poi sarò “solo” e questo un po’ mi eccita e un po’ mi spaventa.

Alcune persone, quelle che mi accompagnano in montagna, conoscono bene questo mio “momento” che di solito accade poco dopo l’inizio di una via, appena passato il primo “punto critico”.

Superato questo momento, potrei scalare il K2 (si fa per dire), perchè mi sono appena lasciato alle spalle un limite. Di più: mi sto lasciando dietro un mondo, un sistema di parametri conosciuti, noti, sicuri. E d’ora in poi sto andando incontro all’ignoto, da solo.

Nel film di Penn questo momento probabilmente accade quando il protagonista supera il fiume. Il fiume è un limite -che si rivelerà fatale- oltre il quale c’è l’ignoto. Da lì in poi te la devi cavare da solo, ragazzo.

Certo, non è solo quello che c’è oltre quel limite, bensì cosa ti lasci indietro.

Questo è il punto. Non le terre selvagge, ma quel punto di non ritorno, dove inizi ad affrontare l’ignoto, con il peso di quello che ti sei lasciato alle spalle.

Non so se c’è un punto a cui sono arrivato con questo mio post, ma non importa. Vediamo se mi riesce di chiudere con “leggerezza”.

Credo che la voglia di scappare da un paese con ventimila abitanti vuol dire che hai voglia di scappare da te stesso, e da te stesso non ci scappi nemmeno se sei Eddie Merckx. -Radio Freccia, Ligabue

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

Qualcuno lo conosce? Impressioni?

(via Gianf)

Al di là di tutte le considerazioni sul proliferare dei SN, conoscendo le persone dietro, secondo me promette bene.

Molto interessante a livello di scambio di idee e pratiche, nonchè per dubbi, fare networking, cercare lavoro all’estero, etc.

Enjoy!

ps: dimenticavo che di recente Andrea Resmini è entrato nel Board of Advisors di IAI. Oltre alla buona notizia, credo sia il coronamento di un lavoro di promozione e networking che Andrea porta avanti da anni con impegno e costanza. Quindi complimenti e buon lavoro!

In pratica, se hai pochi soldi, anzichè fare user research per sviluppare i personaggi, concentrati sulle user stories:

If the money is not available I would recommend concentrating on user stories, scenarios that a user may find themselves when using the website and interacting with your product.

Su questo argomento (personaggi -> scenari -> user stories), dopo il mio intervento al Romecamp di sabato, ho avuto modo di confrontarmi con Stefano.

La mia posizione è che in linea teorica bisognerebbe prima conoscere i personaggi e gli scenari d’uso. Da questi ultimi si dovrebbero derivare le user stories.

Purtroppo non sempre il cliente accetta di investire in una fase di user research. In questo caso, il mio consiglio è di tentare di evidenziare comunque gli scenari d’uso e di produrre delle user stories coerenti, che serviranno da base per il lavoro di design e sviluppo (agile, si presume).