Un design system è l’insieme strutturato di regole, design token, componenti riutilizzabili e documentazione che un’azienda usa per progettare e sviluppare tutti i suoi prodotti digitali in modo coerente: sito, app, e-commerce, landing page, dashboard. Non è un file Figma ben ordinato né un manuale del logo: è un prodotto interno, con un responsabile, un processo di rilascio e regole di governance. In questa guida vediamo da cosa è composto, come funzionano i design token, quali requisiti di accessibilità deve rispettare, quale modello di governance scegliere e come costruirne uno passo dopo passo.

TL;DR

• Definizione: un design system è un framework vivo di standard, componenti e documentazione che funziona come unica fonte di verità per design e sviluppo.
• Design token: sono le decisioni di design (colori, spaziature, tipografia) salvate come dati e trasformate automaticamente in codice per ogni piattaforma.
• Accessibilità: va costruita a livello di token, partendo dai requisiti WCAG 2.2 AA (contrasto 4,5:1 per il testo normale, focus visibile, uso completo da tastiera).
• Governance: centralizzata, federata o ibrida; senza regole scritte su contributi e deprecazioni, il sistema perde fiducia e viene abbandonato.
• Approccio: trattatelo come un prodotto con risorse dedicate, non come un progetto con una data di fine.

Indice

• Cos’è un design system e cosa non è
• Gli elementi di un design system
• Design token: la lingua comune tra design e sviluppo
• Accessibilità costruita dentro il sistema
• Governance: chi decide, chi contribuisce, chi mantiene
• Come costruire un design system in 8 passi
• Quando un’azienda ne ha davvero bisogno
• Il nostro punto di vista: un design system è un sistema di brand
• Costruire il vostro design system con Xpert Marketing
• Domande frequenti
• Fonti

Cos’è un design system e cosa non è

La definizione più condivisa, riportata anche da Wikipedia, descrive il design system come un framework completo di standard, componenti riutilizzabili e documentazione che guida lo sviluppo coerente dei prodotti digitali all’interno di un’organizzazione. Il punto chiave è “all’interno di un’organizzazione”: il design system codifica le decisioni di quel brand, per quei prodotti.

Nella pratica, tre strumenti vengono spesso confusi tra loro:

In altre parole: lo style guide dice come appare il brand, la libreria di componenti offre i mattoni, il design system stabilisce come si costruisce, chi decide e come si evolve. Se state lavorando sull’identità visiva, la nostra guida alle linee guida sul tono di voce del brand mostra come lo stesso principio di sistema si applica anche ai testi.

Gli elementi di un design system

Un design system maturo si organizza su livelli, dal più astratto al più concreto:

1. Principi: poche affermazioni che orientano le scelte quando le regole non bastano (per esempio: “chiarezza prima dell’estetica”, “accessibile per impostazione predefinita”).
2. Fondamenta: colore, tipografia, griglia, spaziature, iconografia, movimento, raggi degli angoli, ombre.
3. Design token: le fondamenta tradotte in variabili con un nome, condivise tra design e codice.
4. Componenti: gli elementi riutilizzabili dell’interfaccia (bottone, input, select, card, tab, notifiche), ciascuno con stati, varianti e comportamento documentati.
5. Pattern: combinazioni ricorrenti di componenti che risolvono un compito (login, checkout, form di contatto, filtri di ricerca, stato vuoto).
6. Linee guida di contenuto: microcopy, messaggi di errore, terminologia, tono.
7. Documentazione e governance: dove si trova tutto, come si usa, chi approva le modifiche, come si segnalano i bug, come si rilascia una nuova versione.

Un esempio pubblico utile è il W3C Design System, che raccoglie in variabili Sass globali colori, font, tipografia e breakpoint per le media query: è la stessa logica dei token, applicata in modo trasparente.

Design token: la lingua comune tra design e sviluppo

I design token sono il cuore operativo del sistema. Un token è una decisione di design salvata come dato: un nome e un valore. Invece di scrivere #0B5FFF in cento punti diversi del codice e in decine di file Figma, definite un token e lo usate ovunque. Quando il valore cambia, cambia in tutti i prodotti.

I tre livelli di token

La struttura più diffusa distingue tre livelli:

• Token primitivi (o globali): i valori grezzi della palette e della scala. Esempio: blue-600 = #0B5FFF, space-4 = 16px.
• Token semantici: il significato d’uso, che punta a un primitivo. Esempio: color-action-primary = blue-600, color-text-error = red-700.
• Token di componente: le decisioni specifiche di un elemento. Esempio: button-primary-background = color-action-primary.

Questa separazione è ciò che rende possibili un rebranding, un tema scuro o un sotto-brand senza riscrivere i componenti: si modifica la mappatura tra livelli, non il codice di ogni schermata.

Dalla variabile Figma al codice

La sincronizzazione tra Figma e codice funziona meglio quando i token sono esportati come unica fonte di verità. Il team di design di ExxonMobil descrive un flusso in cui i token definiti come variabili in Figma vengono trasformati con Style Dictionary in risorse specifiche per piattaforma, come JSON, CSS e TypeScript. Il flusso tipico:

