Design system, senza il marketing
Il termine "design system" è stato logorato da due anni di post su LinkedIn. Quindi ripartiamo dalla definizione.
Un design system è la fonte di verità unica, eseguibile e versionata su come il tuo prodotto appare e si comporta. "Eseguibile" perché i designer lavorano con gli stessi componenti che gli sviluppatori rilasciano in produzione. "Versionata" perché il sistema evolve nel tempo e le versioni precedenti devono continuare a funzionare. "Fonte di verità unica" perché se resta ambiguità, il sistema non sta facendo il suo lavoro.
Un file Figma con dentro qualche bottone non è un design system. Uno Storybook con 40 componenti e nessun design token non è un design system. Il sistema è il ponte tra i due.
Cosa cambia quando ce l'hai
Tre cose, misurabili:
Velocità di sviluppo delle nuove funzionalità. Nei progetti in cui introduciamo un design system vero a metà percorso, la velocità di consegna delle funzionalità accelera del 30–50% nel giro di due sprint. I designer smettono di reinventare i pattern dei form. Gli sviluppatori smettono di reimplementare i bottoni. Le PR si riducono.
Coerenza tra le superfici. Le aziende multi-prodotto sono il caso più ovvio, ma ne beneficiano anche i team con un solo prodotto. Il sito marketing, l'app, la dashboard di amministrazione, i template email — se condividono i token, sembrano provenire dalla stessa azienda. Senza token condivisi, finiscono sempre per divergere.
Costo di onboarding. Un nuovo designer o sviluppatore può rilasciare la sua prima PR nella prima settimana invece che nel primo mese. Il sistema risponde alla maggior parte delle domande "come facciamo X" prima ancora che vengano poste.
Cosa contiene
Un design system funzionante ha grosso modo quattro livelli. Saltane uno e il sistema diventa fragile.
1. Token. Colori, tipografia, spaziature, raggi, ombre, durate delle animazioni, curve di easing. Sono file JSON, non immagini. Alimentano sia Figma (tramite strumenti come Tokens Studio) sia il codice (tramite Style Dictionary o simili). Il livello dei token è il più importante ed è anche quello che viene saltato più spesso.
2. Primitive. Bottoni, input, select, checkbox, radio, toggle, badge, tooltip, modali. Gli elementi UI atomici che compaiono in ogni schermata. Vanno implementati una sola volta, con un'accessibilità adeguata (focus ring, ARIA, supporto per la tastiera), e documentati con tabelle delle prop.
3. Pattern. Form, navigazione, stati vuoti, stati di caricamento, stati di errore, tabelle dati. Sono composizioni di primitive. Incorporano scelte precise: "ecco come gestiamo un form multi-step", non "ecco una libreria di form".
4. Linee guida. Tono di voce, standard di accessibilità, regole sui contenuti ("usiamo il sentence case nei bottoni"), principi di animazione. Le parti non legate ai componenti che tengono coerente il lavoro.
Un fallimento comune: rilasciare il sistema e poi abbandonarlo
Metà dei design system che vediamo nelle codebase dei clienti sono stati costruiti due anni fa, usati per sei mesi, e poi silenziosamente aggirati. Sintomi: uno Storybook che nessuno aggiorna, componenti nella codebase che fanno ombra a quelli del design system, valori hex dei colori hardcoded in 30 punti diversi.
Di solito succede quando il sistema viene trattato come un deliverable una tantum invece che come un prodotto vivo. La soluzione è strutturale:
- Assegna un owner. Anche part-time. Senza un owner, nessuno decide quando un nuovo componente viene promosso nel sistema.
- Rendi il sistema più facile da usare che da aggirare. Se aggiungere un nuovo componente al sistema richiede più tempo di un copia-incolla, hai già perso.
- Fai un audit trimestrale. Scorri ogni schermata, conta le deviazioni, correggile. Usiamo una metrica semplice: "percentuale di schermate che usano solo componenti del sistema". Qualsiasi valore sotto l'80% è un problema.
Partire in piccolo (e non fermarsi)
Non serve una libreria da 200 componenti per chiamarlo design system. Una v1 funzionante sta in un'unica libreria Figma e in un unico pacchetto npm, e contiene grosso modo:
- 8 token di colore
- 4 scale tipografiche
- Una scala di spaziature (4 / 8 / 12 / 16 / 24 / 32 / 48)
- 6 componenti: bottone, input, select, modale, card, tabella
- 3 pattern: layout dei form, header di pagina, stato vuoto
Questo è un design system vero. Rilascialo venerdì, usalo lunedì, fallo crescere nel corso dell'anno successivo.
Quando non ti serve
Un team di due persone che costruisce un singolo prodotto per sei mesi rilascerà più in fretta senza l'overhead di un sistema formale. Il punto di pareggio è più o meno: tre o più designer/sviluppatori, più superfici, oppure un prodotto destinato a vivere più di 18 mesi. Al di sotto di questa soglia, basta scrivere le convenzioni e andare avanti.
Al di sopra di questa soglia, la domanda non è "dobbiamo costruire un design system?" — è "quanto abbiamo già pagato per non averne uno?" Se vuoi un secondo parere su a che punto si trova il sistema del tuo team, il nostro team di UI/UX design esegue un audit leggero come punto di partenza.
