User-centered design: progettare considerando i bisogni degli utenti

Semplicemente stupendo il libro che sto leggendo e di cui scriverò in questi giorni una sintesi su questo blog. Il libro è di Donald A. Norman e si intitola La caffettieria del masochistaRiporto un suo estratto che si collega ad una considerazione personale che avevo pensato di scrivere nei giorni scorsi.

comic-ease-of-use

Questa è una sorta di autocritica per chi come me si occupa di progettazione e sviluppo di software. Ecco il passo del libro in questione:

“Ma i progettisti sembrano particolarmente dimentichi dei bisogni degli utenti, particolarmente inclini a cadere in tutti i trabocchetti del design. Gli specialisti del design non sono interpellati quasi mai per questo tipo di prodotti. La progettazione è lasciata invece tutta nelle mani di ingegneri e programmatori, persone che di solito non hanno alcuna esperienza né competenza specialistica nel campo del design.

Il carattere astratto del computer propone una sfida tutta particolare. Il funzionamento è elettronico, invisibile, senza alcun segno esterno delle azioni che vengono eseguite. E i comandi vengono impartiti mediante un linguaggio astratto, un linguaggio che specifica il flusso interno dell’informazione, con le relative istruzioni, ma che non è particolarmente tagliato a misura dei bisogni dell’utente.

I programmatori specializzati lavorano su questi linguaggi  per impartire al sistema le istruzioni necessarie per eseguire le operazioni richieste. E’ un compito complesso e i programmatori devono possedere un ampio repertorio di competenze e talenti naturali. La messa a punto di un programma esige infatti una combinazione di capacità specialistiche, della preparazione tecnica della conoscenza del compito, fino alla cognizione delle esigenze e delle capacità degli utenti.

Ai programmatori non dovrebbe essere addossata la responsabilità delle interazioni tra la macchina e gli utenti:non ne hanno la competenza specialistica, né dovrebbero averla. Molti dei programmi esistenti per le applicazioni da parte degli utenti di base sono troppo astratti, richiedendo manovre che hanno un senso per le esigenze del computer – e agli occhi dello specialista di computer – ma non sono coerenti, ragionevoli, necessarie o comprensibili per l’utilizzatore normale. Per rendere il sistema più facile da usare e capire ci vuole una gran quantità di lavoro in più. I programmatori hanno tutta la mia comprensione, ma tuttavia non posso scusare il generale disinteresse per i problemi degli utenti. ”

 

E ancora condivido la considerazione di Norman sulla poca presenza nei programmi universitari di materie relative all’usabilità e alla progettazione “usercentric” dei sistemi, non solo informativi. Il cosiddetto user-centered design.

” La scienza del computer ha lavorato finora allo sviluppo di potenti linguaggi di programmazione che permettono di risolvere i problemi tecnici di calcolo. Deboli sforzi sono stati compiuti in direzione di efficaci linguaggi interattivi. Ogni studente di un corso per programmatori viene istruito sugli aspetti computazionali dei computer, mentre sono rarissime invece le lezioni sui problemi che si pongono all’utente. In generale questo tipo di insegnamento non è richiesto nei piani di studio, né peraltro sarebbe facile fargli posto negli orari già fittissimi e massacranti cui devono sottoporsi gli studenti d’informatica. Il risultato è che la maggior parte dei programmatori sa scrivere programmi capaci di eseguire operazioni mirabili, ma inutilizzabili per chi non è uno specialistica del ramo. Quasi nessuno di loro pensa ai problemi che deve affrontare l’utilizzatore. Da qui la sincera sorpresa che li coglie quando scoprono che le loro creazioni sottopongono l’utente comune a una dispotica tirannia.”

 

E’ importante lavorare con persone creative. Ho conosciuto professionisti capaci di applicare principi di buon design e di usabilità nella progettazione di software, sia web che mobile. Dai grafici attenti a questi principi si impara e si trae una esperienza professionale positiva, oltre a produrre software di buona qualità e piacevole per l’utente.

La cosiddetta user experience merita un’attenzione particolare; dovrebbe essere un processo a parte nello sviluppo del software. Specie nelle società ICT italiane, spesso si confondono le figure di progettista, analista, sviluppatore, oltre a non esistere quelle di graphic o user experience designer. Ma per mantenere alto il livello di qualità e competitività del prodotto, occorre essere coscienti della forte specializzazione delle competenze da mettere in gioco.

Cito due massime efficaci per trarre le seguenti conclusioni:

  1. Chi nasce tondo, non muore quadrato” – dividiamo le competenze e le responsabilità delle figure coinvolte in un progetto.  Ognuno faccia il proprio mestiere, senza confondere le professionalità. Dalla interazione di queste professionalità, nasce il buon presupposto per realizzare un prodotto di successo.
  2. Lo sparagno (cit. risparmio) è mal guadagno” – il cosiddetto “triplo vincolo” di un progetto (costo, tempo, qualità), andrebbe spostato sempre più in direzione della qualità. Per far ciò occorre dotarsi di figure competenti per coprire i vari ambiti della progettazione software (analisti, grafici, sviluppatori, progettisti, ecc.). Provate a far fare ad uno sviluppatore la grafica, nella maggior parte dei casi produrrà qualcosa di poco piacevole ed usabile per l’utente finale.

Un pò di sapere è pericoloso: “Ars longa, vita brevis”

Da quando ho messo su questo blog articoli tecnici, mi arrivano spesso mail per informazioni sulla risoluzione di problemi di programmazione, soprattutto quelli legati all’iOS di Apple, visti alcuni processi “rognosi” in cui spesso ci si sbatte.
La mia idea è che si sta procedendo verso quella che definirei “standardizzazione” del linguaggio, che facilita la programmazione, portando anche i non esperti del settore a “cimentarsi” nello sviluppo dei software.

