Systemic design ≠ Design systems
Che cos’è un design system? E perché è così importante? Me lo ha chiesto Designers Italia, la piattaforma di design per i servizi pubblici italiani. La risposta è affidata a questo guest post.
di Raffaele Boiano per Designers Italia
Cinque anni fa ho avuto la fortuna di partecipare al RSD Symposium, la conferenza dei ricercatori che si occupano di systemic design, organizzata a Oslo dal Dipartimento di Architettura e Design. Ricordo che arrivando trovai questa piccola sala in cui circa quaranta persone tentavano di acclimatarsi allo sbalzo termico di 25 gradi, alcuni case studies affissi alla buona in corridoio e i sorrisi tipici di una comunità di pratica nascente che si confronta su temi di frontiera.
Da allora la progettazione di sistemi ha fatto passi enormi, sia in ambito accademico che nelle applicazioni di diverse organizzazioni, siano esse istituzioni o corporation. L’influenza della teoria dei sistemi e la necessità di avere per base un gruppo sociale e non il singolo individuo hanno fatto sì che il systemic design si differenziasse progressivamente dallo user-centered design e dal tradizionale industrial design. Ma andiamo con ordine.
Systemic design è l’approccio di chi vuole affrontare le sfide della progettazione di sistemi nei quali si strutturano interdipendeze tra prodotti, servizi, processi e policy che hanno ripercussioni sociali. Ecco perché il systemic design ha tutte le carte in regola per assumere un ruolo chiave nella trasformazione digitale della pubblica amministrazione.
Harold G. Nelson e Erik Stolterman hanno scritto che gli esseri umani non hanno scoperto il fuoco, ma che lo hanno progettato. Il design non appartiene quindi al dominio della scelta dei colori, né della grandezza dei bottoni nelle interfacce software: progettare è un atto attraverso il quale associamo una serie di obiettivi a delle azioni che riteniamo favorevoli a raggiungerli. Se il nostro obiettivo è una mobilità sostenibile, potremmo progettare strade con carreggiate di un metro di ampiezza per impedire l’uso dell’automobile o mettere in campo altre strategie per andare incontro all’immagine che il team di design ha delle città del domani. Lo user-centered design è la disciplina in voga dell’era antropocentrica: niente è più naturale, tutto esiste perché c’è un’entità che ha orchestrato in touchpoint, vale a dire in punti di contatto, un’intenzione commerciale, istituzionale etc.
Il Politenico di Milano, dal 2005, propone un corso di Laurea specialistica in Product, Service & System Design e il Politenico di Torino nel 2012 ha aperto una laurea specialistica in Systemic Design. Sono segnali forti, un’ulteriore conferma che la direzione è matura.
Che significa adottare una prospettiva di systemic design per riprogettare il sistema operativo del Paese? Ecco due esempi concreti.
Costruire un design system
L’applicazione più immediata dell’approccio sistemico è quella che predica l’adozione di un design system, nuova estensione del concetto di design library.
Una design library è un catalogo coerente di componenti riusabili e interconnessi (moduli, bricks, chunks sono sinonimi). Un componente è un elemento che si ripete e che noi combiniamo con gli altri per rispondere in maniera coerente a un problema in un sistema specifico: user flows consolidati, modelli d’interazione, bottoni, campi di un form, icone, colori, tipografia, microcopy, una policy, una procedura etc. Come teorizzato da Christopher Alexander nel 1977, un design pattern è una soluzione generica applicabile infinite volte per risolvere lo stesso problema senza che ogni applicazione sia uguale alla precedente. Facciamo un esempio: premo sul bottone “Mi sento fortunato” di Google, capito su una pagina web a caso e voglio capire dove mi trovo. Posso cercare in alto a sinistra un logo che assegna identità a questo luogo.
Cercare in alto a sinistra un brand è una strategia di sense making comune per chi organizza la linearità del significante da sinistra a destra, dall’alto in basso. Anche se il pattern è lo stesso (“logo in alto a sinistra”), mille siti diversi avranno mille brand diversi con proporzioni e posizioni diverse. Per ognuno di questi mille contesti specifici c’è un pezzo di interfaccia in alto a sinistra che probabilmente è riusato in altre parti con delle variazioni: questo è un component. La relazione tra pattern è component è tutta qui: un component è un modulo di un’interfaccia con un look & feel definito mentre un pattern è una soluzione generica indipendente da qualunque visual style che può appartenere alla user interface o ad altri domini (una interazione come lo “swipe”, uno specifico comportamento delle persone come il “back” etc).
Costruire una design library, cioè un catalogo di componenti (ognuno con le proprie variazioni) e una serie di regole di applicazione e manutenzione è un investimento per garantire la coerenza del proprio sistema di touchpoints. Significa soprattutto poter progettare a prescindere dallo specifico canale per garantire rilevanza in ogni contesto d’uso.
Un design system estende il concetto di catalogo perché prevede una serie di regole e pratiche condivise per aggiornare e innovare questo set, definendo quindi un sistema di governance della design library.
Spotify nel 2014 ha creato GLUE (Global Language for a Unified Experience) dedicando un team centralizzato di designer e developers al mantenimento della design library e di un UI Kit. Visto che una design library è lettera morta senza coordinamento, il team centrale di Spotify si allinea settimanalmente con i team distribuiti per discutere dei progetti in corso e capire come innovare insieme GLUE.
Lo stesso investimento è stato fatto da molte altre aziende e organizzazioni. Ecco una bella gallery di design libraries. Se avete poco tempo, date uno sguardo al lavoro fatto per costruire design system degli USA.
Design come attività per includere
Aggiungiamo un altro ingrediente: la teoria della complessità. Complicato e complesso non sono sinonimi. Complicato deriva dal latino complicare, e indica qualcosa di piegato, annodato. Una situazione è complicata quando si presenta in maniera non chiara, senza che si possano intuire immediate relazioni causa-effetto. Sciogliere questo nodo è sicuramente faticoso, ma esiste comunque una soluzione anche se non è immediatamente visibile: un problema complicato può essere scomposto e ridotto a qualcosa di più semplice.
Complesso invece deriva dal latino complexus, ossia qualcosa di inestricabile, composto da una parti intrecciate e interdipendenti fra loro (toh, un sistema!). Un problema è complesso perché l’intreccio di elementi che interagiscono fra loro non ci permette di individuare alcuna relazione causa-effetto (e non ha senso cercarne). In una situazione complessa la scelta di individuare e gestire tutte le variabili in gioco è sostanzialmente perdente, così come è impossibile prevederne gli sviluppi. Un problema complesso non può essere affrontato con l’euristica della scomposizione in fattori al fine di trovare una soluzione univoca, ma necessita di essere considerato globalmente.
Chi progetta prodotti e servizi immersi in un contesto complesso, quindi, non può avere l’ambizione del controllo del sistema stesso, e questo è un bene. Segna il tramonto definitivo del designer come deus ex machina, star che si arroga il diritto esclusivo di creare. Anche il processo di prenotazione di un esame medico o il voice responder del numero verde di un CUP (Centro Unico di Prenotazione) sono parti di un sistema che ha reciproche interazioni, una sua autopoiesi e una buona dose di resistenza al cambiamento.
Ripensare il ruolo dei designer non come il fulcro dell’attività di progettazione ma come partecipanti di un team di progetto più allargato (cittadini, analisti di business, esperti di organizzazione, developers, legali etc) è in linea con l’idea che l’innovazione portata da questi progetti dovrà interagire con altre componenti di un sistema complesso e che quindi il risultato finale non è né predeterminabile né stabile.
Chi vuole portare innovazione all’interno di un sistema complesso deve rimuovere lo steccato tra il team di progetto e chi “usa” o consuma i prodotti o i servizi ri-progettati: una nuova generazione di designer è consapevole che ognuno di noi non è che un partecipante di un sistema che semplicemente non ha un centro. Abbiamo appena visto che costruire una design library è un’attività costosa e sostanzialmente inutile se non è accompagnata da una governance che ne garantisca applicazione e mantenimento.
Il successo di un team di trasformazione digitale si gioca sull’abilità di includere altre parti del sistema complesso e motivarle a partecipare, co-costruendo prodotti, servizi e piattaforme partendo da intenzioni comuni. Se siete confusi e volete un esempio concreto di quello di cui abbiamo parlato vi consiglio di scoprire come è stato progettato USCIS (U.S. Citizenship and Immigration Service) dal racconto che ne fa Dana Chisnell.