1. I designer definiscono e aggiornano le variabili in Figma.
2. Le variabili vengono esportate in un file JSON versionato nel repository.
3. Uno strumento di trasformazione genera variabili CSS, costanti per iOS e Android, temi per il framework front-end.
4. La pipeline pubblica una nuova versione del pacchetto, che i team prodotto aggiornano come qualsiasi dipendenza.

Il vantaggio non è solo tecnico: si eliminano le discrepanze tra mockup e prodotto rilasciato e lo sviluppatore non deve più “tradurre” a mano le specifiche. È il tema che affrontiamo anche nella guida su cosa fanno davvero UX e UI designer.

Accessibilità costruita dentro il sistema

L’accessibilità non è una funzione da aggiungere alla fine: è un requisito di base del design system. Il motivo è semplice: se un componente è accessibile, ogni schermata che lo usa eredita quella qualità. Se non lo è, l’errore si moltiplica in tutti i prodotti.

Il riferimento internazionale sono le Web Content Accessibility Guidelines 2.2 a livello AA, che per un design system si traducono in alcuni vincoli concreti:

• Contrasto: almeno 4,5:1 per il testo normale e 3:1 per il testo grande e per i componenti dell’interfaccia. Va verificato sui token semantici, non schermata per schermata.
• Tastiera: tutte le funzionalità devono essere utilizzabili da tastiera, quindi ogni componente interattivo va specificato anche per la navigazione senza mouse.
• Focus visibile: ogni elemento interattivo ha un indicatore di focus chiaro.
• Il colore non basta: stati di errore, selezione o successo non possono affidarsi solo al colore.

Su quest’ultimo punto, la strategia di accessibilità del GOV.UK Design System è un modello da studiare: raccomanda di affiancare al colore forme, motivi o etichette testuali, così che l’informazione resti comprensibile anche per chi ha deficit nella percezione dei colori. Lo stesso team ha documentato come progettare gli stati di focus per chi naviga da tastiera passando da un elemento interattivo al successivo.

In pratica: create token dedicati per focus, contrasto e dimensioni minime dei target touch, e incapsulateli nei componenti. Così i team non devono ricordarsi le regole: le usano già.

Governance: chi decide, chi contribuisce, chi mantiene

Molti design system falliscono non per la qualità dei componenti, ma per l’assenza di regole. Come osserva la guida di Figma sulla governance, ogni design system ha già una governance: la maggior parte dei team semplicemente non l’ha messa per iscritto.

I tre modelli principali

La classificazione più usata, ripresa dalla guida di zeroheight ai modelli di governance, distingue tre strutture:

Il modello federato, come sottolinea un’analisi pubblicata su UX Planet, non è consigliato per team piccoli o startup in fase iniziale: lì un solo responsabile con un processo snello funziona meglio. La scelta dipende dalla scala e dalle dinamiche interne dell’azienda, e il modello può evolvere con il sistema.

Le regole minime da scrivere

Qualunque modello scegliate, quattro documenti fanno la differenza:

• Modello di contribuzione: come un team propone un nuovo componente o una variante, con quali informazioni e in quanto tempo riceve risposta.
• Criteri di accettazione: quando una richiesta entra nel sistema (serve a più team?) e quando resta una soluzione locale.
• Politica di deprecazione: come e con quanto preavviso un componente viene ritirato. Un preavviso di alcuni mesi, comunicato nelle note di rilascio, dà ai team il tempo di migrare.
• Versionamento e rilascio: numerazione semantica delle versioni, changelog, canali di supporto.

Il problema dei “fiocchi di neve”

L’errore più frequente è quello delle soluzioni uniche: un team crea il proprio bottone, il proprio modale, la propria tabella, perché è più veloce che chiedere. Ogni eccezione aumenta il carico cognitivo per l’utente, rompe la coerenza e genera debito tecnico. La risposta non è vietare, ma rendere la scelta corretta anche la più semplice: componenti ben documentati, facili da installare e più rapidi da usare rispetto a scriverne uno da zero.

Come costruire un design system in 8 passi

1. Audit dell’esistente: raccogliete screenshot di tutte le interfacce e contate le varianti. Trovare 14 tonalità di blu e 9 stili di bottone è normale, ed è il miglior argomento per ottenere budget.
2. Obiettivi misurabili: tempo di rilascio di una nuova pagina, percentuale di componenti condivisi, numero di difetti di accessibilità, coerenza tra canali.
3. Principi e fondamenta: definite palette, scala tipografica, griglia e spaziature partendo dall’identità di marca, non dal gusto del singolo designer.
4. Token: strutturateli in primitivi, semantici e di componente, e verificate subito il contrasto.
5. Componenti prioritari: partite dai 10-15 elementi più usati (bottoni, campi, select, checkbox, card, navigazione, notifiche), in design e in codice, con tutti gli stati.
6. Documentazione: per ogni componente, quando usarlo, quando non usarlo, varianti, accessibilità, esempi di codice.
7. Governance e responsabili: scegliete il modello, nominate un responsabile, pubblicate il processo di contribuzione e il canale di supporto.
8. Adozione e misurazione: migrate un prodotto pilota, raccogliete feedback, misurate gli obiettivi del punto 2 e pianificate le versioni successive.

