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?

Interfacce che si adattano

Cominciano a comparire nei blog dei relatori alcune delle presentazioni al recente Information Architecture Summit di Las Vegas. E ce ne sono da leggere con attenzione.

Come per esempio quella di Stephen Anderson, “Creating the Adaptive Inferface” che affronta il problema della progettazione di interfacce che non si manifestino allo stesso modo a tutti gli utenti, ma siano in grado di adattarsi alle diverse esigenze, ai diversi usi, e anche al grado di padronanza che con l’uso l’utente è in grado di dimostrare.

L’idea – non nuova – di Anderson è quella di sfruttare le informazioni “involontariamente” lasciate dall’utente nel sito web, come per esempio l’indirizzo di ip (e quindi, con buona approssimazione, la località) e, nel caso di servizi sotto login o che sfruttino i cookie, le variazione nelle attività dell’utente e la frequenza di utilizzo.

Questo permette al software che produce l’interfaccia di evidenziare le sezioni più richieste a scapito di quelle meno utilizzate, di precompilare alcuni campi in base alle preferenze dell’utente e di personalizzare alcune etichette dell’interfaccia.

Il concetto è sicuramente interessante, come lo sono i diversi esempi presentati. Esistono comunque alcuni fattori da tenere in grande considerazione nel progettare questo tipo di interfacce. Il primo, riconosciuto dallo stesso autore, è che l’utente non va spaventato dandogli a vedere che sappiamo molto di lui: l’aiuto dell’interfaccia dev’essere discreto e non superare mai i limiti della cortesia.

A questo aggiungo che esiste un rischio nel modificare il comportamento dell’interfaccia verso un utente col il progredire della sua esperienza, ed è quello di generare dubbi e confusione perché eravamo convinti “che quel pulsante fosse lì” e che “quella funzionalità si attivasse in quel modo”. Anche queste variazioni vanno studiate con molta cautela.

Interfacce tolleranti

Se dovessi scegliere una funzionalità di Google Calendar che ho trovato particolarmente utile è quella chiamata Quick Add.

E’ cioè possibile aggiungere un evento al calendario senza doversi necessariamente posizionare sul giorno desiderato e inserire tutti i campi.

Google calendar

Google Calendar cerca infatti di analizzare il testo inserito in modalità Quick Add in modo da evincere se è presente un’indicazione di data e di luogo (o, come dice la pagina di aiuto di Google, “who, what, when and where”)

E’ stato portato all’estremo il concetto del pattern chiamato Forgiving Format, che suggerisce a chi progetta le interfacce di non realizzare form complicati con decine di campi, combo e check box con l’errata convinzione che imprigionare l’utente gli eviterà di commettere errori. Dei maestri (in negativo) in questo senso sono alcuni sviluppatori (tra cui, in passato, io stesso), che per evitare del lavoro in fase di validazione dell’input, giungono perfino a usare 3 combobox diverse per richedere una data.