Perché un'interfaccia sembra poco professionale: 9 dettagli

Un'interfaccia sembra poco professionale quando le sue piccole scelte non vanno d'accordo fra loro: tre raggi degli angoli diversi nella stessa schermata, icone prese da due set, un prezzo che scivola di lato ogni volta che si aggiorna. Nessuno di questi è un bug. Messi insieme dicono a chi usa il prodotto che nessuno ha controllato, e l'impressione si forma prima ancora di provare una funzione.

Quell'impressione è stata misurata. In uno studio di Stanford in cui le persone confrontavano la credibilità di siti reali, l'aspetto grafico è stato il fattore citato più spesso, nel 46,1% dei commenti, più della struttura dei contenuti. Lo studio è del 2002 e il web nel frattempo è cambiato. Il risultato però torna con quello che vediamo nelle revisioni: la cura dei dettagli viene letta come attenzione, e l'attenzione come garanzia che il prodotto funzioni.

Questa lista è il controllo che facciamo su una schermata prima di considerarla pronta. I temi più ampi hanno un articolo a parte: la scala tipografica, la gerarchia senza colore e l'allineamento ottico. I nove dettagli qui sotto sono quelli che sfuggono quando il resto è già a posto.

Come abbiamo scelto i nove dettagli

Ogni dettaglio rispetta tre condizioni. Chi non fa parte del team lo nota in pochi secondi, anche se non saprebbe dargli un nome. Si verifica su una schermata finita, a occhio o con gli strumenti per sviluppatori del browser. E si corregge con una regola, un token o una proprietà CSS, quindi resta corretto una volta che il componente lo incorpora. Dove uno standard pubblico fissa una soglia (WCAG 2.2, Core Web Vitals), riportiamo il numero e la fonte.

Quali dettagli fanno sembrare un'interfaccia non finita?

1. Spaziature fuori scala

Misurando gli spazi di una schermata in bozza capita spesso di trovare 13, 14, 15 e 18 pixel che fanno lo stesso lavoro. Ogni valore sembrava giusto quando è stato scritto. Insieme creano un ritmo che l'occhio percepisce come irregolare, anche senza capire perché.

Serve una scala di spaziature, di solito su base 4 o 8 pixel, esposta come token perché nessuno scriva un numero a mano. Sopra la scala vale una regola: gli elementi collegati stanno più vicini di quelli che non lo sono. Un'etichetta appartiene al suo campo, quindi gli sta più vicina che al campo sopra. Quando uno spazio ha bisogno di un'eccezione per sembrare giusto, si tratta di una correzione ottica: va scritta nel componente, non lasciata in un margine isolato.

2. Raggi degli angoli che non si incastrano

Un pulsante con raggio di 16 pixel dentro una card con lo stesso raggio, a 8 pixel dal bordo, ha gli angoli che stonano. Le due curve non corrono parallele e la forma interna sembra gonfia.

La regola che usano i designer: il raggio esterno è uguale al raggio interno più il padding che li separa. Un pulsante da 12 pixel dentro 8 pixel di padding chiede una card da 20. La formula è un punto di partenza da verificare a occhio, perché con raggi interni molto piccoli il risultato può sembrare troppo tondo. L'altra metà della soluzione è una scala breve, tre o quattro valori, così una schermata non ne accumula sei.

3. Icone che non si accordano con il testo

Le icone prese da due librerie portano con sé due spessori di tratto, due stili di angolo e due idee diverse di quanto spazio occupare nel proprio riquadro. Accanto al testo la differenza salta all'occhio. Un'icona da 24 pixel vicino a un testo da 14 urla. Un tratto da 2 pixel vicino a un carattere leggero appesantisce.

Si usa un solo set di icone. Le icone si dimensionano sull'interlinea del testo che accompagnano, con un tratto proporzionato al peso di quel testo. Poi l'allineamento verticale si controlla a occhio: l'icona è centrata sul suo riquadro, il testo sulla sua altezza della x, quindi un'icona centrata in modo matematico spesso sembra un pixel troppo in alto. È lo stesso tipo di correzione di cui parliamo nell'articolo sull'allineamento ottico.

4. Numeri che ballano

Quasi tutti i caratteri per interfacce usano cifre proporzionali: l'1 è più stretto dell'8. Dentro una frase va benissimo. In una colonna di tabella, in un totale che si aggiorna o in un conto alla rovescia è un problema. Le cifre non si allineano e un numero che cambia sul posto si sposta di lato a ogni aggiornamento.

Basta una proprietà CSS. font-variant-numeric: tabular-nums passa a cifre tutte della stessa larghezza, e funziona in tutti i browser principali da gennaio 2020. Va applicata a tabelle, prezzi, timer e a ogni numero che cambia mentre qualcuno lo guarda. Poi le colonne numeriche si allineano a destra, così le unità stanno sotto le unità. È una riga di codice, e una dashboard sembra finita grazie a quella.

5. Stati di interazione mancanti

Una bozza di solito disegna ogni controllo a riposo e si ferma lì. Un controllo pronto per l'uso ne ha bisogno di altri: hover, premuto, focus da tastiera, disabilitato, in caricamento. Un pulsante che non reagisce al clic sembra rotto. Un form che perde l'indicatore di focus sembra incompleto a chiunque navighi da tastiera.

Le WCAG 2.2 fissano il minimo. Il focus da tastiera dev'essere visibile, e l'elemento che lo riceve non può essere coperto del tutto da contenuti della pagina, come un header fisso o un banner dei cookie. I bersagli cliccabili devono misurare almeno 24 per 24 pixel CSS, oppure avere abbastanza spazio intorno perché un cerchio di 24 pixel centrato su ciascuno non tocchi quelli vicini. Sono entrambi criteri di livello AA. Gli stati si progettano dentro il componente, così ogni istanza li eredita.

