Le tre fasi del design: abduzione, deduzione, sintesi

Nota: questo post è stato modificato il 29.4.20 per accogliere il giusto invito di Domenico Polimeno a descrivere con il termine “abduzione” la logica che utilizziamo nella prima parte di un progetto (originariamente avevo usato “induzione”).

Progettare un ambiente informativo è fare una sintesi fra gli obiettivi degli stakeholders, i bisogni delle persone, le soluzioni e le risorse disponibili. Ma questa sintesi è l’atto che conclude un progetto e deve essere preceduta da due fasi di lavoro distinte e complementari: la prima, costituita dalla ricerca sulle persone e gli stakeholders, è basata su un procedimento induttivo; la seconda, quella in cui si definiscono le funzioni del sistema, è basata su un processo deduttivo.

Nella ricerca osserviamo singole persone, ne cogliamo i bisogni, gli ambienti in cui vivono e sfruttiamo una logica abduttiva per radunare tutto questo in classi, cioè in insiemi che presentano caratteristiche comuni. Con tecniche induttive, come il card sorting ad esempio, definiamo i modelli mentali e le aspettative delle persone. Il risultato di questo lavoro ci porta a definire ciò che comunemente chiamiamo personaggi (personas, in inglese), gli scenari in cui questi personaggi si trovano ad interagire, le storie (user stories), cioè le narrazioni che descrivono chi compie qualcosa, ciò che compie e per quale fine lo fa, e le tassonomie, le poligerarchie, le faccette, cioè i criteri con i quali classificare le informazioni presenti nel sistema. Sempre per abduzione, comprendiamo quali azioni debba compiere il sistema (blueprints) all’interno di ogni punto di contatto (touchpoint) e quali altre azioni saranno necessarie per collegare i punti di contatto fra loro. Analogamente comprendiamo gli obiettivi dei vari portatori di interesse (stakeholders), attraverso vari incontri e sessioni di co-working, e tendiamo il più possibile a organizzare questi obiettivi in classi omogenee.

La prassi che viene seguita di solito prevede che, terminato il processo descritto, si faccia una sintesi di quanto emerso definendo l’aspetto che avranno i vari punti di contatto fra il sistema e le persone (comprese quelle che lavoreranno alla gestione e alla manutenzione del sistema stesso) attraverso wireframes, storyboards e prototipi.

Ho lavorato a lungo così, ma nel tempo mi sono reso conto che immaginare la struttura, la logica e l’aspetto finale di un sistema complesso basandosi principalmente su un processo induttivo presenta moltissimi punti deboli.

Innanzitutto, bisogna tenere conto che questo modo di lavorare è nato in un momento storico in cui la realtà fisica era nettamente distinta dalla realtà virtuale, che poi era costituita sostanzialmente da siti web. Di conseguenza, l’intero processo di progettazione era orientato più ad ottimizzare che a creare. Lo conferma il fatto che i primi studi strutturati nella nostra disciplina sono stati compiuti su come fare la differenza di un business digitale migliorando l’usabilità del suo sito web, facendo in modo che aderisse ai modelli mentali e ai processi cognitivi degli utenti ai quali è destinato. Per questa ragione siamo diventati molto bravi ad osservare i successi e le frustrazioni delle persone rispetto ai loro obiettivi individuali in ambienti noti, abbiamo sviluppato tecniche euristiche, abbiamo imparato a realizzare prototipi rapidamente e a condurre test di usabilità.

Il secondo problema è che passare direttamente dalla fase induttiva a quella di definizione delle interfacce costringe la squadra di progettisti a maturare l’idea del quadro complessivo del sistema definendo un punto di contatto dopo l’altro. Ho lavorato spesso così su progetti semplici, che si svolgevano in un unico ambiente, ma appena ho dovuto affrontare la progettazione di sistemi complessi, pervasivi, cross-canale, ho perso la visione complessiva di quello che stavo facendo e ho dedicato un tempo eccessivo a funzionalità che ho capito dopo essere marginali o, peggio, superflue. Soprattutto quando ho dovuto progettare meta-sistemi, cioè sistemi in grado di collegare e tenere assieme vari sistemi esistenti, il metodo induttivo non è stato in grado di consegnarmi un apparato concettuale abbastanza solido e trasversale da poterci costruire sopra una buona architettura dell’informazione.

