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.

A ogni cosa il suo nome

Mi trovo dal cliente con l’art director per illustrare la tavole grafiche del progetto. Ha apportato le ultime modifiche ieri sera e non siamo riusciti a rivederle insieme. Apre il portatile e fa doppio clic su figo.psd.

Il collega che si occupa del frontend manda un’email con le ennesime correzioni richieste dall’azienda che si occuperà dell’integrazione. Una volta decompresso il file, nel desktop compare la cartella che_palle.

Sono due esempi, ma potrei tranquillamente continuare per ore e ore senza mai ripetermi. Ok_bis_def.zipaltra_prova.psd, oggi_non_ho_idee.png: ho a disposizione un’intera letteratura di nomi insignificanti e imbarazzanti.

Stufo di passare le giornate a rinominare i file e inviarli ai diversi attori (ammesso che fossi ancora in tempo) ho messo a punto un semplice sistema di nomenclatura che cerco di applicare e  fare applicare.

Il consiglio è quello di partire già dalla stesura dei wireframe, per proseguire nel corso della progettazione grafica fino ad arrivare allo sviluppo delle pagine HTML. Ogni wireframe va correttamente nominato prima di consegnarlo all’art director, che solitamente è ben felice di conservare la creatività per altri compiti.

Ho provato in questi anni diversi tipi di nomenclature, ma quella che si è rilevata più efficace nasce da un compromesso tra nome dal contenuto altamente informativo e semplicità di applicazione della regola.

Un tipico esempio di nomenclatura potrebbe essere il seguente:

  • HP010
  • PR010
  • PA010

I primi due caratteri indicano la sezione del sito a cui la pagina fa riferimento (in questo caso HP sta per homepage, PR per scheda prodotto e PA per processo d’acquisto), mentre il numero indica il progressivo della pagina all’interno della sezione (HP010 potrebbe essere l’homepage generale, HP020 la declinazione per il periodo natalizio, ecc.). Utilizzo le decine e non le unità per rappresentare i progressivi perché, se ci accorgiamo di aver dimenticato un template che “logicamente” va inserito tra altri due, lo possiamo includere (ad esempio HP015).

Come è facile vedere la regola è banale, ma proprio per questo altrettanto semplice da applicare. A me ha risparmiato molto tempo, ma soprattutto ha permesso di verificare a colpo d’occhio se i template realizzati erano, in ogni fase, tutti quelli previsti.

P.S.: se, come me, avete il pallino delle nomenclature, vi rimando a un articolo che ho scritto quasi 10 anni fa (il tempo passa) e che affronta tra le altre cose il tema dei nomi da dare e non dare alle regole CSS: Chi ha paura di Xhtml 8?

L’usabilità dei progetti opensource

Un intervento sul blog di Experientia lamenta, non senza ragione, le problematiche di usabilità di molti progetti opensource. L’occasione per farlo è un comunicato stampa in cui Canonical, lo sponsor commerciale di Ubuntu, cerca consulenti di usabilità per i propri progetti, competenza evidentemente non presente in azienda.

Fino a qualche anno fa potevamo giustificare le lacune in ambito di usabilità e più in generale di user experience del software opensource. Erano progetti nati grazie a team focalizzati sulla progettazione e stesura di codice e usati da una ristretta minoranza di early adopters.

Le aspettative oggi sono diverse. Alcuni prodotti, come Open Office e WordPress, si rivolgono a un pubblico variegato, grazie anche a procedure di installazione semplificate e, nel caso di prodotti web, a metodi di fruizione ASP.

In questo contesto le problematiche tecniche, seppur importanti, passano in secondo piano. Il software deve essere facile da utilizzare, ma ancora di più deve proporre interfacce coerenti. Risultati che non si raggiungono per caso o con un po’ di buon senso, ma con l’introduzione di specifiche competenze professionali. Competenze che difficilmente si prendono in prestito.

Mi stupisce perciò l’iniziativa del team di WordPress che apre due questionari pubblici su questioni legate alla nuova interfaccia di amministrazione:

  • l’attuale interfaccia è il risultato di una già recente riprogettazione che ha richiesto agli utenti un nuovo approccio all’uso del software. Frequenti variazioni, per quanto si propongano di migliorare il lavoro di tutti, sono destabilizzanti;
  • ridurre la progettazione di una interfaccia grafica a un questionario sminuisce l’importanza e il ruolo di questa disciplina, anche quando gran parte delle decisioni sembrano prese;
  • il questionario si prefigge di raccogliere 5000 risposte. Ma il design di interfaccia non è un approccio democratico, quanto una disciplina che si prefigge di capire quale è la soluzione migliore per il pubblico di riferimento. Sono convinto che la maggior parte dei partecipanti al sondaggio sono sviluppatori, non necessariamente il target principale a cui si rivolge WordPress.

Ho avuto modo di provare per qualche minuto una versione, sicuramente non definitiva, della futura amministrazione di WordPress e ne sono rimasto sconcertato, soprattutto nel notare che quasi ogni azione richiede, diversamente dall’attuale, un primo click per aprire il menù e un secondo per selezionare la voce voluta. Le premesse non mi sembrano delle migliori.

Qualcosa comunque sembra muoversi nel verso giusto, anche se a un maggiore livello di astrazione. Il team di Mozilla promuove Concept Series, un insieme di idee, wireframe e prototipi a partecipazione pubblica per definire la visione dei futuri prodotti opensource. Nulla a che vedere con l’usabilità, ma qualcosa che potrebbe aiutare a raccogliere attorno ai progetti opensource una comunità con competenze non solo tecniche, ma anche di design e di user experience.

Aggiornamento serale: il blog di WordPress presenta una prima versione dei wireframe realizzati per progettare la nuova interfaccia di amministrazione. Visto che non è facile trovare in rete documenti che riportano wireframe completi e documentati, vale sicuramente la pena darci un occhio.