Designer oggi

Consiglio a chiunque si occupi di progettare interfacce per applicazioni web, ma anche di semplici siti, la lettura della trascrizione dell’intervento di Luke Wroblewski, Senior Principal Designer a Yahoo!, alla User Interface Conference a Cambridge, nel 2006.

Una presentazione importante per capire come cambia il ruolo del web designer ai nostri giorni. Design non significa più solo abbellimento, ma anche innovazione. E non si tratta di decidere se un bottone dev’essere sottolineato, bold o rosso, ma si tratta di guidare l’utente nell’uso e fruzione del sistema in costruzione.

I fattori che guidano questo cambiamento di rotta nella professione sono 3:

  • i mercati in rapida evoluzione ed espansione e crescita, anche quelli nati da poco. Quando i mercati sono maturi, più produttori offrono un prodotto con le medesime funzionalità, che deve differenziarsi anche grazie al design
  • le esigenze degli utenti cambiano radidamente e la tecnologia, in taluni casi, le anticipano. Il design è in continua evoluzione
  • information overload (sovraccarico di informazioni). Un buon design aiuta l’utente a districarsi con facilità anche tra dati e processi ad altra complessità

Una professione in continua evoluzione, quindi. Ma i designer italiani, web e non, se ne rendono conto, o continuano a ragionare solo in termini di spazi, colori, risoluzione, fondini?

Riprogettazione di applicazioni web

Riprogettare un’applicazione web nel nome di una migliore usabilità, oltre che per arricchirne le funzionalità, è un’operazione lodevole e che si verifica molto spesso in un ambito così concorrenziale come internet.

Ma attenzione a stravolgere un’applicazione, anche se con i propositi più meritevoli.

E’ vero che riprogettare un’applicazione web la può notevolmente migliorare, ma è anche vero che gli utenti affezionati al servizio, soprattutto quelli meno esperti, si trovano a dover reimparare l’uso di un’interfaccia che conoscevano alla perfezione (sia i suoi pregi, sia i suoi difetti). Rendetevi conto che state chiedendo a questi utenti, che vi hanno dato fiducia, di fare del lavoro non richiesto.

Non esistono delle regole da applicare a propri che spieghino come comportarsi. Vale la pena prima di tutto coinvolgere gli utenti, e questo si può fare ancora prima di riprogettare l’applicazione, chiedendo il loro parere sui limiti della versione attuale e sulle funzionalità di cui il prodotto manca.

Le statistiche, insieme ai dati delle registrazioni, sono un ottimo metodo per distinguere la percentuale di utenti consolidati rispetto a chi entra e fugge, e vi può aiutare a capire a quanti utenti state arrecando piccoli o grandi disagi. Quest’analisi, in realtà, andrebbe fatta indipendentemente dalla riprogettazione del servizio.

Nella maggioranza dei casi quello che emerge è che piuttosto di considerare l’applicazione come una tabula rasa su cui ripartire da zero, è meglio procedere con passi incrementali, ben documentati.

Introdurre una nuova funzionalità, sottolineare i cambiamenti nell’interfaccia, attendere un feedback, introdurre una nuova funzionalità, e così via.

E’ quello che succede con prodotti come Flickr e Gmail che vengono considerati in “beta perpetua”. Questo permette al team di sviluppo di rilasciare costantemente nuove funzionalità secondo i principi della programmazione agile, ma evita anche agli utenti di essere sommersi da nuove caratteristiche da digerire tutte in un colpo.

Capita a volte che questo procedimento non sia perseguibile, perché la riprogettazione dell’applicazione si discosta talmente tanto dalla versione precedente da rendere impossibile il rilascio incrementale.

Anche in questo caso si può, in alcuni casi, fare qualcosa. E’ quello che è successo ad esempio con Google Reader. In questo caso la vecchia versione del prodotto è stata completamente riscritta, senza stazioni intermedie.

Ogni utente ha però la possibilità di tornare, se non è soddisfatto della nuova versione, a quella precedente, dovesse mai preferirla, per un periodo limitato, e sottoporre anche un commento. Si tratta comunque di un processo altamente dispendioso, perché vi trovate a gestire contemporaneamente due prodotti diversi.

Guida di stile per il web: il design grafico

Realizzare progetti web di una certa complessità – della durata di almeno un mese, e che siano seguiti da una fase di manutenzione dei contenuti più o menu lunga – richiede molto organizzazione, ma anche qualche standard.

Solitamente quando mi trovo coinvolto in questo tipo di progetti consiglio di stendere una serie di linee guida da seguire nello sviluppo del processo. Questa serie di linee guida le ho sempre chiamate guide di stile, anche se solitamente questo termine viene impiegato soprattutto per indicare le linee guida relative ai contenuti.

Sono principalmente due le fasi di un progetto web in cui è applicabile il concetto di guida di stile:

  • nella costruzione del layout della pagina e dei diversi elementi
  • nella organizzazione e stesura dei contenuti

Esploriamo qui il primo punto, lasciando il secondo a un successivo intervento.

Una guida di stile per la grafica di un sito dovrebbe essere un documento che si pone due obiettivi: servire come riferimento durante il processo di costruzione del layout delle pagine del sito, ma dovrebbe anche essere consegnato al cliente che si occupa di caricare in contenuti insieme alla guida di stile per i contenuti.

In questo modo chi si trova a dover realizzare nuove pagine nel corso della manutenzione del sito può, se gli è concessa questa possibilità, verificare se le nuove immagini, icone, foto, spalle, box che si appresta a costruire sono in linea con lo “spirito” del sito.

Ecco cosa dovrebbe contenere, sottoforma di testo e immagini, una guida di stile per il design grafico:

  • una rappresentazione dei diversi tipi di template del sito, motivando quando andrebbe usato uno e quando l’altro. Qui varebbe la pena sottolineare eventuali particolarità da prendere in considerazione quando la grafica verrà portata in Html e completata da codice lato server. Questo è utile perché chi si trova a lavorare con in template potrebbe sottovalutare l’impatto di lievi “personalizzazioni” alla grafica
  • l’elenco di tutte le icone usate nella grafica, con la spiegazione del loro utilizzo
  • qualche linea guida per la produzione di nuove immagini e loghi per i contenuti (dimensioni, posizione, in che formato salvarle, ecc.)
  • indicazioni sulla tipografica
  • indicazioni sui tipi di font e stile ai caratteri ammessi (sottolineato, colorato, ecc.)
  • suggerimenti sui diversi tipi di intestazione e link ammessi nel sito, con spiegazione, dovessero essere più d’uno, del loro impiego

Andrebbe quindi presentato un documento che contenga la grafica da usarsi all’interno del sito, arricchito però da qualche linea guida che permetta di capire da come partire da questa grafica per realizzare il codice.

Questo documento aiuta a non ritrovarsi nella frequente situazione per cui, dopo pochi mesi dalla messa online del sito, il designer grafico che l’ha creato vorrebbe non riconoscerne la paternità per colpa dei contenuti non in linea con quanto da lui progettato.