Il design system serve a chi mantiene il software

Aprite un gestionale che è in vita da tre anni e contate i pulsanti. Non quanti sono, quanti tipi ci sono. Di solito quattro: quelli originali, quelli del modulo fatto da un altro sviluppatore, quelli della sezione rifatta di corsa prima di una fiera, e quelli che nessuno ricorda di aver approvato. Stessa storia per i campi data, le tabelle e le finestre di conferma.

Nessuno l'ha deciso. Si è accumulato, una schermata urgente alla volta, e tutti hanno imparato a convivere. La parte interessante è che gli utenti se ne lamentano molto meno del budget.

Il costo si vede nei preventivi, non nelle schermate

Ogni schermata nuova di quel gestionale comincia con una serie di decisioni già prese quattro volte: quale pulsante, quali spaziature, come si mostrano gli errori, cosa succede mentre i dati caricano. Ogni decisione è piccola. Moltiplicata per ogni funzione per tre anni, è il motivo per cui un form che dovrebbe costare un giorno ne costa tre.

Il secondo costo è il collaudo. Quattro tipi di tabella significano quattro comportamenti da verificare dopo qualsiasi modifica, e in pratica significano che nessuno li verifica tutti e quattro. I bug poi arrivano dalla sezione meno usata, che è anche quella che nessuno ha voglia di toccare.

Non è una libreria di componenti

Un design system che meriti il nome ha tre livelli. Prima i token: colori, scala delle spaziature, dimensioni del testo, raggi dei bordi, quella manciata di valori da cui è costruito tutto il resto. Poi i componenti che li usano. Poi le regole d'uso, che sono il livello che quasi tutti saltano: quando usare una finestra modale invece di una pagina, quando serve una conferma, dove compaiono gli errori in un form, cosa può essere l'azione principale di una schermata.

Saltare il primo livello produce una libreria in cui ogni componente si scrive dentro il suo grigio, e cambiare la palette diventa una sostituzione di stringhe su tutto il codice. Saltare il terzo produce una libreria bella usata in modo incoerente, che a distanza di due schermate è indistinguibile dal non avere alcun sistema.

Le regole possono stare in una pagina. Noi le scriviamo come un elenco di coppie: usa questo, non quello. Il pannello laterale per modificare un singolo record, la pagina per tutto ciò che coinvolge più di uno. Mai un'azione distruttiva accanto a quella principale. Gli errori sotto al campo, non solo in testa alla pagina. È documentazione poco affascinante ed è la parte che gli sviluppatori leggono davvero.

Dieci componenti coprono quasi tutto il lavoro

Portali e gestionali sono in gran parte form e tabelle, che è una buona notizia, perché la superficie utile è piccola. Pulsante, campo di testo con la sua etichetta e il suo errore, menu di selezione, selettore di data, tabella con ordinamento e paginazione, finestra modale e pannello laterale, notifica, stato vuoto, segnaposto di caricamento, e un impianto di form che decide dove stanno le etichette. Con quelli fatti bene, la schermata successiva è assemblaggio invece che progettazione.

Conta anche cosa non c'è in quell'elenco. Grafici, costruttori di filtri complessi e qualsiasi cosa con il trascinamento conviene lasciarli fuori dal primo giro: sono i componenti che con più probabilità serviranno in un posto solo, e costruirli per un secondo uso ipotetico è il modo in cui i design system vengono abbandonati.

Gli stati che nessuno disegna

I mockup mostrano il percorso felice: una tabella con otto righe di dati plausibili. La produzione mostra il resto. La tabella con zero righe, quella con quarantamila, quella in cui la richiesta è andata in errore, quella che l'utente non ha il permesso di vedere, quella che sta ancora caricando su una connessione lenta in magazzino.

Nel software interno questi non sono casi limite, sono metà di quello che la gente guarda davvero in una giornata di lavoro. Uno stato vuoto che spiega cosa fare, invece di un rettangolo bianco, elimina chiamate all'assistenza. Uno stato di permesso negato che dice a chi rivolgersi ne elimina altre. Disegnarli una volta dentro il componente significa che ogni schermata eredita la risposta, comprese quelle che verranno costruite tra due anni da qualcuno che non ha letto le linee guida.

L'accessibilità è gratis se vive nel componente

Un contorno di focus visibile, contrasto sufficiente, un'etichetta legata davvero al suo campo, una navigazione da tastiera che segue un ordine sensato, un errore annunciato ai lettori di schermo. Risolti dentro dieci componenti, valgono per tutta l'applicazione senza che nessuno ci ripensi. Risolti schermata per schermata, non vengono risolti mai, ed è la situazione che quasi tutti scoprono quando l'accessibilità diventa un obbligo di legge e non una preferenza.

Come si introduce su un progetto vivo

Non riscrivendo. La versione che fallisce è quella in cui un team ferma lo sviluppo per due mesi per costruire una libreria di componenti, e quando torna scopre che l'azienda ha perso interesse. La versione che funziona è noiosa: prima si estraggono i token, che è una modifica meccanica senza effetti visivi, poi si costruiscono i componenti solo quando una schermata nuova ne ha bisogno, poi si sostituiscono i vecchi quando una schermata è già aperta per un altro motivo.

Una cosa va protetta: un componente che non ha un proprietario torna a essere quattro pulsanti entro un anno. Qualcuno deve avere il permesso di dire no alla quinta variante, e la risposta a "qui ci serve un pulsante un po' diverso" deve essere una conversazione e non un file nuovo. È una decisione di processo, non di design, ed è il motivo per cui i design system reggono oppure muoiono in silenzio.

Niente di tutto questo riguarda il rendere il software più bello, anche se in genere lo diventa. Riguarda il far costare la ventesima schermata meno della quinta. Quando lavoriamo su interfacce e design di un'applicazione destinata a durare, quello è il numero che cerchiamo di spostare.