Alberto Mucignat

“La perfezione non si ottiene quando non c'è più nulla da aggiungere, bensì quando non c'è più nulla da togliere" -Antoine de Saint Exupery

"Sbarazzati della metà delle parole di ogni pagina, e poi sbarazzati della metà di quello che resta" -Steve Krug, Terza legge di Krug sull'usabilità

"Less is more" -Unknown

Togliere è un'attività fondamentale in ogni processo creativo.

La dimostrazione empirica è che da quando faccio test sugli utenti, mi accorgo che spesso non vogliono molte delle cose che ci vengono in mente.

Quindi, sintetizzando.

"Lavorare con gli utenti serve soprattutto a capire cosa togliere" -Alberto Mucignat

Getting Real è una bella lettura estiva. Il libro è uscito da un sacco di tempo, ma vale la pena rileggerlo perchè è sintetico, essenziale, zen.

E poi aiuta a mantenere i piedi per terra. Leggetelo anche a pezzi, ma leggetelo.

Nella sua semplicità, un capitolo fondamentale è Interface Design, dove si spiegano pochi chiari concetti che dovrebbero essere alla base della progettazione di ogni servizio web.

A mo' di mantra riporto i punti più importanti:

- Epicentric Design: iniziare (e focalizzare) il design a partire dal core della pagina. Ne parlo da diversi anni anche in termini di page paradigm.

- Context over Consistency: in ogni pagina ci vanno le informazioni giuste, sulla base di quello che l'utente può decidere di voler fare. Un esempio classico sono i menù: non è detto che uno stesso menù debba apparire in ogni pagina del sito, ma questa è invece una convenzione comune nel costruire siti web.

- Three state solution: disegnare le pagine web pensandole nei 3 stati: regular, error, blank. In particolare lo stato blank viene spesso tralasciato (anche dal sottoscritto, sigh). Si tratta di pensare la pagina a come appare la prima volta che un utente la visita. La prima impressione di un'applicazione web è spesso la cosa più importante (remember: "you never get a second chance").

- Get defensive: migliorare l'esperienza dell'utente in caso di errore o altri problemi. Questa regoletta è stata poi ampliata per bene dagli autori nel libro Defensive Design.

- Copywriting is Interface Design: per finire in bellezza, se non fai copywriting, non stai facendo design. Fondamentale.

In queste regole manca forse qualche accento in più sull'utente, sugli scenari di utilizzo e sui task, che sono fondamentali per stabilire quali cose siano centrali e funzionali a una data pagina. Ma per il resto, lo trovo formidabile.

Nissuna umana investigazione si può dimandare vera scienza, s'essa non passa per le matematiche dimostrazioni -Leonardo Da Vinci

La scorsa settimana sono stato a Londra, per seguire il Future of Web Design. La conferenza è stata molto stimolante, anche se talvolta sento ripetere sempre le stesse cose. Forse sono io che le ho metabolizzate a tal punto che ormai mi sembra superfluo parlarne...

Però, una cosa che non mi è piaciuta per niente è il proporre continuamente l'idea che il design sia da ricercare attraverso il genio e la pura ispirazione.

È falso, oltre che un errore pazzesco.

Primo perchè in questo modo si abituano i designer a pensare che o sono geni, oppure non hanno speranza. Il che è frustrante per chi non ha molta fiducia in se, oltre che un problema quando un "creativo" si trova poi all'interno di un team di lavoro. Si perchè il genio e l'ispirazione sono legati ad una sola persona. Ma difficilmente i designer si troveranno a lavorare da soli ad un problema, mentre sempre di più oggi il problema è riuscire a lavorare in team, modificando le proprie idee in base alle esigenze degli altri.

Secondo perchè il design è una scienza, non un'arte.

Ovvero, la creatività va gestita, non si può pensare che arrivi dall'alto per concessione divina. Ci sono dei processi e delle informazioni che regolano tutto il medodo creativo e che dobbiamo imparare a gestire e a controllare (tanto per dire, vedi sempre Munari, Da cosa nasce cosa).

Tra l'altro, alcuni a Londra hanno citato Leonardo Da Vinci, dicendo che è stato un genio del design.

Certo. Ma Leonardo ha passato la vita a studiare tutte le scienze e le cose di cui veniva a conoscenza. Ogni piccolo dettaglio delle sue opere e delle sue invenzioni proveniva da precedenti informazioni che Leonardo aveva studiato e analizzato. Leonardo aveva un metodo scientifico per memorizzare, selezionare e analizzare le informazioni.

