Il design system è uno dei concetti più abusati nel settore digitale — citato spesso come soluzione enterprise per aziende con decine di designer. In realtà, un design system scalato alle dimensioni di una PMI è uno degli investimenti con il miglior ROI nell’intero ciclo di vita di un prodotto digitale.
Cos’è un Design System (Definizione Operativa)
Un design system è un insieme strutturato di componenti visivi, regole di utilizzo e linee guida che definisce come si costruisce e si presenta qualsiasi prodotto digitale aziendale — sito web, app, dashboard, email, presentazioni.
Non è un file Figma con qualche componente. Non è il manuale del brand applicato al digitale. È un sistema vivente che connette tre layer:
Design tokens — i valori fondamentali del sistema: colori (in tutti i loro ruoli semantici), tipografia (famiglie, scale, pesi), spaziature, raggi di arrotondamento, ombre, transizioni. Espressi come variabili nominali (--color-primary-500, --spacing-md, --radius-button) che possono essere consumate sia dagli strumenti di design che dal codice.
Componenti — elementi dell’interfaccia riutilizzabili: bottoni, form, card, navigation, modal, badge, tabelle, toast. Ogni componente esiste nello strumento di design (Figma) e nel codice (HTML/CSS/JS o componenti del framework) con specifica di tutti gli stati possibili (default, hover, focus, disabled, error, loading).
Pattern e linee guida — regole su come combinare i componenti per costruire interfacce coerenti: pattern di navigazione, layout di pagina, gestione degli errori, accessibilità, comportamento responsive.
Perché Serve Anche a una PMI
L’argomento “il design system è roba da Google e Airbnb” è comprensibile ma sbagliato. La scala cambia la complessità del sistema, non la necessità di averlo.
Il problema senza design system
Senza un sistema strutturato, ogni nuova pagina o funzionalità viene costruita con micro-decisioni ridefinite da zero. Quale shade di blu per questo bottone? Questo testo è h3 o un p con font-size aumentato? Quanto padding interno ha questa card? Questi pixel arrotondati sono gli stessi del modal o diversi?
Queste decisioni non sembrano costose prese singolarmente. Lo diventano in scala: ogni developer e ogni designer che lavora sul prodotto risolve gli stessi problemi in modo leggermente diverso. Il risultato è un’interfaccia visivamente inconsistente che erode la percezione di qualità del prodotto.
Il costo reale si manifesta in:
- Tempo di sviluppo più lungo per costruire nuove funzionalità (ogni componente viene ricreato)
- Bug visivi difficili da trovare perché non c’è uno standard a cui fare riferimento
- Onboarding più lento per nuovi developer o designer che entrano nel team
- Refactoring costoso quando si vuole aggiornare la UI in modo sistematico
Il valore con un design system
Un design system ben costruito riduce il tempo di sviluppo di nuove funzionalità del 30–50% (i componenti esistono già, bisogna solo combinarli). Garantisce coerenza visiva automaticamente. Rende gli aggiornamenti sistemici banali (cambi il valore del token, cambia tutto il sistema). Abilita la collaborazione tra designer e developer su una lingua condivisa.
I Layer Tecnici: Come si Costruisce
Token di Design
I design token sono il fondamento. Prima di costruire un solo componente, si definiscono tutti i valori fondamentali del sistema come variabili con nomi semantici.
Gerarchia dei token:
// Tier 1 — Valori primitivi (non usati direttamente nell'UI)
--blue-100: #EFF6FF
--blue-500: #3B82F6
--blue-900: #1E3A8A
// Tier 2 — Token semantici (usati nell'UI)
--color-primary: var(--blue-500)
--color-primary-hover: var(--blue-600)
--color-text-default: var(--gray-900)
--color-text-muted: var(--gray-500)
--color-surface-default: var(--white)
--color-surface-subtle: var(--gray-50)
// Tier 3 — Token di componente (scoping specifico)
--button-primary-bg: var(--color-primary)
--button-primary-text: var(--white)
--button-primary-bg-hover: var(--color-primary-hover)Questo sistema permette di supportare temi (light/dark mode) cambiando solo i token semantici, senza toccare i componenti.
Componenti in Figma
Ogni componente viene costruito in Figma come componente riutilizzabile con:
- Varianti per gli stati (default, hover, focus, active, disabled, error)
- Proprietà per le configurazioni (size, variant, icon left/right, loading state)
- Auto layout per il comportamento responsive
- Documentazione inline con note d’uso
Componenti in Codice
Il componente Figma ha un corrispettivo esatto nel codice — in Svelte, in React, o come Web Component vanilla, a seconda dello stack del progetto. La specifica del componente garantisce che design e codice siano sempre allineati.
Documentazione e Storybook
Per progetti di media-alta complessità, Storybook (o equivalenti) documenta automaticamente ogni componente con le sue varianti, props e casi d’uso. I developer possono esplorare e testare i componenti in isolamento prima di usarli nel prodotto.
Design System e Brand Identity: L’Integrazione
Un design system non è indipendente dal brand. È la traduzione del brand nel prodotto digitale.
I design token del sistema derivano direttamente dalla brand identity: i colori primari e secondari del brand diventano i token --color-primary e --color-secondary. La tipografia del brand diventa la scala tipografica del sistema. Il tono di voce del brand si manifesta nelle etichette dei bottoni, nei messaggi di errore, nei tooltip.
Questa integrazione è il motivo per cui, in Marfcode, brand identity e sviluppo del sito/app vengono trattati come un unico progetto — non come due fasi sequenziali affidate a team separati. Un brand costruito senza considerare le applicazioni digitali produce quasi sempre attrito quando si arriva allo sviluppo.
Scala Adatta alle PMI: Cosa Serve Davvero
Non tutte le PMI hanno bisogno di un design system completo come quello di Atlassian o Salesforce. La versione scalata per una PMI include:
Fondamenta (sempre necessarie):
- Token di design (colori, tipografia, spaziature) in Figma e in CSS/JS
- Componenti base: button, form elements, card, navigation, modal, tabelle
- Linee guida responsive
- Gestione light/dark mode (se rilevante)
Layer intermedio (per prodotti con più pagine o funzionalità):
- Pattern di layout (grid system, page templates)
- Componenti complessi: data table, filtri, wizard multi-step
- Gestione degli stati di sistema (loading, errori, empty states)
- Storybook o documentazione equivalente
Layer avanzato (per prodotti SaaS o app complesse):
- Motion system (animazioni e transizioni codificate)
- Componenti di data visualization
- Internazionalizzazione nel sistema
- Testing automatizzato dei componenti
Il Nostro Approccio
In Marfcode costruiamo design system scalati alla complessità reale del progetto. Per un sito istituzionale di media complessità, un sistema di token e componenti base risolve il 90% delle esigenze. Per un’applicazione SaaS o un portale clienti complesso, il design system diventa un progetto a sé con timeline e deliverable dedicati.
In entrambi i casi, il sistema nasce in sincronia con il brand identity e viene consegnato con documentazione che permette al team cliente di usarlo autonomamente.
→ Parla con noi del design system per il tuo progetto
Articolo correlato: Brand Strategy vs Brand Identity: differenze e priorità | Brand guidelines: cosa devono contenere
