Alberto Mucignat

Segnalo che sono online le slide del summit americano di architettura dell'informazione. Non sono ancora riuscito a darci un'occhiata, ma mi pare ci sia parecchia carne al fuoco e anche delle novità interessanti.

Andrea c'è stato ed è tornato con un sacco di idee per il summit italiano, quindi tieniti libero per novembre, che abbiamo in serbo numerose sorprese. Tipo si vocifera che avremo degli ospiti internazionali pazzeschi. No, Obama no. Neanche Al Gore. Surprise!

Poco fa invece sono usciti i video del FOWD di cui ho parlato pochi giorni fa. Worth a look!

All'IA Summit americano, quelli di nForm hanno presentato un deliverable chiamato Swimlanes (ringrazio anche a nome di tutti gli ex nuotatori) e poi hanno anche spiegato meglio di cosa si tratta. Complimenti a loro che hanno così vinto il premio "Wall of Deliverable".

In pratica, si tratta di riunire in un unico deliverable una serie di documentazioni, in maniera che possa servire per la comunicazione a tutti i livelli di un'azienda. Per me è veramente un documento interessante e ringrazio gli amici di nForm per averlo condiviso. Ognuno poi ne faccia l'uso che vuole o lo modifichi a piacimento.



Ultima cosa: mi piacerebbe avere un angolo per votare il deliverable dell'anno anche al prossimo IA Summit italiano, per cui pingo i ragazzi del board su questo

"Are you creating something people actually want to use?" -Hannah Donovan

Al FOWD di Londra ho partecipato a un paio di workshop. Uno di questi con Hannah Donovan, direttore creativo di Last.fm.

Hannah ci ha spiegato i processi interni di design e di risoluzione dei conflitti tra le varie menti pensanti di last.fm. In breve: il design viene realizzato con i personaggi, che vengono appesi al muro e ognuno fa riferimento a loro quando si progettano o realizzano nuove funzionalità.

Quando c'è una nuova idea nell'aria, c'è una check list da utilizzare (la posto appena riesco ad avere le slide), ma prima di tutto viene verificato se c'è un personaggio che necessita della nuova funzionalità.

I personaggi sono basati su dati reali provenienti dalla loro base dati (20 milioni di utenti, a quanto pare) e quindi sono delle profilazioni su dati reali, altamente affidabili.

A questo punto, siccome tutti quelli che lavorano a Last.fm sono heavy users del loro sito, pensando a quello che spesso succede con i miei clienti, ho posto la domanda: come fate a bilanciare le vostre idee con i bisogni degli utenti?

Cioè: se a qualcuno di voi viene in mente una nuova funzionalità, chi decide se farla o meno visto che siete voi stessi utenti del sito?

Risposta di Hannah (da incidere sul marmo): valgono sempre e solo i nostri utenti. Se una cosa ha senso per loro allora viene pianificata, altrimenti semplicemente non la facciamo.

Il problema infatti è semplice. Per quanto tu possa essere l'inventore di un'applicazione web:

1. tu sei troppo coinvolto per poter decidere unilateralmente cosa serve ai tuoi utenti
2. tu stai progettando per l'utente finale, non per te

Ecco, a futura memoria di quelli che mi dicono "io conosco i miei utenti", senza avermi mai dato documentazione. Imparate la lezione, prima che sia troppo tardi.

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?

Domenica ho letto tutto d'un fiato "Da cosa nasce cosa" di Bruno Munari. Libro illuminante per chi fa experience design, quindi anche per il web.

Tra le altre cose ho trovato una parte che ben si collega alle mie ricerche su web e gioco. In una parte del libro Munari parla dei giochi in questi termini:

Il giocattolo ideale deve poter essere capito dal bambino senza alcuna spiegazione. Si può lasciare il giocattolo in mano al bambino e lui lo dovrebbe capire, sia cosa è, sia come si usa.

Questa cosa è valida anche nel web e si chiama usabilità. Potrebbe bastare questa frase a farci pensare, ma continua Munari:

Spesso occorre spiegare questi semplici giocattoli agli adulti, poichè gli adulti sono qualche volta nell'impossibilità di capire per eccesso di cultura che, se non è assimilata ma solo immagazzinata, fa da filtro a tutte le novità, per cui se uno vede una cosa nuova, non avendo una mente elastica, resta bloccato e la rifiuta perchè gli crea un complesso di inferiorità.

Ecco spiegata la frustrazione degli utenti adulti davanti ai problemi di usabilità.

In conclusione, credo che nel web siamo tutti un po' adulti. Ovvero:
1. il web dovrebbe essere semplice e autoesplicativo
2. per quanto semplice, ci saranno degli utenti che lo troveranno inusabile o poco chiaro

L'idea del gioco mi aiuta a pensare a come progettare il web, è uno stimolo inesauribile. Se hai altre risorse sull'argomento, batti un colpo nei commenti, grazie.

Il mio amico Enrico Maria lancia una bella riflessione a proposito di come le interfacce web del futuro siano orientate sempre più allo storytelling.

In effetti, a guardare bene, i servizi web che oggi hanno successo sono quelli che consentono agli utenti di raccontare le proprie storie. Dai blog ai tumblog, da flickr a youtube, tutti mettono a disposizione un taccuino virtuale su cui appuntare pensieri, immagini, idee, riflessioni. Le interfacce di questi servizi sono sostanzialmente semplici e consentono di operare senza fatica e in pochi secondi.