Leonardo era sicuramente uno molto dotato, ma genio lo è diventato col tempo, con le informazioni e le esperienze. E grazie soprattutto al suo metodo, che andrebbe forse studiato più che le sue invenzioni (vedi anche Introduzione al metodo di Leonardo Da Vinci).

Il genio forse non esiste. Ne parla bene anche Scott Berkun in The myths of innovations, dicendo che tutti quelli che noi consideriamo "geni" in realtà hanno passato tanti anni, se non l'intera esistenza, a studiare e ad analizzare spesso solo un singolo problema.

Si chiama tenacia, non genialità.

Vedi la storia di tutti i premi Nobel: ne trovi uno che ha inventato qualcosa in un paio di giorni? O senza l'aiuto di precedenti scoperte? Pensa anche ai teoremi di matematica, alla fisica, alla chimica...

Pare che Edison abbia fatto 2000 tentativi prima di realizzare la moderna lampadina col filamento in carbonio. 2000. Duemila.

Prova solo a contare fino a duemila.

La domanda è: tu a quale tentativo ti saresti fermato?

I wireframe devono essere brutti, mi dice Mafe, che a sua volta gliel'hanno detto gli americani.

Da tempo progetto in bassa fedeltà, cerco di far entrare in gioco il visual design (colori, stili grafici, sfumature, rifiniture) solo nella fase finale del lavoro. Devo dire che funziona, anche se richiede un passaggio difficile per chi è abituato a visualizzare il prodotto come un insieme di colori ed effetti grafici.

Ripensando ai lavori passati, mi rendo conto di quanti mockup ad alta fedeltà venivano prodotti all'atto dell'offerta al cliente. Completamente inutili, perchè il cliente si fissava su un modello grafico e le successive modifiche venivano viste come una ritrattazione. E chi poteva dargli torto?

Soprattutto, le informazioni visualizzate nel mockup erano quasi sempre sbagliate, perchè il lavoro di progettazione doveva ancora essere fatto.

Per questo ci sono alcuni buoni motivi per lavorare in bassa fedeltà, almeno fino a un certo punto dello sviluppo di un progetto web:
- focalizzare l'attenzione su informazioni e funzionalità
- concentrarsi sulla struttura comunicativa e semantica
- rappresentare efficacemente le interazioni e l'architettura dell'informazione

Vi sono invece molti problemi a lavorare fin da subito in alta fedeltà. Ne cito solo alcuni:
- fissazione del cliente (ma anche dei designer) su un aspetto grafico prestabilito
- costi iniziali di sviluppo del design
- impossibilità di prevedere a priori tutte le informazioni da visualizzare
- difficoltà ai cambiamenti radicali di design
- difficoltà a concentrarsi sulle informazioni
- interminabili discussioni inutili sull'aspetto grafico
- poche discussioni costruttuive su come effettivamente deve funzionare il prodotto

Un collega anglosassone una volta aveva scritto "i wireframe migliori che ho visto erano schizzi disegnati sulla carta".

L'altro giorno un cliente ha visto i wireframe digitali di alcuni scenari di navigazione in media fedeltà. La reazione è stata abbastanza contenuta. Alla fine gli ho fatto vedere uno schizzo che non ero riuscito ancora a mettere in formato digitale, nel quale c'erano i miei commenti, scarabocchi vari e molte imperfezioni. La reazione è stata: stupendo, potresti darmi anche questo?!?

La morale è che in fase di progettazione funziona meglio un prototipo a bassa fedeltà.

Alcune risorse utili:
- High or low fidelity, paper or computer ("Low-fidelity prototypes have big advantages in cost and ease of iteration, and allow designers to focus on interaction design and information architecture")
- Balancing fidelity in prototyping ("fidelity has to be balanced and your clients should be told that high-fidelity is not the way to go if they want a well-designed product and a cost-effective design phase")
- High and low fidelity prototyping ("Low fidelity allows you to work rapidly and iterate quickly")
- Don't make the demo look done ("How 'done' something looks should match how 'done' something is.")

Mi piacerebbe anche conoscere la tua esperienza a proposito. Come funziona da te? Lavori in alta o bassa fedeltà? Cosa ne dicono i clienti? Come funziona al vostro interno? Quali sono i problemi?