Scala tipografica per UI di prodotto: dimensioni che reggono ovunque

Una scala tipografica è un insieme fisso di dimensioni del carattere, ognuna derivata da una dimensione base tramite un rapporto scelto, che dà a una UI di prodotto una sola gerarchia invece di decine di valori improvvisati. Alla fine di questa guida avrai una scala di sette-nove dimensioni, nominate come token, che regge dal telefono a 320px al monitor a 1440px e supera lo zoom al 200% senza rompere il layout.

Il motivo per farlo non è ordine estetico. È che le dimensioni del carattere scelte a caso sono il modo più comune in cui una UI inizia a sembrare non finita. Un bottone a 15px accanto a un'etichetta a 14px accanto a un titolo a 22px si legge come rumore, perché l'occhio non capisce se le differenze sono volute. Una scala rende ogni dimensione una decisione già presa una volta, così l'interfaccia parla con una voce sola.

Cosa ti serve prima di iniziare

• Una dimensione base per il corpo del testo. Usa 16px. Il web ci è arrivato intorno al 2010 perché un testo più piccolo peggiora la leggibilità a distanza di monitor, e Safari su iOS zooma qualsiasi campo di input sotto i 16px.
• Un rapporto. Un singolo numero tra 1,2 e 1,333 che distanzia le dimensioni.
• Un posto dove salvare i valori come token (custom property CSS, una collezione di variabili Figma, o entrambi tenuti in sincrono).
• Dieci minuti e la disponibilità a rifinire a mano l'estremità piccola, perché la matematica pura del rapporto lì si rompe.

Passo 1: fissa la base a 16px in rem

Dichiara la dimensione del corpo una volta sola, in rem, e lascia che tutto il resto la riferisca. rem è relativo alla dimensione del carattere della radice, quindi rispetta l'impostazione del browser dell'utente e cresce correttamente sotto zoom. Una dimensione in px ignora del tutto quell'impostazione. È la differenza di accessibilità più grande dell'intera scala: le WCAG non impongono un minimo in pixel, ma richiedono che il testo si ridimensioni al 200% senza perdita di contenuto, e il testo basato su rem lo fa senza sforzo.

Passo 2: scegli un rapporto, poi smetti di fidartene all'estremità piccola

Il rapporto decide quanto contrasto c'è tra dimensioni adiacenti. La terza minore (1,2) tiene i passi vicini e si adatta a strumenti B2B densi, ricchi di dati. La terza maggiore (1,25) è il default sicuro per la maggior parte delle UI di prodotto. La quarta giusta (1,333) apre un divario più ampio e si legge in modo più editoriale, meglio su pagine di marketing che dentro un'app. Il riferimento Imperavi UI Typography spiega bene perché la cosa che scegli davvero è il rapporto, non le singole dimensioni.

C'è un tranello. Applicato alla lettera, un rapporto collassa all'estremità piccola. Da una base di 16px, un rapporto di 1,2 dà 13,3px, poi 11,1px, poi 9,3px per i due passi sotto il corpo. In un'interfaccia reale sono illeggibili. Quindi usi il rapporto per generare l'estremità grande e rifinisci a mano le due dimensioni sotto il corpo verso valori leggibili. Non è barare. È ciò che fa ogni design system maturo.

Passo 3: nomina le dimensioni come token, mai come pixel

La scala qui sotto è una terza maggiore attorno a 1,25 rifinita a mano, con una base di 16px. Salva ogni riga come token semantico, non come valore in pixel, così un componente riferisce --font-size-body e mai il numero letterale.

• caption: 13px, interlinea 18px
• small: 14px, interlinea 20px
• body: 16px, interlinea 24px
• body-lg: 18px, interlinea 28px
• title-sm: 20px, interlinea 28px
• title: 24px, interlinea 32px
• heading: 30px, interlinea 36px
• display: 38px, interlinea 44px

Otto dimensioni coprono quasi ogni prodotto. Se ti ritrovi a cercarne una nona, aggiungila di proposito in cima per un hero, non in mezzo per tappare un problema di spaziatura. Nominare per ruolo invece che per dimensione è ciò che ti permette di ritarare l'intera scala più avanti senza toccare un solo componente. Stessa idea del resto della tua architettura di design system: il componente chiede un lavoro, il sistema risponde con un valore.

