Sviluppare un design system: cosa avremmo voluto sapere prima

Dopo aver affrontato il caos dei componenti duplicati, della continua ristilizzazione degli elementi dell’interfaccia e della proliferazione incontrollata delle varianti, è tipico che in un’azienda inizi a serpeggiare l’idea di costruire infine un design system.

Prima però di illudersi di avere finalmente ordine, coerenza e la vita facilitata dai componenti già pronti, vale la pena chiarire quali siano effettivamente i benefici nel costruire un design system e quando veramente valga la pena farlo.

Che cos’è un design system

Prima di decidere se sia il caso o meno di creare un design system, capiamo bene di cosa stiamo parlando. Il design system è una raccolta di componenti (es. bottoni, menù, select, ecc.) , che possono essere riutilizzati all’interno di diversi prodotti digitali.

Ciascun elemento è accompagnato da un set di proprietà, come colore e dimensione; alcune di queste sono specifiche del componente, mentre altre sono comuni a tutto il design system.

Da cosa è composto un design system?

Tipicamente, i diversi elementi che compongono un design system possono essere ricondotti a tre tipologie:

Organizzare un design system con un modello di atomic design presenta dei vantaggi sia a livello di interazione tra team (ad esempio, avere una nomenclatura comune), ma anche per il riutilizzo dei componenti; se, per esempio, il design system viene aggiornato con nuovi colori, la modifica applicata al solo livello atomico si rifletterà anche sui livelli superiori.

Non solo una questione estetica

Il design system non ha il solo scopo di creare elementi esteticamente piacevoli. Un design system che si rispetti, infatti, oltre alla UI si occupa di gestire anche aspetti della UX come logiche di comportamento e accessibilità.

Alcuni esempi delle questioni che vengono gestite tramite la costruzione di un design system sono:

• Stato di caricamento, ad esempio nel pulsante
• Stato di disabilitazione
• Gestione dell’errore negli elementi dei form
• Controllo degli elementi da tastiera, incluso focus visibile
• Lettura da screen reader
• Ordinamento e filtraggio per componenti complessi, come le tabelle

Un buon design system, dunque, non è solo visivamente perfetto, ma anche efficiente. Se una persona con disabilità non riesce ad utilizzarne gli elementi, per esempio, il sistema ha fallito il suo scopo.

Perché scegliere di usare un design system?

Ma perché dovremmo scegliere di creare un design system e attenerci a quello? Non si tratta forse di una limitazione della creatività dei nostri designer? Parzialmente, ciò è vero. Quando si sceglie di sviluppare un design system, non è conveniente poi rivedere da capo tutti i componenti per ogni progetto e perciò c’è una tendenza all’omogeneità.

Dalla prospettiva opposta, però, si tratta di un investimento strategico che impatta su tempistiche e costi di sviluppo a medio-lungo termine. I vantaggi che questo comporta, infatti, sono principalmente due:

• Accelerare il lavoro di designer e sviluppatori nella creazione di nuove piattaforme, creando una base condivisa.
• Ridurre inconsistenze e duplicazioni tra i componenti e agevolare il sistema di riferimento tra design e codice.

Sembra quindi che sviluppare un design system abbia considerevoli benefici, ma la verità è che si tratta di una decisione da non prendere sotto gamba. Costruire bene il design system è infatti un’operazione che può richiedere mesi di lavoro e che non termina con l’ultimazione di questo, ma richiede continuamente di essere mantenuto e perfezionato.

Un design system è una scelta adeguata specialmente per le aziende di prodotto, che sviluppano prodotti interni dai caratteri riconoscibili. Più difficilmente può essere impiegato dalle aziende di consulenza, che si attengono invece alle specifiche fornite dai vari clienti.

Se fatto con tutti i crismi, lo sviluppo di un sistema comporta miglioramenti in termini di time-to-market e di coerenza di esperienza, con un impatto che si riflette sulla redditività del prodotto finale. Vale quindi la pena di sviluppare il design system?

Quali sono le difficoltà nel creare un design system

Lo sviluppo del design system comporta inevitabilmente delle sfide di cui è bene essere consapevoli prima di cimentarsi nell’impresa. Ci sono infatti delle domande cardinali da porsi prima ancora di prendere in considerazione l’idea: 

