Avrei dovuto segnarmi il giorno, ma lo ritrovo spulciando il blog e-xtrategy e quello di Jacopo Romei: quindi sì, era un giorno di giugno, un pomeriggio normale durante una giornata di lavoro normale. Michele mi chiama in riunione per discutere di un nuovo progetto ed esordisce dicendo “da oggi dobbiamo lavorare in modo agile”.

Eh?

(grazie a Daniele Canonici per il disegno!)

È passato qualche mese, ho sbattuto il naso su questa parola diverse volte, ho fatto domande a Lorenzo, scritto a Jacopo, riflettuto su alcuni aspetti di questa metodologia di lavoro e… sono appena agli inizi. Mi ci vorrebbe un personal coach!

Però, qualcosa è cambiato. Dopo quella famosa riunione a sorpresa, per quello che mi riguarda e in questi pochi mesi, è cambiato tutto l’approccio al progetto grafico per un sito web. In generale, le fasi ora sono più o meno queste: 1. spiegazione delle storie precedentemente definite con il cliente insieme al team di lavoro; 2. veloce schizzo dell’homepage per individuare gli ingredienti principali; 3. wireframe delle pagine più critiche; 4. sviluppo grafico delle pagine wireframizzate. E poi riunioni, correzioni, riunioni…

Il giorno che avrò imparato qualcosa di più sui primi due punti, dovrò scriverci un post. Sui punti 3 e 4, invece, anche se sono passati pochi mesi, mi sento di poter spendere parole di pura soddisfazione. In breve, il wireframe sta cambiando il mio modo di pensare a un progetto web dal punto di vista funzionale, così come il sistema a griglia sta cambiando l’aspetto visuale.
Prima di lavorare con i wireframe, grafica e interfaccia per me erano un tutt’uno. Il wireframe era uno schizzo veloce che facevo su carta e poi passavo direttamente alla grafica… È curioso, perché il wireframe in realtà è come un uovo di Colombo, una soluzione tanto semplice e funzionale quanto utile per dialogare con gli sviluppatori e discutere per tempo gli aspetti critici di un’interfaccia. In un caso abbiamo potuto usarlo per discutere in modo molto costruttivo con il cliente e spero che possa ricapitare. Dal giorno in cui ho iniziato a progettare usando i wireframe, le pagine che produco in questo modo diventano un supporto alla grafica: mentre la grafica risolve l’aspetto visivo, il wireframe permette di valutare vari aspetti funzionali del sito e lo studio della navigazione; in più apre le porte a una discussione con gli sviluppatori, che possono decidere fin dall’inizio dove e come risolvere eventuali criticità.

Secondo alcuni il wireframe è solo il disegno a matita, che può essere fatto durante la riunione di riepilogo delle user stories, dopodiché si passa alla grafica. Io non la penso così. Il gruppo Information Architects, in questo articolo sul redesign per Internazionale lo chiama “sweet spot“: in italiano potremmo definirlo come dolce equilibrio tra gli elementi, anche se “dolce equilibrio” non è la traduzione letterale esatta. Da quando uso questo nuovo metodo di progettazione, mi viene spontaneo cercare quello “sweet spot” proprio durante la fase di wireframing, perché è in quel tipo di visualizzazione che vengono fuori i buchi, si avverte una mancanza, un’incomprensione, un’ambiguità nell’interfaccia.
Ci sono altri due aspetti impliciti nei wireframes, che mi piacciono in modo particolare, che vanno sfruttati e che non possono quindi risolveresi in uno schizzo al volo: la loro trasparenza e versatilità. Trasparenza perché mostrano lo scheletro della navigazione, senza grafica, che in questa fase potrebbe avere un effetto simile al fumo negli occhi; versatilità perché sono comprensibili, pur essendo nudi. Per ipotesi, si potrebbero usare per discutere non solo con il team, ma anche per fare test con gli utenti o per fare le prime valutazioni con il cliente.
In definitiva, il wireframe è lo strumento chiave, che può davvero semplificare le successive iterazioni di un progetto e dar vita a un’esperienza di navigazione decisamente più approfondita.

Il metodo che uso attualmente è questo:
schizzo a matita l’homepage ed eventualmente una o due pagine interne, mettendo a fuoco tutti gli elementi richiesti nelle storie e individuando il tipo di griglia più adatto.

Poi passo ai wireframe delle singole pagine: dato che ormai lavoro su pagine costruite tenendo conto di griglie e ritmo, mi preparo un file in Photoshop con le griglie visibili: questo file è il livello base per tutti i miei wireframe, che costruisco in Illustrator, in modo asciutto, senza grafica: solo contenuti e link, bottoni, etichette. Su questi wireframes aggiungo un livello con tutti i dubbi, note e ipotesi di funzionamento. Li discuto con il team di sviluppo e li correggo secondo tutte le valutazioni fatte insieme.

Infine, esporto il file Illustrator come psd e inizio a lavorare sulla grafica.

Forse questi passaggi Photoshop-Illustrator-Photoshop possono sembrare un po’ macchinosi, ma per ora mi ci trovo bene. Nel frattempo, sul sito http://wireframes.linowski.ca, ho trovato molte risorse per cominciare a ragionare la progettazione usando i wireframes. Ho iniziato a provare uno dei tool suggeriti, ma lo trovo un po’ legnoso. Ci proverò ancora, perché vorrei trovare un modo più rapido di produrre il wireframe. In fase di wireframing, credo di poter evitare di pensare alle griglie, così da recuperare tempo e freschezza durante la fase creativa, cioè il momento in cui passo a vestire di grafica il progetto.

Segnalo un ulteriore approfondimento in questa slide di Alberto Mucignat che giustamente definisce il wireframe come tool definitivo per la progettazione di una user experience.