Inoltre, spesso mettono a disposizione i cosiddetti bookmarklet (quello di Tumblr è eccezionale), che consentono con un click di farci compiere azioni sulla pagina che stiamo leggendo (ad esempio postare al volo alcune frasi in un blog o un'immagine che ci piace su un photo book).

Alcuni servizi, grazie alle API, consentono ai programmatori di sviluppare veri e propri tool di supporto al servizio (penso al flickr upload o a twitterrific). Questi tool permettono di raccontarci direttamente dal nostro computer, senza aprire il browser e dover andare sul sito web del servizio.

La mia impressione quindi è che le interfacce per lo storytelling stiano diventando sempre più immediate e facili da usare, fino a diventare quasi trasparenti per l'utente.

Inoltre, queste tendenze stanno facendo da traino anche per tutte le altre applicazioni web. Chi sviluppa web, specialmente in Italia, si trova quindi nella scomoda posizione di dover continuamente rincorrere questi "trends", con tutte le conseguenze del caso.

A tal proposito, hai qualche esperienza da condividere?

Glom. (Non so se tirare un sospiro di sollievo o se rimanere in apnea...)



E un saluto agli amici di Voi siete qui!

La mia linea dati naked ha subito un rincaro di 12 euro al mese (da dicembre). In pratica devo pagare un sovrapprezzo a Telecom che non sapevo avrei dovuto pagare quando ho acquistato il servizio dal mio operatore (NGI).

Le comunichiamo che l'Agcom, con la delibera n. 249/07/CONS approvata in data 23 maggio 2007, ha dato il nulla osta a Telecom Italia per applicare a tutti agli operatori (ISP) un canone aggiuntivo mensile per tutte le linee ADSL attive su cavo dati (ADSL "Naked").
Dato che la sua linea rientra fra queste tipologie, nell'importo sopra menzionato, è incluso tale contributo per un importo di 36,00 Euro iva compresa (trimestrale, ndb).

Cioè: ho un contratto da X euro al mese e da dicembre pago X+12 euro al mese, tanto per gradire. Il sovrapprezzo ricade sull'utente, ovviamente, non sia mai che l'operatore si accolla il costo. Su questo dovrebbero intervenire le associazioni dei consumatori. O no?

Comunque, per me questa è una follia tutta italiana. Ci libereremo mai dalla schiavitù di un operatore monopolista che fa quel che vuole grazie soprattutto alla collusione con lo stato?

Ma la situazione in fondo è ancora peggiore. Il fatto è che non ci siamo fatti sentire quando ne avevamo la possibilità. E adesso paghiamo.

Nella progettazione centrata sull'utente (UCD, User-Centered Design) un passaggio chiave è quello di definire i personaggi (o personas), ovvero degli "utenti tipo" sui quali verrà centrata tutta la progettazione del servizio web. Alla fine del processo, di solito vengono prodotti un paio di personaggi per ogni progetto.

Ora la domanda è: come fanno questi 2 personaggi a rappresentare tutti gli utenti che avrà il mio servizio web? Come posso pensare di progettare un servizio per loro 2, quando in realtà può essere usato da milioni di utenti?

Flow Interactive ha postato a proposito una serie di risposte sensate che mi permetto di evolvere liberamente:

1. i personaggi sono tuttora il modo migliore che abbiamo per rappresentare gli utenti
2. i personaggi aiutano a definire gli utenti limite del sistema
3. non tentare di progettare per tutti gli utenti

In particolare, gli ultimi due punti si legano ad un piccolo sfogo di Stefano sugli utenti medi del web. Il punto è che spesso, nel definire i personaggi del nostro sistema, pensiamo proprio di dover definire l'utente medio, sul quale andiamo a costruire il nostro sistema web. In realtà, si dovrebbe definire un utente particolare, con esigenze particolari.

Faccio un piccolo esempio.

Di recente mi è capitato di vedere dei personaggi inventati di sana pianta. L'errore non è solo nel metodo, perchè di solito i personaggi vengono definiti dopo una fase di ricerca e analisi sul target degli utenti, supportata da attività concrete (interviste, focus group, ecc) (*). L'errore risiede soprattutto nel fatto che se ci inventiamo dei personaggi, inevitabilmente tendiamo a idealizzarli e a immaginarceli perfetti, perlomeno per il ruolo che devono ricoprire nel nostro scenario, nel nostro sito web.

Ma l'utente perfetto non esiste, come non esiste l'utente medio.

Per progettare un servizio web dobbiamo capire soprattutto per chi non stiamo progettando. È un pilastro della strategia: capire prima di tutto cosa non fare, a chi non rivolgersi. Ne consegue che non possiamo progettare per l'utente perfetto, ovvero per l'utente medio, ma dobbiamo invece definire gli utenti particolari del nostro sistema.

Questi utenti particolari hanno delle esigenze che sono evidentemente particolari. Soprattutto, queste esigenze devono combaciare quanto più possibile con i requisiti business. Questi ultimi, devono essere abbastanza circoscritti, altrimenti si ricade nel problema noto come WTGO ("Wannabe the Google of ...").

In conclusione, credo che il processo di definizione dei personaggi parta a monte, mentre si pensa al servizio da realizzare. Definiti i requisiti business, si definiscono di conseguenza i personaggi (gli utenti particolari!) a cui è rivolto il servizio. Questi ultimi non sono una semplice rappresentazione del target utenti, ma sono il prodotto di un'intensa attività di ricerca e analisi.

Mettiamola così: se non lavoriamo con criterio sui nostri personaggi, non stiamo nemmeno lavorando per i nostri 5 milioni di utenti.

(*) Penso che comunque sia una buona pratica immaginarsi i propri utenti, sicuramente meglio del non immaginarseli affatto

Mi chiedo se sono l'unico cliente Aruba a voler accedere all'area clienti. Di sicuro, essendo un cliente, vorrei essere un attimo facilitato.

E invece... trovatelo voi il link all'area clienti, se ci riuscite.