• Il team (sia di design che di sviluppo) è disposto a prendersi la responsabilità di costruire e mantenere il sistema?
• Si è tenuto conto, nella valutazione dei tempi e costi, anche dell’investimento richiesto per documentare e adottare il sistema, oltre a quello per scrivere il codice?
• L’investimento è giustificato dal contesto (es. vengono sviluppati molti prodotti, i componenti vengono riutilizzati spesso e ci lavorano più team) oppure è più conveniente sviluppare componenti ad hoc di volta in volta o, eventualmente, utilizzare una libreria di UI?

Ma vediamo più nel dettaglio quali sono le potenziali difficoltà a cui si va incontro quando si sceglie di sviluppare un nuovo design system.

Da Figma al codice: i team devono essere allineati sul design system

Una problematica che può insorgere è quella di uno scarso allineamento tra team. Ad esempio, è possibile che il design system venga progettato, sviluppato ma che poi cada in disuso, totale o parziale.

Questo può succedere perché i nuovi componenti vengono disegnati da zero, senza tener conto di ciò che già esiste, o perché sebbene a design siano presenti i componenti del design system questi non vengono usati poi in fase di programmazione.

Perché avviene ciò? Spesso la motivazione risiede nelle diverse aspettative dei membri dei vari team. Per affrontare e prevenire questo problema vanno quindi messe in atto delle strategie volte al coinvolgimento di tutti coloro che verranno toccati dalla scelta di utilizzare un design system. 

Ad esempio, si possono organizzare sessioni di feedback durante la prima fase di elaborazione del design system, in modo da allineare i vari team, ed eventualmente anche mostrare una panoramica del risparmio ottenuto grazie all’impiego di un design system.

Un'ulteriore soluzione è quella di stabilire un buon modello di governance, cioè decretare a priori chi ha potere sulle modifiche al design system e su tutti gli aspetti che lo riguardano (come la denominazione dei componenti e delle loro proprietà, la scelta delle funzionalità che devono essere incluse, ecc.).

Infine, è utile tenere una documentazione dell’intero processo. Se lo sviluppatore o il designer di turno non sanno dell’esistenza dei componenti o non sanno come usarli, naturalmente è difficile che vi facciano ricorso. Per questo, è importante stabilire una fonte di verità che possa essere consultata per sapere quali sono le best practice nelle occasioni che si presentano.

Il costo reale di un design system: manutenzione e scalabilità

Come per qualsiasi software, il design system non è un prodotto confezionato e concluso, ma un organismo vivo, che richiede una manutenzione continua. Può per esempio essere necessario aggiornare le dipendenze, supportare nuovi framework o allinearsi a nuove regole di accessibilità.

Il management del design system incide molto sui costi di sviluppo e va tenuto in conto, anche nell’onboarding del team di sviluppo. Se l’impegno viene sottovalutato, ci si ritrova presto con un sistema obsoleto e, di conseguenza, inutilizzato. Mettere sul piatto quest’aspetto fin da subito può aiutare a scegliere con maggior coscienziosità se imbarcarsi in questa sfida.

Un ulteriore problema è quello della scalabilità nel tempo. Con l’utilizzo, è normale che i componenti si moltiplichino, col rischio di ritrovarsi con lo stesso sistema caotico da cui si voleva inizialmente sfuggire. 

Per prevenire che ciò avvenga, è buona norma  denominare gli elementi in maniera da poter distinguere le loro versioni (es. experimental, beta, stable, ecc.). Altrettanto importante è indire audit periodici in cui rimuovere o unificare i componenti e deprecare quelli vecchi. Ogni scelta in questo senso dovrebbe essere guidata dalle metriche, e in particolare dal numero di adozioni dei singoli componenti e dal tempo di shipping risparmiato.

Come si sviluppa un buon design system

Quali sono gli step concreti per costruire un design system solido? E come stabiliamo se il design system è un buon design system? Rispondiamo a queste domande, una alla volta.

Scegliere la base di partenza

Stabilire un punto d’inizio è come scegliere il colore del pavimento di una stanza da rinnovare: è una scelta minima, ma incide largamente sull’effetto finale. Nella maggior parte dei casi, la scelta migliore è quella di utilizzare soluzioni già esistenti e adattarle.

Ciò significa adottare librerie già esistenti da personalizzare al bisogno, sfruttando il fatto che siano già testate da utenti e sviluppatori, accessibili e dotate di una logica solida. 