Quella che scrivo è una riflessione che si può applicare ai settori lavorativi più disparati, ma che qui vorrei particolareggiare per quello in cui opero, quello dello sviluppo di software appunto.

Innanzitutto, parto da una citazione famosa di Socrate: “Scio ne sapio” (“Io so di non sapere”). La citazione è rivolta (e venne rivolta) con un atteggiamento polemico contro coloro che pretendono di sapere troppo. Ma il “non” sapere è uno stato normale dell’uomo.
La presente riflessione è nata dopo aver letto una mail, e di cui qui vi riporto un estratto:

[…] So utilizzare abbastanza bene Windows 7; non sono un programmatore, ma mi interesserebbe prendere delle lezioni sull’utilizzo dello smartphone e tablet Apple (rispettivamente iPhone e iPad). Sono appassionato di questi apparecchi, ma non so utilizzarli. […]

Cosa ho pensato? La curiosità è lecita, ma non si può pretendere di imparare a programmare così da un giorno all’altro e, sicuramente, non è il caso di partire da Objective-C per farlo.

Il punto di partenza potrebbe essere quello di trovare un “linguaggio padre”, come può essere C/C++/Java per i linguaggi “tipati” o Python/PHP per quelli “non tipati”.
L’importante è iniziare a pensare alla programmazione. Non programmare.

Mi ha molto affascinato l’articolo di Peter Norvig (padre dell’intelligenza artificiale) dal titolo: “Teach Yourself Programming in Ten Years“, e di cui riporto il link all’ottima traduzione di Fabio Tessitore): Imparara a programmare in 10 anni…perchè vanno tutti di fretta?

Vi invito a leggerlo tutto di un fiato. Io da qui ho estrapolato le seguenti frasi/citazioni:

  • La conclusione è che le persone vanno molto di fretta quando devono imparare qualcosa sui computer, oppure che i computer sono qualcosa di favolosamente facile da imparare rispetto a qualsiasi altra cosa.
  • Non ci sono libri su come studiare Beethoven, la Fisica dei Quanti o perfino l’Addestramento dei Cani in pochi giorni.
  • Come disse Alexander Pope, “un po’ di sapere è pericoloso“.
  • Qual è il punto? Alan Perlis una volta disse: “Un linguaggio che non influenza il modo di pensare la programmazione, non vale la pena di essere conosciuto. È possibile che debba imparare una piccola parte del C++ (o più probabilmente, qualcosa del tipo JavaScript o Flash) perché hai bisogno di interfacciarti con qualcosa di esistente per portare a termine un compito specifico. Ma allora non stai imparando a programmare; stai imparando a completare quel compito”.
  • Alcuni ricercatori (Bloom (1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973)) hanno dimostrato che sono necessari circa dieci anni per sviluppare esperienza in una gran varietà di campi, inclusi il gioco degli scacchi, la composizione musicale, la telegrafia, la pittura, il suonare il pianoforte, il nuoto, il tennis, le ricerche in neuropsicologia e in topologia.
  • La chiave è la pratica intenzionale: non semplicemente farlo ancora e ancora, ma impegnarsi in un compito appena oltre le proprie abilità, provare, analizzare il proprio rendimento mentre e dopo l’esecuzione e correggere gli errori. Quindi ripetere. E ripetere ancora. (Vedi l’articolo “Lo sgobbone batte l’intelligente“)
  • Samuel Johnson (1709-1784) pensava ci volesse anche di più: “L’eccellenza in un campo qualsiasi può essere raggiunta solo attraverso il lavoro di una vita; non si può acquistare ad un prezzo inferiore“. E Chaucer (1340-1400) aggiunse La vita è così breve, l’arte così lunga da imparare. Ippocrate (c. 400 AC) è noto per la massima “Ars longa, vita brevis“, che è parte della citazione più lunga “Ars longa, vita brevis, occasio praeceps, experimentum periculosum, iudicium difficile, che in Italiano suona come” –  [La vita è breve, l’arte è lunga, l’occasione è fugace, l’esperienza ingannevole, il giudizio difficile]. Sebbene in Latino, “ars” può significare sia arte che mestiere, nell’originale Greco la parola “techne” significa solo abilità, non arte.
  • Lavora su progetti insieme ad altri programmatori. Sii il miglior programmatore in alcuni progetti; sii il peggiore in altri. Quando sarai il migliore potrai testare le tue abilità di guidare un progetto e ispirare gli altri con la tua visione. Quando sarai il peggiore imparerai cosa fanno i maestri, e cosa non piace fare loro (perché lo faranno fare a te).
  • Perlis dice che i migliori hanno un talento che prescinde dall’allenamento. Ma da dove viene questo talento? È innato? O viene sviluppato con la diligenza? Auguste Gusteau (lo chef di Ratatouille) dice: “Tutti possono cucinare, ma solo gli impavidi possono essere grandi.” Penso sia volontà di dedicare una larga parte della propria vita alla pratica. Ma forse “impavidi” è un termine per sintetizzare questo concetto. Oppure, come dice Anton Ego, il critico di Gusteau: “Non tutti possono diventare grandi artisti, ma un grande artista può venir fuori da ovunque“.

Non c’è altro da aggiungere penso. Occorre aver la coscienza di non sapere le cose, per studiarle, provarle e confrontarsi con gli altri, migliorandosi continuamente. Comunque, il segreto per sopportare lo sforzo è quello di fare le cose con passione.