Design System — Cheat Sheet

Tag: design-system, frontend, ui, ux, design-tokens, storybook, component-library

Livello: intermedio

TL;DR: Linguaggio visivo condiviso e libreria di componenti riutilizzabili per garantire coerenza, scalabilità e sincronizzazione tra team di design e frontend.

Concetti chiave

Un design system comprende linee guida di design, componenti UI, token di stile e documentazione tecnica.

I design token memorizzano valori atomici di stile come colori, spaziature, tipografia ed elevazioni in formato agnostico.

L'architettura Atomic Design organizza gli elementi in atomi, molecole, organismi, template e pagine.

Storybook o strumenti analoghi fungono da catalogo visuale isolato e workbench di sviluppo frontend.

Il versionamento semantico (SemVer) è critico per gestire breaking change tra libreria UI e applicazioni consumatrici.

L'accessibilità (WCAG 2.1 AA) e la navigazione da tastiera devono essere integrate a livello di singoli componenti atomici.

Separazione rigida tra componenti presentazionali ("dumb" o UI pura) e logica di business applicativa.

I token vengono compilati tramite tool come Style Dictionary verso CSS custom properties, SCSS, JSON o formati mobile.

Domande tipiche e risposte pronte

Q: Qual è la differenza sostanziale tra una component library e un design system completo?R: La component library è solo l'implementazione del codice dei componenti UI; il design system include governance, linee guida di UX, design token e pattern documentati.

Q: Come gestisci la propagazione delle modifiche ai design token dal design al codice?R: Esporto i token dal software di design in formato JSON e uso una pipeline automatizzata con Style Dictionary per generare le variabili CSS e TypeScript.

Q: In che modo gestite le breaking change quando rilasciate una nuova versione del design system?R: Utilizzo il versionamento semantico rigoroso, deprecando i componenti con warning a runtime prima di rimuoverli e allegando dettagliate migration guide nei changelog.

Insidie e errori comuni

Trattare il design system come un progetto una tantum anziché come un prodotto interno in continua evoluzione.

Hardcodare valori CSS arbitrari nei componenti saltando la gerarchia dei design token stabiliti.

Iniettare chiamate API o logica di stato globale applicativa all'interno dei componenti del design system.

Eccessiva configurabilità dei componenti: creare prop API sovradimensionate invece di comporre componenti più semplici.

Trascurare i test di regressione visiva, provocando rotture accidentali dell'interfaccia a valle di refactor CSS.

Snippet e comandi

{
  "color": {
    "primary": {
      "base": { "value": "#0055ff", "type": "color" },
      "hover": { "value": "#0043cc", "type": "color" }
    }
  },
  "spacing": {
    "sm": { "value": "8px", "type": "spacing" },
    "md": { "value": "16px", "type": "spacing" }
  }
}

TypeScript

```import React from 'react';

export interface ButtonProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {

variant?: 'primary' | 'secondary';

size?: 'sm' | 'md';

}

export const Button: React.FC<ButtonProps> = ({

variant = 'primary',

size = 'md',

children,

className = '',

...props

}) => {

return (

<button

className={btn btn--${variant} btn--${size} ${className}}

{...props}

{children}

</button>

);

};

```

Da ripassare

[ ] Pipeline di build e distribuzione dei token con Style Dictionary

[ ] Pattern di composizione avanzati (Compound Components, slot pattern)

[ ] Setup di test di regressione visiva automatizzati (Playwright, Chromatic o Loki)

[x] Principi di Atomic Design per la categorizzazione dei componenti

[x] Strutturazione dei contract e prop types con TypeScript