IL GRANDE BLUFF DEI DESIGN SYSTEM

Nell’industria digitale è di gran moda parlare dei Design System (DS). La definizione di “unica fonte di verità per consentire alle organizzazioni di costruire prodotti e servizi” li rendono soggetti a grandi aspettative da parte degli addetti ai lavori. Le grandi organizzazione ostentano prodotti sviluppati grazie a un DS. Nella comunità dei designers è tutto un fiorire di profili LinkedIn che si auto-attribuiscono titoli di esperti, guru e portatori sani di trucchi e segreti per lo sviluppo di questa nuova arma definitiva.

Dopo avere letto dozzine di articoli, qualche libro e guardato ore di video sul tema, sono giunto alla conclusione che da un lato i Design System sono sopravvalutati da senior managers e decision makers e dall’altro utilizzati da molti designers per favorire iscrizioni a workshop e conferenze. L’effetto collaterale di questa baruffa è che agli utilizzatori dei prodotti e servizi digitali arriva poco o niente in termini di miglioramento della loro esperienza. Se guardiamo agli strumenti web come, ad esempio, i prodotti finanziari, quelli assicurativi e quelli della pubblica amministrazione, i problemi che da sempre affliggono gli utilizzatori (sia quelli finali sia quelli appartenenti alle organizzazioni stesse) restano lì vivi e vegeti. Molte sono le domande prive di risposte come ad esempio: che tipo di prodotto è stato sviluppato con quel particolare DS? Quante e quali persone ci hanno lavorato? Per quanto tempo? Quali sono i vantaggi oggettivi relativi dell’utilizzo di quel particolare DS paragonato ad altri strumenti?

Incoerenza dei modelli di interazione

Come progettista, la mia attenzione molto spesso cade su piattaforme professionali come quelle per la gestione di prodotti finanziari, quelle per il trading di materie prime etc
Uno dei principali problemi che riscontro quando ho accesso a questo tipo di prodotti è il livello di incoerenza tra le diverse interazioni sistema-utente. Non mi riferisco soltanto alla mancanza di omogenia relativa all’esperienza con i dispositivi mobili (mobile first è il bluff che ha preceduto quello dei DS), ma mi riferisco alle lacune evidenti nell’esperienza desktop. Notifiche, messaggi di sistema, moduli e gerarchie di azioni vivono nel caos grazie alla mancanza di un modello di sviluppo omogeno e sostenibile, cosa che dovrebbe essere gestita da un DS. L’utilizzo consapevole di questo strumento dovrebbe drasticamente diminuire queste lacune. La loro costante presenza, evidenzia che il DS non esiste o viene parzialmente utilizzato, magari per puri scopi estetici.

Eredità con le precedenti versioni dell’applicazione

Provate a immedesimarvi con professionista, ad esempio, un consulente finanziario che deve monitorare le opportunità di investimento dei propri clienti. In molti casi, questo utente, durante la sua esperienza d’uso, è costretto ad interagire con interfacce diverse da loro non solo dal punto di vista stilistico ma soprattutto dal punto di vista funzionale e di usabilità. Nella mia esperienza ho visto che questo fenomeno è dovuto alla fretta di rilasciare nuovi prodotti innestando selvaggiamente pezzi di codice provenienti da precedenti versioni. L’eccitazione relativa all’adozione di un DS spinge managers e team a modificare le parti più semplici del prodotto (ex il contenitore dell’applicazione) e di non toccare quelle più complesse (ex tabelle interattive). Il risultato è un Frankenstein che diventa più ingestibile e ostile ad ogni aggiornamento del prodotto. L’ utilizzo appropriato di un DS dovrebbe avere come primo effetto quello di facilitare la comunicazione all’interno del team, tra senior managers, responsabili del prodotto, ingegneri e progettisti per favorire una pianificazione.

Difficoltà a pianificare lo sviluppo nel medio e lungo termine

Tutto il baccano che si sta facendo attorno al tema dei DS ha come effetto collaterale la generazione di mostri digitali. È il risultato di una diffusa ansia da parte dei senior managers e decision makers nel precipitarsi ad integrare un DS nel processo di creazione dei prodotti. Questi personaggi, esposti a un bombardamento mediatico, in maniera ingenua, credono che l’arrivo di un DS nella loro organizzazione sia la panacea per tutti i mali. A complicare la situazione contribuisce il fatto che questi individui hanno un obiettivo ben chiaro, minimizzare i costi e massimizzare i profitti. Ragione per cui, spesso cadono nella trappola delle scorciatoie, tipo adottare un DS distribuito da terze parti, che nel medio e lungo termine porterà più danni che vantaggi. Le grandi organizzazioni operanti in settori complessi come la finanza, la gestione e distribuzione dell’energia e la grande distribuzione dovrebbero dedicare il giusto tempo e le giuste risorse per pianificare la strategia che meglio si adatti ai loro obiettivi di business. Nel corso degli anni ho più volte collaborato con organizzazioni che hanno optato per un DS distribuito da terze parti (ex. Google Material Design, IBM Carbon Design etc) la ragione principale di questa scelta era sempre la stessa, ridurre i costi di progettazione, specialmente quelli relativi alla ricerca e sviluppo relativa al design e andare rapidamente all’implementazione e alla distribuzione del prodotto. Facile intuire quale sia stata la strategia nel breve termine. Il DS è stato utilizzato per un progetto pilota, qualcosa di molto semplice e il cui rilascio in produzione non generi un grande impatto sulla famiglia di prodotti e non faccia saltare sulla sedia gli utenti. Ancora più facile intuire quale sia stato il risultato, la nuova versione dell’applicazione è una figata! Certo che lo è, soprattutto se il metro di paragone è il vecchio, obsoleto e ostile UI framework che non viene aggiornato da 10 anni! Ma provate ad indovinare cosa è successo appena si è iniziato ad adottare il DS per qualcosa di più complesso come ad esempio, una applicazione per la gestione delle attività gestionali di una banca. Credetemi, l’ultimo posto dove vorreste essere è la sala riunioni dove ingegneri, analisti, responsabili di prodotto, progettisti e senior managers devono prendere decisioni su come pianificare e gestire il crescente numero di personalizzazioni che il DS necessita per fornire un ragionevole rapporto di funzionalità e usabilità rispetto alla vecchia versione del sistema.

Conclusioni

Sono giunto alla conclusione che non è necessario un grande investimento per individuare la soluzione migliore. Basterebbe prototipizzare le funzionalità principali e/o le più complesse e individuare i pro e i contro delle varie opzioni a disposizione. 

Al solito, credo che il segreto sia avere un approccio pragmatico e onesto rispetto alle capacità e possibilità proprie dell’organizzazione. Noi progettisti abbiamo il compito di supportare colleghi e senior managers nel comprendere che strumenti come i DS sono cosa complessa. L’investimento che l’organizzazione ha pianificato o sta pianificando nel creare/scegliere un DS deve essere volto verso un unico obiettivo, dotare tutte le persone coinvolte nella realizzazione del prodotto di uno strumento condiviso in grado di facilitare l’innovazione e la manutenzione della famiglia di prodotti. Come effetto collaterale, l’organizzazione potrà ottimizzare i processi di produzione, risparmiare tempo e risorse preziose e aumentare i profitti grazie ad un maggiore velocità di esecuzione e a un’elevata capacità di rilasciare prodotti in grado di soddisfare le necessità dei clienti/utenti. 

Lunga vita ai Design System!

Image credits

Photo by Michał Parzuchowski on Unsplash

Back to the top