Interfacce decenti senza fare il designer.
Per chi costruisce cose e vuole che siano usabili, non solo funzionanti.
"Il design è come un barzelletta. Se devi spiegarlo, non funziona."
— cit. vari, usata a sproposito in ogni pitch deck dal 2015
No, non sono la stessa cosa. Sì, lo sapevi già. No, non cambia niente finché non lo applichi.
È la parte visiva: colori, tipografia, layout, pulsanti, icone, animazioni. È come appare l'interfaccia. Un pittore che fa un bel quadro fa UI.
Se il tuo sito è bello ma incomprensibile, hai fatto buona UI e pessima UX.
È l'esperienza complessiva: l'utente riesce a fare quello che vuole fare? In quanto tempo? Con quanta frustrazione? È come funziona. Un cartello stradale chiaro fa UX.
Se il tuo sito è brutto ma intuitivo, hai fatto cattiva UI e buona UX.
Non devi diventare un designer. Devi evitare gli errori che rendono le tue interfacce inutilizzabili. La maggior parte dei problemi di UX nei progetti fatti da sviluppatori non vengono da mancanza di creatività — vengono da 5-6 errori sistematici che si ripetono sempre.
Quattro parole che i designer usano nelle riunioni. Impara cosa significano così puoi capire quando stanno dicendo cose sensate e quando no.
L'occhio umano non legge una pagina linearmente — la scansiona. La gerarchia visiva guida questo scan: cosa è più importante visivamente viene visto prima. Titolo > sottotitolo > corpo > dettagli.
Se tutto è in grassetto, niente è in grassetto. Se tutto è grande, niente è grande.
❌ Tutto uguale
Titolo della pagina
Descrizione del prodotto
Dettaglio tecnico importante
Nota a piè di pagina
✅ Gerarchia chiara
Titolo della pagina
Descrizione del prodotto
Dettaglio tecnico · Nota
Ogni azione dell'utente deve avere una risposta visibile. Ho cliccato il bottone? Funziona? Sta caricando? È andato a buon fine? Il silenzio dell'interfaccia è la fonte numero uno di frustrazione e doppi click.
Se il bottone primario è blu in una pagina, deve essere blu ovunque. Se un'azione si annulla con "Annulla", non deve essere "Indietro" in un'altra schermata. La coerenza riduce il carico cognitivo — l'utente non deve reimparare le convenzioni ogni volta.
Il modo più semplice per averla: usa un design system, anche minimale. Anche solo 3-4 variabili CSS con i colori e i font risolve il 70% dei problemi di incoerenza.
Un bottone deve sembrare cliccabile. Un campo di input deve sembrare editabile. L'affordance è la qualità di un elemento che comunica come si usa senza spiegazioni. Un bottone flat con zero elevazione e zero bordo non comunica "cliccami" — comunica "sono testo".
Regola pratica: se devi scrivere "clicca qui" o "trascina qui", l'affordance è rotta.
Guida l'occhio con dimensione, peso e colore
Ogni azione ha una risposta visibile
Stessi elementi, stessi comportamenti ovunque
Il 90% di un'interfaccia è testo. Trattalo bene. No, "Comic Sans dà personalità" non è un argomento valido.
Non inventare dimensioni a caso. Usa una scala predefinita — ogni valore è un multiplo del precedente. Le più comuni sono basate su rapporti come 1.25 (Major Third) o 1.333 (Perfect Fourth). Sì, i designer hanno davvero dato nomi musicali alle scale tipografiche. Sono fatti così.
Uno è sufficiente nella maggior parte dei casi. Due è il massimo sensato (uno per titoli, uno per corpo). Tre font in una stessa interfaccia è un design problem travestito da scelta creativa.
Font sicuri e gratuiti: Inter (interfacce), JetBrains Mono (codice), Geist (moderno), System UI (zero latenza, zero personalità).
/* Design token tipografici in CSS — copia e adatta */ :root { --font-sans: 'Inter', system-ui, sans-serif; --font-mono: 'JetBrains Mono', monospace; --text-xs: 0.75rem; /* 12px */ --text-sm: 0.875rem; /* 14px */ --text-base: 1rem; /* 16px */ --text-lg: 1.125rem; /* 18px */ --text-xl: 1.25rem; /* 20px */ --text-2xl: 1.5rem; /* 24px */ --text-3xl: 1.875rem; /* 30px */ --text-4xl: 2.25rem; /* 36px */ --leading-tight: 1.25; --leading-normal: 1.6; --leading-loose: 1.8; }
La regola 60-30-10, il contrasto WCAG, e perché quel grigio chiarissimo su sfondo bianco che ti sembra elegante è illeggibile per metà degli utenti.
In qualsiasi schema di colori ben bilanciato: 60% colore dominante (sfondo, aree neutre), 30% colore secondario (card, elementi strutturali), 10% colore accent (CTA, link, highlight). Se superi il 10% di accent, l'interfaccia diventa rumorosa.
9 colori. Non ne servono di più per il 90% dei progetti.
Le WCAG (Web Content Accessibility Guidelines) definiscono rapporti minimi di contrasto tra testo e sfondo. Non è burocrazia — è che il tuo testo grigio chiaro su sfondo bianco è illeggibile per il 30% degli utenti anche senza disabilità visive dichiarate.
| Livello WCAG | Ratio minimo | Applicazione |
|---|---|---|
| AA | 4.5:1 | Testo normale (standard minimo accettabile) |
| AA Large | 3:1 | Testo grande (18px+ o 14px bold) |
| AAA | 7:1 | Massima accessibilità |
webaim.org/resources/contrastchecker — incolla due hex, ti dice il ratio
Browser DevTools → Inspect elemento → clicca sul colore → mostra ratio automaticamente
Figma con plugin "Contrast" — controlla tutto il file in un click
Il whitespace non è spazio sprecato. Anche se il tuo capo continua a chiedere di "sfruttare meglio lo spazio".
Stessa logica della tipografia: usa una scala fissa invece di valori random. La base comune è 4px o 8px — ogni valore è un multiplo. Tailwind CSS usa questa scala di default e funziona benissimo.
Elementi correlati devono stare vicini. Elementi non correlati devono avere più spazio tra loro. Se il label di un campo form è lontano quanto il campo successivo, l'utente non capisce cosa appartiene a cosa.
Regola pratica: lo spazio interno a un gruppo deve essere minore dello spazio tra gruppi diversi.
Su schermi larghi, il testo a piena larghezza diventa impossibile da leggere. Il corpo del testo non dovrebbe mai superare i 65-75ch (caratteri) di larghezza. Per layout più ampi, usa colonne o max-width sul container di testo.
.prose { max-width: 65ch; }
/* Design token spaziatura — base 4px */ :root { --space-1: 0.25rem; /* 4px */ --space-2: 0.5rem; /* 8px */ --space-3: 0.75rem; /* 12px */ --space-4: 1rem; /* 16px */ --space-6: 1.5rem; /* 24px */ --space-8: 2rem; /* 32px */ --space-12: 3rem; /* 48px */ --space-16: 4rem; /* 64px */ --space-24: 6rem; /* 96px */ }
Bottoni, toast, modal. Quelli che tutti sanno fare ma quasi nessuno fa bene. Inclusi i team con il design system da 200 componenti.
Un bottone ha almeno 5 stati: default, hover, active (pressed), focus, disabled. Se ne manca anche uno solo, l'interfaccia sembra rotta. E ci sono tre livelli di gerarchia: primary (CTA principale), secondary (azione alternativa), ghost/tertiary (azione di minor peso).
I toast sono notifiche temporanee (2-4 secondi) per azioni completate. Gli alert sono messaggi persistenti per stati importanti. Entrambi devono avere quattro varianti semantiche: success (verde), error (rosso), warning (giallo), info (blu).
Ogni componente che carica dati da rete ha tre stati che devi gestire: loading (spinner o skeleton), empty (nessun dato), error (qualcosa è andato storto). Se gestisci solo lo stato "dati presenti", il 30% delle volte la tua UI è rotta senza che tu lo sappia.
Il componente più odiato dagli sviluppatori, il più usato dagli utenti, e quello su cui ci sono più tutorial sbagliati in circolazione.
Non è "la versione piccola del desktop". E no, non basta testarlo ridimensionando Chrome sul tuo MacBook da 16 pollici.
Le dita non sono cursori. Un touch target troppo piccolo è la fonte numero uno di tap errati su mobile. Apple HIG raccomanda 44×44pt minimi, Google Material raccomanda 48×48dp. Nella pratica: ogni bottone, link, o elemento interattivo deve avere almeno 44px di area tappabile, anche se visivamente è più piccolo.
/* Trick: aumenta l'area di tap senza cambiare l'aspetto */ .small-btn { position: relative; padding: 12px; /* area reale */ } /* oppure */ .icon-btn { min-width: 44px; min-height: 44px; display: flex; align-items: center; justify-content: center; }
/* Mobile-first: scrivi base per mobile, poi sovrascrivi per schermi più grandi */ /* default: mobile */ .grid { grid-template-columns: 1fr; } /* tablet ≥768px */ @media (min-width: 768px) { .grid { grid-template-columns: repeat(2, 1fr); } } /* desktop ≥1024px */ @media (min-width: 1024px) { .grid { grid-template-columns: repeat(3, 1fr); } }
srcset e loading="lazy"font-display: swaptransform e opacity sono GPU-accelerated. Evita margin, width, height nelle animazionivh puro su mobile — la barra del browser cambia altezza durante lo scroll. Usa svh o dvhNon serve diventare esperti WCAG. Bastano 10 regole. Di cui almeno 4 probabilmente stai già violando.
Usare i tag HTML giusti risolve il 60% dei problemi di accessibilità senza scrivere una riga di CSS o JS aggiuntivo. Gli screen reader capiscono <button>, <nav>, <main>, <h1>. Non capiscono <div class="btn"> e <span class="title">.
<div class="nav">
<span onclick="go()">
Home
</span>
</div>
<div class="title">Ciao</div>
<div class="btn" onclick="submit()">
Invia
</div>
<nav>
<a href="/">
Home
</a>
</nav>
<h1>Ciao</h1>
<button type="submit">
Invia
</button>
<nav>, <main>, <article>, <button>, <h1-h6>alt descrittivo (o alt="" se decorativa)outline: none senza sostituirlo<label for="id">)/* Focus visibile — non toglierlo, miglioralo */ :focus-visible { outline: 2px solid #38bdf8; outline-offset: 2px; border-radius: 4px; } /* Rimuovi solo per mouse, non per tastiera */ :focus:not(:focus-visible) { outline: none; }
Non è "inverti i colori". Non è filter: invert(1). Non è "metti tutto su sfondo nero". È una palette separata e ci vuole cinque minuti a farlo bene.
L'errore più comune nel dark mode è usare filter: invert(1) o semplicemente invertire i colori. Il risultato è quasi sempre sbagliato — le immagini si invertono, i colori saturati diventano aggressivi, le ombre non funzionano. Il secondo errore più comune è annunciare il dark mode come feature importante quando è solo sfondo nero con testo bianco.
Il dark mode corretto ha una palette separata definita come CSS custom properties, e si attiva con prefers-color-scheme o con una classe sul <html>.
/* Design token con dark mode automatico */ :root { --bg: #ffffff; --surface: #f8fafc; --text: #0f172a; --muted: #64748b; --accent: #0ea5e9; } @media (prefers-color-scheme: dark) { :root { --bg: #0f172a; --surface: #1e293b; --text: #e2e8f0; --muted: #94a3b8; --accent: #38bdf8; /* più chiaro in dark */ } } /* Toggle manuale via classe */ .dark { --bg: #0f172a; /* ... */ }
box-shadow con colori chiari invece che scurimix-blend-mode o fornisci versioni separateCosa usare, perché, e soprattutto cosa non devi comprare/abbonare/imparare prima di aver fatto una sola riga di CSS.
| Tool | Cosa fa | Quando usarlo |
|---|---|---|
| Figma | Design, prototipo, handoff | Se lavori con un designer o vuoi progettare prima di codare |
| Excalidraw | Wireframe veloci, diagrammi | Sketching rapido, brainstorming, zero overhead |
| Tailwind CSS | Utility-first CSS framework | Quando vuoi costruire veloce senza design system custom |
| shadcn/ui | Componenti React pronti (copia nel progetto) | React + Tailwind, componenti accessibili senza libreria esterna |
| Radix UI | Primitive UI accessibili headless | Quando vuoi stile custom ma accessibilità garantita |
| Coolors.co | Generatore palette colori | Trovare combinazioni armoniche in 30 secondi |
| Google Fonts | Font gratuiti | Inter, Geist, JetBrains Mono — già ottimi per interfacce |
| Contrast Checker | Verifica ratio WCAG | Prima di decidere qualsiasi combinazione testo/sfondo |
| Lighthouse | Audit performance, a11y, SEO | DevTools → Lighthouse — gratis, diretto, usa sempre |
| axe DevTools | Audit accessibilità automatico | Extension browser, trova i problemi a11y evidenti automaticamente |
Prima di andare in produzione. Spuntala davvero, non solo leggila pensando "sì sì" e chiudendo la tab.
email, tel, number)