In questo articolo forniremo la nostra definizione di Design System e affronteremo alcune delle idee sbagliate più comuni su questo argomento. Il nostro obiettivo è aiutarti a rispondere alla domanda "Il tuo Design System è davvero un Design System?"
Gabriele Petronella I Design System sono diventati una soluzione molto diffusa tra le aziende che vogliono migliorare l’efficienza e la coerenza del proprio processo di design. Tuttavia, anche se molte organizzazioni sostengono di avere un Design System, nella realtà spesso non hanno chiaro cosa implichi davvero averne uno.
In questo articolo condividiamo la nostra definizione di Design System e affrontiamo alcune delle idee sbagliate più comuni su questo tema. Approfondendole, speriamo di aiutarti a rispondere alla domanda “Il tuo Design System è davvero un Design System?” e di fornirti spunti utili per ottimizzare il workflow di design della tua azienda.
Secondo il Nielsen Norman Group, un Design System è una collezione di componenti riutilizzabili, guidati da standard chiari, che possono essere combinati per costruire un numero qualsiasi di applicazioni.
In altre parole, è un insieme di principi, strumenti e componenti che permettono di creare un’esperienza utente coerente tra diversi prodotti. Questo consente ai team di progettare prodotti di alta qualità in modo più rapido, testare soluzioni e iterare facilmente. Inoltre, un Design System aiuta a ridurre i tempi di sviluppo, perché i team non devono ricreare gli stessi componenti da zero ogni volta.
Tutto molto bello in teoria. Ma cosa significa concretamente?
Il concetto di Design System è ancora relativamente nuovo, e ne esistono molte interpretazioni. Per questo riteniamo fondamentale definire la nostra visione di cosa sia un Design System e perché potresti averne bisogno.
Esploriamo quindi la visione di buildo su un Design System per capire perché si tratta di qualcosa di ben più complesso di un semplice framework per creare esperienze utente coerenti tra più prodotti. Parleremo dell’importanza della relazione tra design e sviluppo, della governance di un Design System, del concetto di estensibilità senza perdere coerenza, di accessibilità e di molti altri elementi che, insieme, sbloccano il vero potenziale di un Design System.
Prima di addentrarci nei concetti più profondi di un Design System, partiamo dalla superficie, con il famosissimo concetto di Component Library, uno degli elementi fondamentali di un DS. Una Component Library è una collezione di elementi UI, come bottoni o form, usati per costruire esperienze utente coerenti in diversi prodotti.
Le Component Library sono ormai molto diffuse, e potresti già usarne una. Quindi potresti pensare: “Sto usando una Component Library, quindi ho un Design System, giusto?”. Beh, dipende. Per prima cosa, la Component Library è solo una delle parti chiave di un Design System.
Inoltre, per funzionare davvero all’interno di un DS, una Component Library deve avere caratteristiche ben precise, a partire da aspetti legati alla governance, come la relazione tra designer e developer, fino ad arrivare a temi più pratici come estensibilità e accessibilità. Ma non perdiamo tempo con le introduzioni e andiamo subito al primo tema: la relazione tra designer e developer.
Il risultato ideale si ottiene grazie a una collaborazione bilanciata tra team di design e sviluppo. Questo richiede un approccio sinergico e sincronizzato, in cui i team condividono responsabilità in tutte le fasi. Non si tratta di una staffetta in cui i designer consegnano un prototipo e i developer lo implementano come meglio riescono. È una corsa affiancata, in cui designer e developer lavorano insieme con gli stessi strumenti e lo stesso linguaggio per costruire la migliore UI e UX per l’utente finale. Una comunicazione efficace e una visione condivisa sono essenziali per ottenere questo risultato.
È quindi fondamentale che gli asset di design (come una libreria Figma o Sketch) e quelli di sviluppo (come una libreria React.js o Angular) vengano progettati ed evoluti insieme, come istanze diverse dello stesso concetto.
Devono parlare la stessa lingua e permettere al developer che usa la libreria di trovare una corrispondenza perfetta con ciò che è stato progettato nel Design System.
Questo è l’aspetto cruciale che rende un Design System un acceleratore di produttività per la UI e garantisce che la coerenza visiva non si fermi al mockup.
Uno degli errori più diffusi è considerare il Design System una risorsa “solo per designer”, lasciando ai developer il compito di trovare soluzioni alternative per l’implementazione.
Un esempio concreto di questo scenario potrebbe essere un’azienda che sta sviluppando una nuova web app.
Il team design realizza prototipi e mockup ad alta fedeltà utilizzando uno strumento come Figma, includendo un set completo di componenti per l’interfaccia utente dell’app. Il prototipo è stato creato seguendo la documentazione del Design System, che definisce la tipografia, la palette colori e le altre linee guida di design. Tuttavia, il Design System non tiene conto delle tecnologie che i developer useranno per implementare l’applicazione.
Una volta finalizzati i design, tocca al team di sviluppo costruire l’app. I developer, com’è naturale, non reinventano ogni componente da zero: per velocizzare, potrebbero affidarsi a una libreria UI generica come Material UI, sperando di poter personalizzare i componenti per rispecchiare il design.
Ma presto si rendono conto che i componenti di Material UI non corrispondono esattamente (1:1) a quelli progettati. Devono dedicare più tempo del previsto a “forzare” la libreria per adattarla. Incontrano anche problemi di coerenza e accessibilità, perché i componenti di Material UI non seguono le stesse linee guida e standard definiti nel design.
Il risultato? L’interfaccia finale non è rifinita né coerente quanto avrebbe potuto esserlo, e l’intero processo di sviluppo diventa molto più lungo e costoso. Questo esempio evidenzia quanto sia importante che designer e developer lavorino insieme e che un Design System sia costruito considerando l’intero processo di sviluppo dell’app, dall’inizio alla fine.
Per garantire la coerenza, è fondamentale che tutti i componenti UI che compongono la Component Library siano costruiti a partire da fondamenta comuni. Queste fondamenta includono tipicamente palette colori, sistema di spaziatura, tipografia e altri aspetti “di basso livello”. Disporre di un set solido di foundations e costruire i componenti sopra di esso è ciò che trasforma un design system in un sistema.
Uno degli errori più comuni che osserviamo sul campo è costruire librerie di componenti senza aver prima definito le foundations. In questi casi, nello scenario migliore si ottiene una coerenza visiva solo a costo di uno sforzo elevato, perché ogni nuovo componente parte da zero. Nel peggiore dei casi, la coerenza si perde progressivamente man mano che vengono aggiunti nuovi componenti alla libreria.
Facciamo un esempio: supponiamo di introdurre un nuovo componente nella nostra libreria che richiede del padding. Se il Design System è dotato di un set adeguato di foundations, sappiamo che possiamo utilizzare uno dei valori predefiniti di spaziatura (es. 0, 2, 4, 8, 16, 24 o 32 pixel). Ne scegliamo uno, e siamo certi che sarà coerente con il resto dei componenti, poiché tutti utilizzano la stessa scala di spaziatura. Se invece non abbiamo foundations, potremmo scegliere un valore arbitrario (es. 5px) che magari funziona per quel componente singolo, ma che genera incoerenze quando lo si combina con altri componenti che usano valori diversi.
Come abbiamo visto, un set solido di foundations garantisce la coerenza tra i componenti di una libreria. Ma la vera forza emerge quando queste foundations sono accessibili anche agli utenti del Design System.
Una Component Library include in genere componenti standard come bottoni, modali, toggle e disclosure. Tuttavia, quando si applica il sistema a casi d’uso reali, emergono esigenze specifiche di dominio che devono essere considerate. Ad esempio, potresti avere bisogno di implementare una card ricorrente nelle tue applicazioni.
In questi casi, la Component Library originale deve essere completata con componenti UI specifici per il tuo prodotto, che per questo motivo vivono al di fuori del Design System vero e proprio. Un set di foundations è realmente efficace solo se consente di costruire nuovi componenti che sembrano integrati nativamente nel Design System, sia per aspetto che per comportamento.
Ad esempio, se le foundations sono esposte in modo diretto, i componenti personalizzati possono usare lo stesso sistema di spaziatura, gli stessi colori e la stessa tipografia dei componenti del Design System. Questo non sarebbe possibile se la libreria esponesse solo i componenti finiti, senza accesso alle foundations sottostanti.
Le foundations giocano un ruolo fondamentale anche in tema di accessibilità. Si tratta di un ambito complesso, che richiede attenzione lungo l’intero ciclo di sviluppo del prodotto. Tuttavia, ci sono aspetti che possono essere centralizzati e gestiti all’interno dei confini di un Design System.
Le foundations possono essere progettate in modo da prevenire alcuni errori comuni legati all’accessibilità, per esempio:
Anche se le Component Library sono estremamente utili, possiamo spingere il concetto di Design System ancora oltre. Lo scopo ultimo di un Design System è facilitare la creazione di interazioni coerenti e familiari per l’utente finale. A volte questo obiettivo si raggiunge attraverso i componenti stessi (ad esempio, usando lo stesso componente Button su due prodotti). Altre volte, invece, è necessario condividere elementi più complessi: pensa a concetti come “il modo in cui vengono presentati alert e notifiche” o “il modo in cui è strutturata la navigazione”. Questi sono concetti che l’utente finale si aspetta siano coerenti, ma che non si traducono in componenti da usare direttamente da una libreria. Li definiamo “UX patterns”, o più semplicemente “pattern”.
Il compito di un Design System è quello di creare un repository centrale per questi pattern e renderli accessibili a designer e developer diversi, così da poter riutilizzare la conoscenza e l’esperienza accumulate nei progetti precedenti.
Ultimo, ma non per importanza: possiamo avere tutto quello che abbiamo descritto finora, ma a cosa serve se non esiste un modo per farlo evolvere? Anche il miglior Design System è destinato a degradarsi nel tempo se non c’è un team o un processo per mantenerlo aggiornato.
Introdurre un Design System non significa solo creare un insieme di asset, ma soprattutto cambiare il modo in cui pensiamo e organizziamo il lavoro legato alla delivery di prodotti digitali. In questo senso, per esperienza diretta, un Design System funziona solo se ha processi e un team propri.
In un Design System è indispensabile avere almeno un designer (solitamente un interaction/visual designer) e uno sviluppatore front-end. Come abbiamo già sottolineato, è fondamentale che design e sviluppo procedano in parallelo, altrimenti gran parte dei benefici viene persa.
Per esperienza, se non si progettano con attenzione team e processi attorno al Design System, può succedere che alcuni team utilizzino una libreria condivisa che evolve in modo estemporaneo, caso per caso, gestita da tutti i team di prodotto senza una ownership centrale.
Nel lungo periodo, questo porta a librerie incoerenti, pensate per rispondere ai bisogni di una singola applicazione, e che tendono rapidamente a diventare obsolete.
Potresti pensare: “il nostro team è troppo piccolo, non possiamo permetterci di dedicare persone a questo.” È un dubbio comune e legittimo. Per esperienza, è estremamente vantaggioso strutturare un team dedicato al Design System, con processi e asset separati rispetto ai team prodotto, anche quando le stesse persone lavorano su entrambi.
Questa separazione dei ruoli e delle responsabilità rende il lavoro più chiaro e meno ingarbugliato, anche se i membri del team ricoprono più ruoli contemporaneamente.
I processi che nessun team di Design System può permettersi di trascurare riguardano sia la sfera interna al team sia quella esterna.
I processi interni includono:
I processi esterni riguardano come:
È molto importante che i processi esterni siano chiaramente comunicati e ben documentati per tutti gli utenti del sistema. Ad esempio, anziché dire semplicemente “Contattaci se hai un problema”, è preferibile essere più precisi: “Apri un ticket su questa board Jira…, includendo queste informazioni…, riceverai una risposta entro X giorni, e daremo priorità in questo modo…”.
Abbiamo parlato degli elementi che generalmente dovrebbero essere presenti in un Design System, ma questo non significa che siano gli unici.
Un Design System raccoglie conoscenza e risorse per supportare la delivery di prodotti in modo efficace e coerente. In quest’ottica, sentiti libero di includere qualsiasi altra cosa che possa aiutarti a raggiungere questo obiettivo. Alcuni esempi sono:
In conclusione: il tuo Design System è davvero un Design System?
Un Design System è un insieme di principi, strumenti e componenti riutilizzabili, guidato da standard chiari, che designer e developer possono usare per supportare la delivery efficace di un prodotto mantenendo coerenza.
Come abbiamo visto in questo articolo, esistono molte interpretazioni di cosa sia un Design System, molte delle quali generano confusione. Questo porta le aziende a credere di avere un Design System e di trarne beneficio, quando in realtà non è così.
Abbiamo visto che un risultato finale di qualità richiede una collaborazione bilanciata tra design e sviluppo. Significa lavorare in modo sincrono e condividere responsabilità. Una comunicazione efficace e una visione condivisa sono essenziali. Gli asset di design e sviluppo devono essere progettati ed evoluti in parallelo, parlando lo stesso linguaggio, per garantire una corrispondenza perfetta tra ciò che viene progettato e ciò che viene implementato.
Un set solido di foundations garantisce coerenza tra i componenti di una libreria. Ma la vera forza arriva quando queste foundations sono esposte a designer e developer per costruire nuovi componenti. Le foundations di un Design System dovrebbero essere accessibili a designer e developer tanto quanto i componenti esistono come risorse di design e di sviluppo.
Un Design System dovrebbe sempre prevedere un designer e uno sviluppatore front-end che lavorano fianco a fianco, per garantire che i benefici del sistema vengano pienamente espressi. È importante ricordare che un Design System è un contenitore di conoscenza e risorse: per questo dovresti sentirti libero di includere qualsiasi elemento utile a raggiungere l’obiettivo di una delivery del prodotto efficace e coerente.
Gabriele is co-founder of Buildo, where he works as co-CTO. He is passionate about front-end and back-end architectures, and has long-term experience with React, TypeScript and Scala.
Ogni mese scegliamo articoli utili ma anche idee fresche e stimolanti. Proprio quello che vorremmo trovare noi in una newsletter!
