L'AI dentro un design system funziona solo se il sistema ha un confine

Ho visto parecchie squadre attaccare un modello al proprio design system e restare deluse dal risultato. La diagnosi che si danno quasi sempre è la stessa: il modello non capisce il nostro prodotto. Quasi sempre è sbagliata.

Il problema non è che il modello non capisce il prodotto. È che il prodotto non si è mai spiegato. Un design system che vive dentro la testa di tre persone funziona benissimo finché quelle tre persone rivedono ogni schermata. Nel momento in cui qualcosa genera al posto loro, tutto quello che era implicito diventa un buco.

Il sistema non è l’inventario dei componenti

Quando ho lavorato al sistema che teneva insieme sette testate, la parte lunga non è stata disegnare i componenti. È stata decidere cosa poteva essere condiviso e cosa doveva restare libero, e poi difendere quella linea davanti a sei redazioni che chiedevano tutte la loro eccezione.

Quella linea è la cosa che serve a un modello. Non l’elenco dei bottoni: la regola che dice perché un bottone è fatto così e in quali casi non lo è. Se la regola non è scritta da nessuna parte, il modello la inventa, e la inventa in modo plausibile. Plausibile è la parola pericolosa. Un componente sbagliato che sembra giusto passa la revisione più facilmente di uno sbagliato che sembra sbagliato.

Tre cose che ho visto mancare sempre

Le ragioni, non solo i valori. Un token che dice spaziatura-3: 24px non serve a niente da solo. Serve accompagnato dal motivo per cui esistono sette gradini e non quaranta. Senza il motivo, la prima richiesta strana produce un ottavo gradino, e il sistema comincia a perdere pezzi da lì.

I casi limite, scritti. Cosa succede al titolo quando la redazione scrive ottanta caratteri invece di trenta. Cosa succede alla card quando l’immagine manca. Sono le domande a cui un designer risponde in mezzo secondo e che nessuno mette mai su carta. Un modello che non le trova scritte risponde a caso, e la risposta a caso finisce in produzione.

Il perimetro del no. Un sistema utile dice anche cosa non deve succedere. Non esistono card dentro le card. Il colore di marca non tocca mai il testo di lettura. Sono frasi brevi, quasi banali da scrivere, e sono esattamente quelle che tengono insieme il risultato quando il volume di produzione sale.

Il vantaggio vero non è la velocità

La promessa che si sente di più è che si va più veloci. Sulle schermate semplici è vero, e non è granché interessante: le schermate semplici non erano il collo di bottiglia.

Il vantaggio che mi interessa è un altro. Quando il sistema è scritto abbastanza bene da guidare una macchina, è anche scritto abbastanza bene da guidare la persona nuova che entra in squadra il mese prossimo, il consulente esterno, la redazione che vuole fare da sola una pagina di servizio. La generazione assistita è un test di leggibilità del sistema. Se il modello produce schifezze, il sistema non è pronto nemmeno per gli umani.

Cosa faccio in pratica

Prima di collegare qualsiasi cosa, provo a rispondere per iscritto a tre domande: dove passa il confine tra condiviso e libero, quali sono i casi limite di ogni componente di lettura, e quali sono le cinque cose che nel prodotto non devono succedere mai. Se non riesco a rispondere, non è il momento di automatizzare. È il momento di finire il sistema.

Poi tengo la revisione umana esattamente dove stava prima: sulla gerarchia. Un modello compone bene, e giudica male cosa deve essere visto per primo. Quella decisione continua a costare poco tempo e a valere moltissimo, ed è l’ultima che ha senso delegare.