In teoria non c’è differenza tra teoria e pratica, in pratica si

Norman Donald
La Caffettiera del masochista
Giunti editore 2014

caffettiera-masochista

Questo libro mi è stato consigliato da Roberto Picerno, un amico interaction designer in IDEO, alla mia richiesta di una bibliografia per iniziare a studiareinteraction design.
Fin dalle prime pagine mi ha aperto la mente e fatto capire l’importanza e la profondità di un approccio progettuale “antropocentrico” (assicurarsi cioè che i prodotti rispondano davvero a bisogni reali e che siano comprensibili e facili all’uso).

Scritto in maniera molto semplice e comprensibile passa in analisi sistemi molto vari, dal semplice al complesso, andando quindi a definire alcune regole base per qualunque progetto, che si tratti di un pela patate o dell’organizzazione del lavoro in una azienda.

Il libro offre un sacco di strumenti pratici su come affrontare la fase progettuale, rispondendo sia a dubbi banali tipo “a quante persone far testare un prototipo per ogni interazione” (dubbio che effettivamente avevo), che analizzando questioni più filosofiche (es. come funziona la memoria), riuscendo però ad amalgamare le questioni in un unica strategia progettuale, quella dello Human-Centered Design.

Mi fermo qui perchè sono fresco di lettura e inesperto al lato pratico, vorrei però riportare alcuni paragrafi che mi hanno chiarito, con parole migliori, varie questioni aperte nel progetto TwoReads.
Sono diversi paragrafi, intrecciati tra loro e che si compongono l’un l’altro:

“I tecnici e le persone logiche in genere tendono a considerare irrilevante la risposta viscerale. Un ingegnere progettista è fiero della qualità intrinseca del suo lavoro ed è costernato quando prodotti peggiori si vendono meglio «solo perchè sono più carini». Ma tutti noi siamo portati a dare questo tipo di giudizi immediati, non escluso il più razionale degli ingegneri, che non a caso ama certi dispositivi mentre altri li usa mal volentieri. Le risposte viscerali contano eccome.”

Leggendo questo paragrafo ho pensato a Lorenzo e Alex, i più tecnici del team, ed è interessante notare che Norman stesso nasca come ingegnere.
Direttamente collegati ci sono questi altri due:

“[…] se tutti capiscono il punto di vista di tutti, è possibile ideare soluzioni creative capaci di soddisfare la maggior parte delle esigenze. Si noti che neanche lavorando in un gruppo del genere è cosa facile: ognuno ha un gergo tecnico diverso, ognuno pensa che la sua disciplina sia quella fondamentale e non di rado considera le richieste degli altri superflue. […] Le squadre multidisciplinari, grazie alla migliore comunicazione e collaborazione, spesso permettono di risparmiare tempo e denaro.”

E ancora:
“Di solito alla testa dei vari comparti di un’azienda ci sono persone intelligenti che cercano di fare del loro meglio e, quando intervengono a modificare un progetto, lo fanno perchè non soddisfa le loro esigenze. Sono preoccupazioni legittime, ma le modifiche introdotte in questo modo sono quasi sempre dannose. La maniera migliore di ovviare a tale problema è assicurarsi che rappresentanti di tutti i comparti siano presenti durante l’intero processo, a partire dalla decisione di lanciare il prodotto, e in tutte le fasi fino alla distribuzione e all’assistenza. Così tutti i rilievi avranno modo di farsi sentire tempestivamente. A sovraintendere l’intero processo di ideazione e realizzazione deve esserci una squadra multidisciplinare, che fino dal primo giorno condivida i problemi di competenza di tutti i comparti, in modo che tutti possano lavorare a risolverli e, quando nasce un conflitto, trovare insieme il compromesso più soddisfacente. Purtroppo sono poche le aziende organizzate in questo modo.”

Questo è uno dei topic più attuali nell’organizzazione di TwoReads e penso di qualunque azienda in cui non c’è ancora un processo di lavoro definito: la perdita di informazione e quindi di tempo data dall’assenza di figure chiave in determinati incontri o fasi. La mia idea è che ancora non ci sia modo di lavorare in maniera più efficace se non fianco a fianco, sopratutto nelle prime fasi, su questo tema mi trovo spesso a parlare con Giulio invece, che da buon project manager sta organizzando il nostro flusso di lavoro e di comunicazione.