Un principio va tenuto fermo: un design system non è un progetto con una data di fine, ma un prodotto che richiede investimento continuo, persone dedicate e canali di supporto chiari. Senza, smette di evolvere e i team lo abbandonano.

Quando un’azienda ne ha davvero bisogno

Non tutte le aziende devono partire da un design system completo. Questi segnali indicano che è il momento:

• gestite più di un prodotto digitale (sito, e-commerce, app, area riservata) e appaiono come brand diversi;
• ogni nuova landing page richiede di riprogettare elementi già esistenti;
• design e sviluppo discutono spesso su “come doveva essere”;
• state affrontando un rebranding e volete che si propaghi ovunque senza rifare tutto;
• avete segnalazioni di accessibilità ricorrenti sugli stessi elementi.

Se avete un solo sito vetrina e un team di due persone, bastano una libreria di componenti e un file di token ben curato. Come spieghiamo nell’articolo su perché il web design non riguarda solo l’aspetto di un sito, la coerenza visiva è prima di tutto una questione di funzionamento e di conversione.

Il nostro punto di vista: un design system è un sistema di brand

Lavorando su branding, sviluppo web e campagne digitali per aziende di settori diversi, vediamo spesso lo stesso scollamento: l’identità visiva vive in un PDF, il sito in un tema WordPress, le landing page delle campagne in un page builder, i social in modelli grafici separati. Ognuno è coerente con sé stesso, nessuno con gli altri.

Per questo consideriamo il design system come l’estensione naturale della brand identity, non come un esercizio riservato ai team di prodotto. I token che definiscono colore e tipografia del sito sono gli stessi che dovrebbero guidare banner, email automatizzate e materiali per gli eventi. Quando la strategia, la ricerca di mercato e l’analisi dei dati alimentano anche le scelte di design, il sistema smette di essere un archivio di componenti e diventa uno strumento di crescita misurabile: pagine che si pubblicano più in fretta, test A/B più puliti, esperienze riconoscibili su ogni canale.

È la stessa logica che descriviamo parlando di marketing 360 come sistema: i risultati arrivano quando le parti lavorano insieme. Il nostro consiglio è partire piccoli, con fondamenta e token solidi, e far crescere il sistema insieme al brand.

— Xpert

Costruire il vostro design system con Xpert Marketing

Se state pianificando un rebranding, un nuovo sito o un ecosistema di prodotti digitali, possiamo affiancarvi dall’identità visiva ai componenti in codice. Il nostro servizio di branding e identità visiva definisce le fondamenta del sistema, mentre l’area Web, Tech & Innovation copre UX/UI, landing page, e-commerce, app mobili e WordPress. Scoprite tutte le aree di intervento nella pagina dei servizi di Xpert Marketing e raccontateci da dove partite.

Domande frequenti

Che differenza c’è tra design system e style guide?

Lo style guide descrive l’aspetto del brand: logo, colori, tipografia, tono. Il design system include queste regole ma aggiunge token, componenti in design e codice, pattern, documentazione e governance. Lo style guide si consulta, il design system si usa per costruire.

Cosa sono i design token, in parole semplici?

Sono decisioni di design salvate come variabili con un nome, per esempio color-action-primary. Lo stesso token viene usato in Figma e trasformato automaticamente in CSS o codice per app. Se il valore cambia, l’aggiornamento si propaga a tutti i prodotti.

Quanto tempo serve per creare un design system?

Dipende dal numero di prodotti, dalla quantità di componenti e dalle risorse dedicate. Una prima versione con fondamenta, token e componenti principali può essere pronta per un prodotto pilota, ma il sistema non si “finisce” mai: va mantenuto e fatto evolvere come qualsiasi prodotto.

Quale modello di governance scegliere?

Per una startup o un team piccolo funziona un modello centralizzato con un solo responsabile. Le aziende con più team su prodotti correlati traggono vantaggio da un modello federato o ibrido, con processi di contribuzione scritti. L’importante è mettere le regole per iscritto e rivederle con la crescita.

Un design system serve anche a una PMI?

Sì, in versione proporzionata. Anche una PMI con sito, e-commerce e campagne frequenti risparmia tempo con token condivisi e una piccola libreria di componenti. Non serve un team dedicato fin dal primo giorno, serve un responsabile chiaro.

Fonti

• Design system, Wikipedia
• Settings, W3C Design System
• Design tokens: unified approach to design system implementation, Design at ExxonMobil
• WCAG 2.2 Quick Reference, livello AA, W3C
• Accessibility strategy, GOV.UK Design System
• Understanding focus state styles, GOV.UK Design System
• Design System Governance: Structuring Ownership, Figma
• Design system governance models, zeroheight
• Design System Governance Models, UX Planet

Raccomandati

• UX UI design: cosa fanno davvero e come iniziare a progettare
• Il web design non riguarda solo l’aspetto di un sito