Infine, non è facile coinvolgere gli stakeholders in modo costante nel processo induttivo, fatta ovviamente eccezione per la fase che li riguarda direttamente: per farlo ci vuole un notevole dispendio di tempo e di risorse. D’altro canto, coinvolgerli solamente nella fase di definizione delle interfacce espone la squadra di progettazione al rischio che essi comprendano solo in quel momento l’esito verso il quale ci si sta dirigendo e che -di conseguenza- alcune eventuali obiezioni importanti emergano solamente nella fase finale del percorso generale di progettazione.

Col tempo ho avvertito dunque la necessità di introdurre uno specifico lavoro sulle funzioni del sistema fra la fase induttiva e quella di sintesi finale. In questo lavoro, per prima cosa si deve definire la funzione fondamentale dell’intero sistema. Il modo migliore di farlo è attraverso un lavoro di co-design che coinvolga tutti gli stakeholders. Questa infatti è la funzione che il sistema nel suo complesso dovrà svolgere per raggiungere gli obiettivi degli stakeholders, soddisfacendo i bisogni principali dei suoi utenti.

Da questa funzione principale, seguendo un processo deduttivo che vedremo nel dettaglio nel prossimo capitolo, devono essere derivate le macro-funzioni necessarie a soddisfare i bisogni e possibili tenendo conto dei vincoli emersi nella fase induttiva. Ognuna di queste macro-funzioni viene poi suddivisa nelle sue specifiche sottofunzioni, continuando il processo fino ad un grado di granularità giudicato sufficiente dalla squadra di progettazione a chiarire tutti gli aspetti necessari a realizzare il sistema. Attraverso le sotto-funzioni, infatti, si definisce nel dettaglio ciò che il sistema deve compiere nei diversi luoghi in cui si articola e ciò che deve compiere per trasportare informazioni fra un luogo e l’altro. In altre parole, le sotto-funzioni tornano a descrivere ciò che nella prima fase abbiamo chiamato touchpoints e blueprints, ma questa volta giungendo ad essi attraverso un processo deduttivo.

È proprio a questo punto del progetto che il braccio induttivo e il braccio deduttivo della tenaglia del designer si toccano ed è possibile procedere con la sintesi finale.

Il processo deduttivo con il quale definiamo le funzioni di un sistema ci offre quindi diversi vantaggi:

· garantisce infatti una visione complessiva e coerente del sistema, anche quando esso è in contatto con le persone attraverso touchpoint diversi e di diversa natura

· consente di procedere nel lavoro assieme agli stakeholders con uno sforzo contenuto. Nel definire le funzioni in modo collaborativo, gli stakeholders non perdono mai il controllo sull’esito del progetto, sono meno propensi a moltiplicare le richieste di dettaglio poiché colgono il valore della coerenza complessiva del sistema e sono in grado formarsi un’idea della forma che esso assumerà, allo stesso tempo di chi progetta. Il lavoro di sintesi che verrà compiuto sui touchpoint, per questa ragione apparirà loro come una naturale conseguenza di ciò che si è deciso assieme.

· porta alla luce l’eventuale necessità di costruire nuovi ambienti e nuovi punti di contatto rispetto a quelli emersi nella fase di ricerca e ce ne restituisce le caratteristiche principali alla luce del sistema generale in cui sono inseriti

· permette di gestire la complessità, perché nel definire le funzioni e le sotto-funzioni ci rendiamo conto immediatamente se stiamo definendo al contempo un numero eccessivo di entità e possiamo intervenire per semplificare

· ma soprattutto ci permette di escludere ogni requisito che non sia necessario, cioè orientato al raggiungimento della funzione principale, aiutandoci a realizzare un sistema essenziale e limitando i tempi necessari alla sua realizzazione