Il tuo design system non è un design systemYour design system isn't a design system
Tutti parlano di Design System.
Il cliente dice che gli serve un Design System, le agenzie dicono di costruire Design System, le aziende cercano persone che sappiano lavorare sui Design System.
Eppure, quando si prova a capire a cosa serva davvero un Design System, le risposte diventano molto meno chiare.
Negli ultimi anni il termine è diventato così comune da finire per descrivere cose molto diverse tra loro: una UI Kit, una libreria di componenti, una lista di design-token, o semplicemente un file Figma particolarmente ordinato.
Sono sicuramente tutte cose utili, ma non sono necessariamente un Design System.
Quando parliamo di Design System, stiamo cercando di risolvere un problema ben preciso.
Quando il Design System era ancora una keyword
Quando ho iniziato a sentir parlare seriamente di Design System, lavoravo in I MILLE, nel 2019.
Era una keyword ancora relativamente nuova, molto più presente oltreoceano, ne sentivo parlare su X (si chiamava ancora twitter allora). Se ne parlava, si vedevano aziende internazionali costruire sistemi molto strutturati ( Atlassian, Uber, Airbnb, Spotify...) ma non era ancora così chiaro cosa significasse davvero.
Io stesso cercavo di introdurre il concetto nei progetti in cui lavoravo, perché per me aveva senso, ci credevo...chi ha lavorato con me sa quanto ne ero ossessionato, perché non parlavo d'altro.
Questo perché si iniziava a vedere che, quando un prodotto digitale cresce, non basta più avere designer bravi o una buona libreria di componenti. Servono regole condivise, conoscenza, documentazione e responsabilità.
Ai tempi non c'era ancora Figma, c'era il vecchio e caro Sketch e Adobe XD (e no non è una faccina!)
Il problema più grande però era spiegarlo, al capo, al cliente e ai colleghi, ma soprattutto quando bisognava metterlo a budget.
Un nuovo sito era ormai facile da raccontare, una nuova piattaforma anche ma un Design System? Come lo spieghi?
Era difficile quantificarlo, definire esattamente cosa si sarebbe consegnato, in quanto tempo e soprattutto spiegare quale valore avrebbe prodotto nel tempo. Così quella keyword iniziava lentamente a trasformarsi in una voce di costo.
E da lì, le aziende sapevano di averne bisogno, ma non sapevano esattamente cosa chiedere, e quindi chiedevano a consulenti e agenzie di spiegarglielo.
È probabilmente qui che è iniziata gran parte del problema, quando qualcosa deve diventare acquistabile, tendiamo a trasformarlo in un deliverable.
E quindi il Design System diventava sempre più spesso una libreria di componenti da costruire, documentare e consegnare.
La libreria è solo la parte visibile di un Design System.
Una UI Kit è facile da mostrare, apri Figma e trovi componenti, varianti, colori, tipografia, spacing, puoi letteralmente contarli, puoi presentarli e puoi metterli in un preventivo.
Un sistema di decisioni però è molto meno visibile perché porta con se un sacco di domande: Chi decide quando un componente deve cambiare? Chi può proporre una modifica? Quando una nuova esigenza deve entrare nel sistema? Quando invece è meglio lasciarla specifica di un singolo prodotto? Chi mantiene la relazione tra design e codice? Chi ha ownership? Cosa succede quando cambia il team?
E queste domande non le troviamo dentro al Figma, le risposte non sono definibili con una variable, ma sono quelle che determinano se il sistema continuerà ad avere senso tra un anno.
Ed è qui che, secondo me, cambia la definizione.
Una UI Kit è un insieme di strumenti per progettare interfacce.
Un Design System è un sistema di decisioni, regole, strumenti e responsabilità che permette a un'organizzazione di produrre e far evolvere un'esperienza digitale coerente nel tempo.
La UI Kit è quindi solo un artefatto, il Design System è il sistema che decide come quell'artefatto viene creato, usato, modificato e fatto evolvere.
Perché poi il problema reale rimane comunque:
Come faccio io agenzia/consulente a vendere a te azienda un design system, se poi non hai persone per poterlo portare avanti nel tempo?
Domanda a cui, ancora oggi, non ho trovato risposta...
La parte più importante si chiama Governance
Governance è una parola che spesso sembra molto più complicata di quello che è, fa quasi paura, alla pari di "due diligence" ma in realtà significa una cosa abbastanza semplice quanto importante nel panorama di oggi:
Chi decide cosa?
E non voglio iniziare a fare polemica sterile su questa domanda, chi lavora o ha lavorato in agenzia sa benissimo cosa non vuol dire e come un vecchio saggio diceva: "Chi sa fare, sa capire..." o forse era Giovanni Storti in "Chiedimi se sono felice"...
Comunque un Design System ha bisogno di risposte concrete e senza queste risposte alle domande che ci siamo fatti fino ad ora, la libreria può essere perfetta, ma il sistema comunque non funzionerà.
Perché il giorno dopo che consegni il tuo figma con la libreria tutta bella ordinata con i componenti, l'indomani qualcuno dovrà prendere una decisione, poi un'altra e un'altra ancora e non avrà gli strumenti per portare avanti tutto il lavoro prezioso che avrai fatto.
Il vero valore del Design System sta proprio nel rendere queste decisioni condivise, comprensibili e ripetibili, ed è così che il Design System smette di essere semplicemente un progetto di design e diventa quindi una parte della cultura con cui un'organizzazione costruisce i propri prodotti digitali.
Un sistema non deve rendere tutto uguale
So già che molti Art Director, Visual Designer, UI Designer (e via via discorrendo) quando sentono o vedono la parola Design System la associano a "gabbia di regole da seguire". Questo però è un altro equivoco molto comune.
"Se abbiamo un Design System, allora tutte le pagine devono essere costruite con gli stessi componenti..."
Quindi prendiamo cento componenti, li combiniamo in modi diversi, cambiamo qualche allineamento, spostiamo un'immagine, invertiamo due colonne...e abbiamo costruito un sistema coerente.
Però così il rischio è trasformare il Design System in un enorme building block, un template dal quale è possibile fare soltanto combinazioni già previste.
Ma la consistenza non significa questo.
Se sto progettando un servizio per la pubblica amministrazione, probabilmente avrò bisogno di un sistema molto più controllato, perché accessibilità, chiarezza e prevedibilità hanno un peso enorme.
Se sto progettando un prodotto editoriale o un'esperienza, potrei avere bisogno di maggiore libertà.
E anche all'interno dello stesso prodotto può nascere un'esigenza che non esiste da nessun'altra parte, ma non per questo è un errore.
Un comportamento nuovo può essere modificato, un componente nuovo può essere modificato, una deviazione dal sistema creato può essere modificata.
La domanda non dovrebbe essere:
"Possiamo farlo usando un componente che esiste già?"
Ma:
"Questa decisione deve essere condivisa anche altrove?"
Se la risposta è sì, forse abbiamo trovato un nuovo elemento da aggiungere al sistema.
Se la risposta è no, non c'è necessariamente bisogno di forzarlo dentro una libreria.
Un Design System non dovrebbe eliminare la creatività, ma eliminare la necessità di reinventare ciò che abbiamo già deciso.
Il Design System quindi non è un file
Forse abbiamo passato troppo tempo a chiederci se un'azienda "ha un Design System", come se fosse una checklist da spuntare.
Un'organizzazione non diventa più coerente perché ha una libreria di componenti, ma quando riesce a prendere decisioni condivise, conservarle, applicarle e modificarle senza perdere l'idea iniziale. È per questo che un Design System non dovrebbe essere pensato come qualcosa che si costruisce e poi si consegna, ma qualcosa che deve continuare a funzionare anche dopo la consegna.
E forse è proprio questa la domanda che vale la pena fare quando qualcuno dice "Ci serve un Design System."
E non deve essere:
"Quanti componenti dobbiamo costruire?"
Ma:
"Quale problema organizzativo stiamo cercando di risolvere?"
La risposta a quella domanda ci dirà cosa costruire: una UI Kit, una libreria di componenti, una lista di design-token, o semplicemente un file Figma particolarmente ordinato.
E aggiungo giusto un ultimo punto prima di chiudere il file.
Se sei arrivato fino a qui, probabilmente è perché ti interessa davvero capire cosa sia un Design System, quindi te lo dico nel modo più semplice possibile:
per creare un Design System ci vuole tempo.
Non è una cosa che consegni prima di iniziare un sito, non è un pre-requisito da compilare in mezza giornata e soprattutto, non è qualcosa che puoi considerare "finito" quando hai sistemato tutti i componenti in Figma.
Non puoi costruire in due giorni qualcosa che dovrà guidare un prodotto per mesi o anni.
E soprattutto non puoi misurarlo in numero di componenti, pagine Figma o ore di lavoro.
Se ti chiedono di "fare un Design System" entro venerdì, probabilmente non stanno chiamando nella maniera corretta quello che si aspettano di vedere.
Se ti è venuto in mente qualcuno, probabilmente sai già a chi condividere questo articolo.
Stai costruendo un Design System?
Se dedichi ore o giorni a trasformare una brand identity in colori, tipografia, spacing e altre variabili in un sistema coerente e pronto per Figma, oggi puoi farlo con RatioDS in pochi minuti.
Ho realizzato una piattaforma che ti consente di generare, salvare e condividere la tua foundation, generare un file .json e caricarlo direttamente su Figma tramite il mio plugin (finalmente è online!) ed avrai già pronte all'uso tutte le variabili necessarie per costruire il tuo prossimo design.
Così magari nel tuo prossimo progetto, perderai meno tempo sulla parte meccanica e ti dedicherai di più alle domande che ci siamo fatti prima.
E ovviamente attendo feedback sul tool!
Everyone's talking about Design Systems.
Clients say they need a Design System, agencies say they build Design Systems, companies are hiring people who know how to work on Design Systems.
And yet, when you try to figure out what a Design System is actually for, the answers get a lot less clear.
Over the last few years the term has become so common that it ends up describing very different things: a UI Kit, a component library, a list of design tokens, or just a particularly tidy Figma file.
They're all useful things, sure, but they're not necessarily a Design System.
When we talk about Design Systems, we're trying to solve a very specific problem.
When Design System was still just a keyword
The first time I started hearing people talk seriously about Design Systems, I was working at I MILLE, back in 2019.
It was still a fairly new keyword, much more present in the US; I'd hear about it on X (it was still called Twitter back then). People talked about it, you'd see international companies building highly structured systems ( Atlassian, Uber, Airbnb, Spotify...) but it still wasn't clear what it really meant.
I was trying to bring the concept into the projects I worked on myself, because it made sense to me, I believed in it...anyone who worked with me knows how obsessed I was, because I wouldn't shut up about it.
That's because we were starting to see that, when a digital product grows, having good designers or a good component library isn't enough anymore. You need shared rules, knowledge, documentation and ownership.
Back then there was no Figma yet, there was good old Sketch and Adobe XD (and no, that's not an emoji!)
The biggest problem, though, was explaining it: to the boss, to the client, to colleagues, but most of all when it had to go into the budget.
A new website was easy to pitch by then, a new platform too, but a Design System? How do you explain that?
It was hard to quantify, to define exactly what would be delivered, how long it would take and, above all, to explain what value it would produce over time. So that keyword slowly started turning into a cost line.
And from there, companies knew they needed one, but they didn't know exactly what to ask for, so they asked consultants and agencies to explain it to them.
That's probably where a big part of the problem started: when something has to become purchasable, we tend to turn it into a deliverable.
And so, more and more often, the Design System became a component library to build, document and hand off.
The library is just the visible part of a Design System.
A UI Kit is easy to show: you open Figma and there are components, variants, colors, typography, spacing. You can literally count them, you can present them and you can put them in a quote.
A system of decisions, though, is much less visible, because it comes with a ton of questions: Who decides when a component needs to change? Who can propose a change? When should a new need become part of the system? When is it better to keep it specific to a single product? Who maintains the relationship between design and code? Who has ownership? What happens when the team changes?
And you won't find these questions inside Figma. The answers can't be defined with a variable, but they're the ones that determine whether the system will still make sense a year from now.
And this, in my opinion, is where the definition changes.
A UI Kit is a set of tools for designing interfaces.
A Design System is a system of decisions, rules, tools and responsibilities that lets an organization produce and evolve a consistent digital experience over time.
So the UI Kit is just an artifact; the Design System is the system that decides how that artifact gets created, used, changed and evolved.
Because in the end the real problem is still there:
How am I, as an agency or consultant, supposed to sell you, the company, a design system if you don't have the people to keep it going over time?
A question I still haven't found an answer to...
The most important part is called Governance
Governance is a word that often sounds way more complicated than it is, it's almost scary, right up there with "due diligence," but it actually means something fairly simple, and just as important in today's landscape:
Who decides what?
And I don't want to start some pointless argument over this question. Anyone who works or has worked at an agency knows perfectly well what it doesn't mean, and as a wise old man once said: "Those who know how to do, know how to understand..." or maybe it was Giovanni Storti in "Chiedimi se sono felice"...
Anyway, a Design System needs concrete answers, and without answers to the questions we've asked so far, the library can be perfect, but the system still won't work.
Because the day after you hand off your Figma file with its nice, tidy library of components, someone will have to make a decision, then another, and another, and they won't have the tools to carry forward all the valuable work you did.
The real value of a Design System lies precisely in making these decisions shared, understandable and repeatable, and that's how a Design System stops being just a design project and becomes part of the culture an organization builds its digital products with.
A system doesn't have to make everything the same
I already know that a lot of Art Directors, Visual Designers, UI Designers (and so on and so forth) hear or see the words Design System and think "a cage of rules to follow." But that's another very common misconception.
"If we have a Design System, then every page has to be built with the same components..."
So we take a hundred components, combine them in different ways, change a few alignments, move an image, swap two columns...and we've built a consistent system.
But that way you risk turning the Design System into one giant building block, a template that only allows the combinations it already anticipated.
That's not what consistency means.
If I'm designing a service for the public sector, I'll probably need a much more controlled system, because accessibility, clarity and predictability carry enormous weight.
If I'm designing an editorial product or an experience, I might need more freedom.
And even within the same product, a need can come up that doesn't exist anywhere else, and that doesn't make it a mistake.
A new behavior can be changed, a new component can be changed, a deviation from the system you created can be changed.
The question shouldn't be:
"Can we do this with a component that already exists?"
But:
"Does this decision need to be shared elsewhere too?"
If the answer is yes, maybe we've found a new element to add to the system.
If the answer is no, there's not necessarily any need to force it into a library.
A Design System shouldn't eliminate creativity; it should eliminate the need to reinvent what we've already decided.
So a Design System isn't a file
Maybe we've spent too much time asking whether a company "has a Design System," as if it were a checklist to tick off.
An organization doesn't become more consistent because it has a component library, but when it manages to make shared decisions, keep them, apply them and change them without losing the original idea. That's why a Design System shouldn't be thought of as something you build and then hand off, but as something that has to keep working even after the handoff.
And maybe that's exactly the question worth asking when someone says "We need a Design System."
And it shouldn't be:
"How many components do we need to build?"
But:
"What organizational problem are we trying to solve?"
The answer to that question will tell us what to build: a UI Kit, a component library, a list of design tokens, or just a particularly tidy Figma file.
And let me add one last point before I close the file.
If you've made it this far, it's probably because you genuinely want to understand what a Design System is, so I'll put it as simply as I can:
building a Design System takes time.
It's not something you deliver before starting a website, it's not a prerequisite you fill out in half a day and, above all, it's not something you can call "done" once you've tidied up all the components in Figma.
You can't build in two days something that will have to guide a product for months or years.
And above all, you can't measure it in number of components, Figma pages or hours of work.
If they ask you to "do a Design System" by Friday, they're probably not calling what they expect to see by its right name.
If someone just came to mind, you probably already know who to share this article with.
Are you building a Design System?
If you spend hours or days turning a brand identity's colors, typography, spacing and other variables into a consistent, Figma-ready system, today you can do it with RatioDS in just a few minutes.
I built a platform that lets you generate, save and share your foundation, export a .json file and load it straight into Figma with my plugin (it's finally live!), and you'll have all the variables you need ready to go for building your next design.
That way, on your next project, maybe you'll spend less time on the mechanical part and more on the questions we asked earlier.
And of course, I'm waiting for your feedback on the tool!