Esistono due tipologie di librerie che possono essere impiegate (e varie sfumature nel mezzo):

• Le librerie headless, come React Aria di Adobe o Radix UI, offrono tutta la logica, l’accessibilità e la gestione degli stati, ma non hanno alcuna stilizzazione associata in partenza, o quasi.
• Le librerie stilizzate, come shadcn o MUI, possono essere adattate al proprio brand, ma allo stesso tempo offrono componenti già stilizzati, utili specialmente quando l’obiettivo è impiegare il minor tempo possibile per andare in produzione.

La scelta dell’una o dell’altra soluzione dovrebbe essere presa in accordo tra i team e dipende soprattutto dal contesto: quanto si allontana il design system elaborato da quelli standard? E quanto è importante un veloce ingresso sul mercato? Ogni situazione è a sé.

Documentare e testare a ogni step di sviluppo

Man mano che il design system viene sviluppato, è importante verificare il comportamento dei componenti con regolarità, in modo da non ritrovarsi a fine processo con bug e funzionamenti inaspettati e con la difficoltà di risalire all’origine del problema.

Fondamentale è anche la documentazione del lavoro svolto. La documentazione, idealmente, va trattata come un prodotto a sé, con queste caratteristiche:

• Dev’essere filtrabile e navigabile
• Deve contenere esempi reali di utilizzo e snippet
• Deve fornire tutte le note tecniche necessarie, le indicazioni su come vada usato (e non usato) il componente

Per ottenere una buona documentazione, può essere utile usare tool appositi come Storybook. 

È di massima importanza che la documentazione rimanga sempre aggiornata. Sebbene sia facile sottovalutarne la portata, una documentazione mediocre, ad esempio statica e prolissa, senza casi d’uso e note sull’utilizzo, diventa inutile e, conseguentemente, inutilizzata.

Tips pratici per costruire bene il design system

Durante la fase di sviluppo, cosa bisogna tenere a mente per costruire un buon design system? Innanzitutto, bisogna fare affidamento in toto ai già citati design tokens. Questi saranno la base da cui tutto verrà generato, che rende facili da gestire rebranding, temi light e dark e l’eventuale rilascio di prodotti in white-label. 

Poi, è importante scegliere buone API e mantenerne la consistenza. Quanto è destabilizzante quando un componente viene disabilitato dalla prop disabled e un altro da isDisabled? O quando anziché l’attesa size si trova qualcosa come dimensions? 

Al di là del buonsenso, è essere coerenti e allinearsi tra i membri del team, in modo da non incorrere nell’errore di avere nomenclature multiple e inconsistenti.

Nella costruzione dei singoli elementi, bisogna poi tener conto della componibilità: anziché costruire monoliti iper-configurabili ma difficili da utilizzare, meglio ricorrere a elementi più leggeri che possono facilmente combinarsi tra loro e venir estesi. 

Il pragmatismo è fondamentale in questo caso: una volta coperti i casi d’uso più comuni, eventuali estensioni possono arrivare solo quando se ne presenta la necessità reale. Anche se sarebbe bello poter prevedere tutti i casi subito, spesso ciò comporta una complessità non necessaria e lunghi tempi di sviluppo.

Infine, va tenuto presente anche il contesto di setup: più è rapido e intuitivo, più sarà probabile che il design system venga utilizzato e aggiornato.

Come giudicare se un design system è “buono”?

Quale metrica ci indica se abbiamo fatto un buon lavoro nello sviluppare il nostro design system? La developer experience è la metrica che conta davvero. Infatti, lo scopo di sviluppare un design system è quello di rendere veloce e sicuro costruire nuove feature. Se lo sviluppatore è soddisfatto e passa poco tempo a combattere contro il CSS avrà più tempo per pensare alla UX e per comporre nuove feature.

Per il resto, sarà il tempo a dire se un design system è buono: se viene utilizzato, sia dai designer che dagli sviluppatori, mantenuto e soddisfa l’utente, allora probabilmente è un buon design system.

E tu, stai pensando di lanciarti in quest’avventura e costruire il tuo design system aziendale? Facci sapere se possiamo aiutarti. Il nostro team di design è a disposizione per una call conoscitiva gratuita in cui mette a disposizione le proprie competenze per aiutare a costruire un brand coerente ed efficace. Se vuoi un suggerimento, non esitare a chiamarci.