Passo 4: rendi fluide con clamp() solo le dimensioni display

La tipografia fluida con clamp() scala una dimensione in modo continuo tra un minimo e un massimo al variare del viewport, senza breakpoint. La sintassi è clamp(MIN, PREFERITO, MAX), e il valore preferito deve mescolare un'unità viewport con un termine in rem, per esempio clamp(1.9rem, 1rem + 3vw, 2.75rem). La parte in rem è ciò che tiene in vita lo zoom: un valore in solo vw resta ancorato al viewport e si rifiuta di crescere quando un utente zooma, un vero fallimento di accessibilità documentato a fondo da LogRocket e Smashing Magazine.

Applica il dimensionamento fluido solo a heading e display. Il testo del corpo e quello della UI restano fissi. Una dimensione del corpo fluida deriva mentre la finestra si ridimensiona, e su un telefono stretto può scivolare sotto la soglia leggibile prima che tu te ne accorga. Gli utenti leggono il corpo del testo. Danno un'occhiata al testo display. La fluidità appartiene dove c'è l'occhiata, non dove c'è la lettura.

Passo 5: abbina a ogni dimensione un'interlinea

L'interlinea fa parte della scala, non è una decisione separata. La regola che tiene: il testo grande vuole un moltiplicatore più stretto, il testo piccolo uno più largo. Il corpo a 16px vuole circa 1,5 (24px). Un display a 38px vuole circa 1,15 (44px), perché a quella dimensione un moltiplicatore di 1,5 apre un divario che spezza il titolo in righe scollegate. Salva l'interlinea accanto a ogni token di dimensione, così l'abbinamento viaggia insieme e nessuno deve tirare a indovinare.

Passo 6: fai rispettare i limiti

Sotto ogni scala di prodotto ci sono due limiti duri.

• 14px è il minimo pratico per qualsiasi testo che un utente deve leggere su desktop. Le caption a 13px vanno bene per timestamp e metadati, non per il contenuto.
• 16px è il minimo per i campi dei form su mobile. Safari e Chrome su iOS zoomano automaticamente su qualsiasi input con carattere sotto i 16px al focus, il che sposta il viewport e disorienta l'utente. La soluzione è una riga: metti gli input a 16px. Non ricorrere a maximum-scale=1 o user-scalable=no per sopprimere lo zoom, perché disattiva del tutto il pinch-zoom e viola le WCAG, come CSS-Tricks ha spiegato anni fa.

Come verifichi che la scala regga?

Tre controlli, in ordine. Primo, porta lo zoom del browser al 200% e conferma che il layout si ridisponga senza tagli o scroll orizzontale. Secondo, apri la stessa pagina a 320px di larghezza e conferma che nessun testo del corpo sia sceso sotto i 14px e nessun input sotto i 16px. Terzo, socchiudi gli occhi davanti a uno schermo reale: se non distingui all'istante un titolo da un sottotitolo dal corpo, il rapporto è troppo stretto e i passi hanno bisogno di più contrasto. Il test dello sguardo socchiuso coglie ciò che le misure in pixel non vedono.

Errori comuni e come risolverli

• La scala sembra piatta. Le dimensioni adiacenti sono troppo vicine. O alzi il rapporto o togli un passo intermedio, così le dimensioni rimaste si distanziano di più.
• I titoli sembrano larghi e scollegati. L'interlinea è uniforme lungo tutta la scala. Stringi il moltiplicatore su tutto ciò che sta sopra title.
• I form su mobile zoomano al tocco. Un input è sotto i 16px. Alzalo. È il bug tipografico più comune nel SaaS in produzione.
• Le dimensioni tornano nel tempo a valori arbitrari. I componenti scrivono pixel a mano invece di riferire i token. Fai il lint dei valori font-size grezzi che non sono un riferimento a token.

Dove portarla dopo

La scala è uno strato di un sistema tipografico. Peso, spaziatura tra le lettere e il rapporto tra font-size e token di spaziatura stanno tutti sopra di essa. Se stai decidendo dove far vivere questi valori, i compromessi sono nel nostro confronto tra le categorie di un design system. La scala è la parte che decide più direttamente se una UI si legge come finita, ed è per questo che vale la pena renderla esatta prima di ogni altra cosa.