Design system aziendale: guida pratica per chi deve costruirlo da zero

Ogni team di sviluppo, prima o poi, arriva al punto in cui si accorge che il bottone primario ha tre varianti diverse in tre parti dell'applicazione, che i margin sono definiti in modo inconsistente in ogni componente, e che ogni volta che un designer vuole aggiungere una funzionalità deve rispiegare da zero al developer come devono essere le ombre delle card. Questo è il momento in cui il design system smette di essere un lusso e diventa una necessità.

Cos'è davvero un design system

La definizione sbagliata: una libreria di componenti UI. Una libreria di componenti è solo uno degli artefatti che compongono un design system, non l'insieme.

La definizione corretta: un design system è il linguaggio condiviso tra design e sviluppo, un insieme di regole, componenti, pattern e linee guida che garantiscono coerenza visiva e funzionale in tutti i prodotti digitali di un'organizzazione, e che definiscono come le decisioni di design vengono prese, documentate e implementate.

La differenza pratica: senza un design system, la stessa decisione ("quanto deve essere grande questo bottone?") viene presa ogni volta in modo indipendente da designer e developer diversi, con risultati inconsistenti. Con un design system, quella decisione viene presa una volta, documentata e applicata ovunque automaticamente.

Gli elementi fondamentali

Un design system completo comprende quattro strati sovrapposti:

1. Token di design

I token sono le variabili fondamentali del sistema visivo: colori, tipografia, spaziatura, border radius, ombre, z-index. Non sono componenti, sono i mattoni di cui i componenti sono fatti.

// Token esempio
--color-primary-600: #2563eb;
--color-neutral-100: #f5f5f5;
--spacing-4: 1rem;       /* 16px */
--radius-md: 0.375rem;   /* 6px */
--shadow-sm: 0 1px 2px rgba(0,0,0,0.05);

La distinzione importante: token primitivi (i valori grezzi) vs token semantici (i valori con significato). --color-blue-600 è un token primitivo. --color-action-primary è un token semantico che in tema chiaro punta a --color-blue-600 e in tema scuro a --color-blue-400. Questa distinzione è ciò che permette di implementare temi e dark mode in modo sistematico.

2. Componenti UI documentati

I componenti sono i mattoni dell'interfaccia: Button, Input, Card, Modal, Dropdown, Table, Badge. Ogni componente ha:

• Varianti (primary, secondary, destructive)
• States (default, hover, focus, disabled, loading)
• Props/API documentate
• Linee guida d'uso (quando usarlo, quando non usarlo)
• Esempi di utilizzo corretto e scorretto

3. Pattern di interazione

I pattern sono soluzioni ricorrenti a problemi di UX: come gestire un form multi-step, come mostrare errori di validazione, come strutturare una pagina di dettaglio con sidebar, come implementare una tabella con filtri e paginazione. I pattern documentano la "best practice interna" per questi scenari ricorrenti.

4. Linee guida di accessibilità

Un design system responsabile include requisiti di accessibilità: contrasto minimo dei colori (WCAG AA: 4.5:1 per testo normale), gestione del focus keyboard, attributi ARIA richiesti per componenti complessi, alternative testuali per elementi visivi.

Quando ha senso costruirne uno

Non tutti i team hanno bisogno di un design system completo. I segnali che indicano che è il momento:

• Hai più di 3 prodotti digitali che devono condividere la stessa identità visiva
• Il team di sviluppo ha più di 5 persone
• Designer e developer lavorano su feature in parallelo e i risultati sono inconsistenti
• Ogni nuovo developer impiega settimane prima di essere produttivo sull'UI perché "deve imparare come funzionano le cose qui"
• I design brief includono note come "come la card X nella pagina Y"

Se hai un prodotto singolo con un team piccolo, una libreria di componenti documentata in Storybook è spesso sufficiente senza l'overhead di governance di un design system completo.

Strumenti: cosa usare

Figma per il design: variabili native (introdotte nel 2023) permettono di definire i token direttamente in Figma e mantenerli sincronizzati con il codice tramite plugin come Tokens Studio o Style Dictionary. I component properties consentono di costruire componenti con varianti e stati gestibili dal designer senza creare decine di frame separati.

Storybook per la documentazione del codice: ogni componente ha la propria "storia" che mostra tutte le varianti, gli stati e gli esempi d'uso. Storybook permette lo sviluppo isolato dei componenti (senza doverli inserire in un'applicazione reale per vederli), i visual regression test (con Chromatic) e la documentazione generata automaticamente dalle prop-types o dai tipi TypeScript.

shadcn/ui o Radix UI come base per l'implementazione: invece di partire da zero con i comportamenti accessibili (focus trap nei modal, keyboard navigation nei dropdown, gestione dello scroll), questi progetti forniscono la logica comportamentale lasciando completa libertà sullo stile. In Tailwind CSS, shadcn/ui è diventato lo standard per applicazioni React moderne.

Style Dictionary per la sincronizzazione dei token: trasforma i token definiti in JSON in variabili CSS, costanti SCSS, oggetti JavaScript e file Swift/Kotlin per le app mobile, mantenendo i token sincronizzati tra tutte le piattaforme da un'unica sorgente di verità.

Quanto tempo richiede

Un design system non è un progetto con una fine: è un prodotto che cresce nel tempo. Ma ecco le fasi iniziali con stime realistiche:

Un design system "v1" usabile richiede tipicamente 3-4 mesi di lavoro part-time di un designer e un frontend developer. Il ROI inizia a essere visibile quando la terza feature viene costruita più velocemente perché i componenti sono già pronti.