“Un modo per semplificare il pensiero è usare modelli semplificati, approssimativi, dello stato reale delle cose. La scienza di occupa della verità, la pratica si accontenta di approssimazioni. Per agire non abbiamo bisogno della verità: ci bastano risultati relativamente rapidi che, sebbene imprecisi, siano “sufficientemente buoni” per lo scopo che ci interessa. […] per la maggior parte degli scopi una stima approssimata è accettabilissima. Tocca alle macchine rispondere ai problemi aritmetici. Le persone dovrebbero concentrare gli sforzi su questioni di livello superiore: per esempio, le ragioni per cui è necessario ottenere queste risposte.”

Qui invece ho pensato ad Andrea e a come il progetto è avanzato fino ad ora; è una continua approssimazione, sempre più scientifica e specifica ma comunque un’approssimazione; la parte più difficile è capire quale livello di approssimazione è accettabile e quale no in ogni fase, ma penso sia una cosa che impareremo, sbagliando:

“Il solo modo per ridurre la frequenza degli errori, infatti, è ammetterne l’esistenza, studiarli e quindi mettersi in condizione di intervenire per prevenirli in futuro. In assenza di dati, è quasi impossibile apportare miglioramenti. Invece di stigmatizzare chi denuncia un errore, dovremmo ringraziarlo e incoraggiare in tutti i modi la trasparenza. É necessario, perché lo scopo non è punire i responsabili, ma capire com’è avvenuto l’errore e cambiare le cose per evitare che si ripeta. […] è impossibile eliminare gli errori se non sappiamo quali sono.”

“Dobbiamo eliminare dal nostro vocabolario la parola insuccesso, sostituendola con esperienza di apprendimento. Non riuscire ci insegna qualcosa: impariamo più dai fallimenti che dai successi. Una buona riuscita certamente ci fa piacere, ma spesso non abbiamo la minima idea del perchè ce l’abbiamo fatta. Quando invece le cose vanno male si può capirne il perchè, così da evitarlo in futuro.” “Forse vi sorprenderà l’alta percentuale di fallimenti: è che non sono pubblicizzati, mentre si sente parlare solo dei rarissimi successi. La maggior parte delle start-up fallisce, ma nel mondo dell’high-tech californiano il fallimento non è considerato un male. È anzi un titolo d’onore: significa aver intravisto un potenziale futuro e averci provato, assumendosi i rischi del caso. Anche se l’iniziativa è fallita, i collaboratori hanno imparato delle lezioni che saranno preziose al tentativo successivo. Le ragioni del fiasco possono essere molte: il mercato non era ancora pronto, la nuova tecnologia non era ancora matura per il lancio commerciale, gli investimenti erano sufficienti.”

Più di metà del libro è dedicato agli errori; farli è inevitabile, bisogna solo trovare il modo di accorgersene, di capirli e di correggerli.

“[…] è questa combinazione fra uomo e macchina a creare esseri superpotenti. La tecnologia non ci rende più intelligenti, nè noi rendiamo intelligente la tecnologia. È la combinazione tra i due, la persona e l’artefatto, ad essere intelligente.”

“La combinazione uomo debole + macchina + processo forte si è rivelata vincente sul computer superpotente e, cosa ancora più significativa, sulla combinazione uomo forte + macchina + processo debole. […] La chiave per vincere non è competere contro le macchine, ma competere insieme con le macchine. Fortunatamente gli esseri umani sono più forti proprio dove i computer sono deboli, creando potenzialmente una bella collaborazione.”

Questi due paragrafi rappresentano esattamente l’idea e il nome TwoReads, due letture diverse, due lettori che leggono in modo complementare, un modo potenzia l’altro e viceversa.

Chiudo consigliando questo libro sia a chi come me inizia ad affrontare per la prima volta un progetto complesso, in cui i fattori necessari per arrivare al successo sono molti e diversi tra loro, sia a chiunque è interessato a capire perchè a volte è difficile aprire l’acqua di un rubinetto.

In particolare vorrei che lo leggessero tutti i componenti di TwoReads, perchè vengono spiegate molto bene le dinamiche di integrazione di competenze diverse all’interno di un unico progetto.

Dalla bibliografia mi sono segnato altre letture da fare in futuro per approfondire alcuni argomenti:

AG

Rispondi