6. Testo che va a capo male

Un titolo che lascia una sola parola sulla seconda riga. Il titolo di una card che in inglese sta su una riga e in tedesco su tre. Il nome lungo di un cliente che spinge fuori dalla card il pulsante accanto. Le bozze usano testi della lunghezza scelta dal designer. I testi veri arrivano di ogni lunghezza.

Per i titoli, text-wrap: balance pareggia la lunghezza delle righe, e lo supportano tutti i browser principali. Per i paragrafi, text-wrap: pretty evita l'ultima parola isolata; dove il browser non lo supporta il testo va a capo come prima, quindi aggiungerlo non rompe niente. Per tutto ciò che arriva dai dati, la regola si decide prima: troncare con i puntini e mostrare il valore intero al passaggio del mouse, ammettere due righe, oppure lasciar crescere il layout. Poi si prova con il valore reale più lungo che c'è, mai con quello medio.

7. Layout che salta durante il caricamento

La pagina compare, la persona sta per toccare un pulsante, sopra si carica un'immagine e il pulsante si sposta. Poche cose fanno sembrare un prodotto più economico. Google lo misura come Cumulative Layout Shift, e un buon punteggio è 0,1 o meno al 75° percentile dei caricamenti.

Quasi sempre le cause sono tre: immagini senza dimensioni, contenuti inseriti sopra quello che è già sullo schermo, font web che si caricano con una misura diversa. A ogni immagine e video vanno dati gli attributi width e height, o un aspect ratio, così il browser riserva lo spazio. Gli stati di caricamento devono avere la misura di quello che conterranno, per esempio una riga scheletro alta quanto una riga vera. Lo spazio per i banner si riserva prima che arrivino. La nostra guida ai Core Web Vitals su Next.js entra nei dettagli del framework.

8. Testo grigio che non si legge

Un testo secondario grigio chiaro sembra raffinato in uno strumento di design, su un monitor calibrato. Sul portatile, alla luce del giorno, sparisce. Lo stesso vale per i bordi dei campi così tenui che il campo quasi non si trova.

Le WCAG danno numeri per entrambi i casi. Il testo normale richiede un rapporto di contrasto di almeno 4,5:1 rispetto allo sfondo, il testo grande 3:1. Le parti visive che identificano un controllo, come il bordo di un campo o il contorno di una casella di spunta, richiedono 3:1 rispetto ai colori vicini. La scala dei grigi si costruisce con questi rapporti decisi in partenza, così il token del testo secondario li rispetta per costruzione. Aiuta anche avere meno grigi: una schermata con sette grigi leggermente diversi sembra improvvisata, e tre o quattro gradini bastano per quasi ogni interfaccia.

9. Testi e dati segnaposto

"Senza titolo", lorem ipsum, un pulsante con scritto "Invia", una tabella in cui ogni riga ha un nome ordinato e tre elementi esatti. Le bozze sono piene di contenuti che non dovevano andare online, e qualcuno ci va lo stesso. I dati sono il caso più sottile: il design mostra 3 elementi, in produzione ne arrivano 0, 1 e 4.000.

Prima di chiudere una schermata, la si prova nei casi limite: nessun dato, un solo elemento, una lista molto lunga, un nome molto lungo, un'immagine mancante, un errore. Ognuno chiede una risposta progettata, ed è il tema dell'articolo sugli empty state. Poi si rilegge ogni etichetta come la leggerebbe l'utente. "1 elementi" e un "Invia" generico sono dettagli piccoli, e si notano entrambi. Per i conteggi, Intl.PluralRules sceglie la forma plurale giusta in ogni lingua in cui esce il prodotto.

Da quali correzioni conviene partire?

I nove dettagli non costano tutti uguale. Raggruppati per quanto cambiano l'impressione a parità di ore di lavoro:

• Una riga di CSS: cifre tabulari, titoli bilanciati, dimensioni delle immagini. Si possono pubblicare oggi.
• Un token: la scala delle spaziature, la scala dei raggi, una scala dei grigi con il contrasto già calcolato. Quando i componenti leggono i token, migliorano tutte le schermate insieme.
• Un componente: stati di interazione, dimensioni delle icone, regole di troncamento. Si correggono una volta nel componente e ogni istanza le eredita.
• Un'abitudine di revisione: dati nei casi limite e testi veri. Il codice qui non basta: vanno nella definizione di "finito" del team.

Il criterio dietro il raggruppamento: un dettaglio corretto a mano su una schermata torna fuori sulla successiva. Un dettaglio corretto in un token o in un componente resta corretto. Per lo stesso motivo questi problemi si accumulano nel tempo nei prodotti senza un sistema, il component drift di cui abbiamo già scritto.

Come si controlla una schermata in dieci minuti?

Facciamo questo controllo su ogni schermata prima del rilascio. Serve solo un browser.

1. Si riduce lo zoom al 50% e si strizzano gli occhi. Spazi irregolari e raggi fuori posto emergono prima dei contenuti.
2. Si clicca sulla barra degli indirizzi e si scorre tutta la pagina con il tasto Tab. Ogni controllo deve mostrare il focus, e nessuno deve sparire dietro un elemento fisso.
3. Negli strumenti per sviluppatori si rallenta la rete con un profilo mobile lento e si ricarica. Si guarda se qualcosa si sposta.
4. Si sostituisce un nome con il valore reale più lungo del database, e una lista con una lista vuota.
5. Si misura il contrasto del testo più chiaro e del bordo più tenue.
6. Si leggono ad alta voce tutte le etichette dei pulsanti.

Sei controlli richiedono una decina di minuti, e trovano quasi tutti i nove dettagli prima che li trovi un utente.