Lavorare senza un designer

Non sono un designer. Riconosco una buona UI, riesco ad articolare perché qualcosa non funziona visivamente, ma non ho gli istinti che si sviluppano dopo anni di pensiero visuale. Lasciato a me stesso, posso passare quarantacinque minuti a scegliere tra due sfumature di grigio e finire per non scegliere nessuna delle due.

Per molto tempo ho trattato questa lacuna come qualcosa da colmare — una cosa che sarei migliorato leggendo abbastanza articoli su tipografia, spaziatura e gerarchia visiva. Era il frame sbagliato. La domanda giusta non è come diventare un designer migliore. È come prendere il minor numero possibile di decisioni di design.

Cosa dà davvero un designer

Non è solo gusto. Un designer ti dà un sistema — un insieme coerente di regole che governano spaziatura, colore, tipografia e interazione. Una volta che quelle regole esistono, la maggior parte delle decisioni UI si risolve automaticamente. Non scegli tra dimensioni; scegli da una scala. Non scegli un colore; scegli un token da una palette con un ruolo definito.

Quando non c'è un designer, non c'è un sistema. E senza un sistema, ogni componente diventa una nuova negoziazione. Questo titolo deve essere 20px o 22px? Ci vogliono 16px di padding o 20px? Il border radius deve corrispondere alla card o al pulsante? Queste decisioni sembrano piccole prese singolarmente. Si accumulano in fretta, e l'incoerenza si sedimenta in modi che rendono un prodotto impreciso senza che nessuno riesca a spiegare esattamente perché.

Il problema dello sviluppatore solista non è che prende cattive decisioni di design. È che ne deve prendere troppe.

Fidati del framework

La soluzione a cui sono arrivato è fidarsi di un design system quasi ciecamente. Non perché ogni decisione che un framework prende sia quella giusta, ma perché decisioni sbagliate ma coerenti sono meglio di decisioni incoerenti. Un pulsante leggermente troppo piccolo su ogni schermata sembra intenzionale. Un pulsante leggermente troppo piccolo su tre schermate e leggermente troppo grande su altre due sembra rotto.

Questo significa accettare i vincoli del sistema invece di combatterli. Quando un framework ti dà una scala di spaziatura, usa la scala — non ricorrere a valori pixel arbitrari perché qualcosa sembra leggermente fuori posto. Quando ti dà una palette di colori, usa la palette. Nel momento in cui inizi a fare override in modo frammentato, hai lasciato il sistema e sei da solo.

Come ci sono arrivato sul web

Il mio primo progetto serio usava Material UI. Era la scelta ovvia all'epoca — una libreria di componenti completa, con il linguaggio di design di Google integrato. La velocità era reale. Si poteva costruire un'interfaccia funzionale e ragionevolmente coerente velocemente, senza prendere molte decisioni. Il problema arrivava dopo, quando il prodotto aveva bisogno di sembrare sé stesso piuttosto che un'app Material Design. Convincere MUI a togliersi di mezzo richiedeva di combatterlo a ogni passaggio.

Sono passato a Mantine, più flessibile e piacevole da usare. I componenti sono ben progettati, la documentazione è ottima e non impone la stessa identità visiva rigida. Ma continuavo a ritrovarmi nella stessa tensione di fondo: una libreria di componenti è l'astrazione di qualcun altro sopra il CSS, e quell'astrazione ha dei bordi. Ogni volta che avevo bisogno di qualcosa leggermente fuori dal percorso normale, finivo a leggere il codice sorgente e a scrivere override.

Tailwind ha risolto questo problema spostando l'astrazione a un livello più basso. Non ti dà componenti — ti dà un insieme limitato di primitive. Una scala di spaziatura, una scala tipografica, una palette di colori. Le decisioni sono comunque vincolate, ma la composizione è tua. Non ci sono componenti da combattere, nessun meccanismo di override da capire. Costruisci quello che ti serve usando valori che il sistema ha già scelto, e il risultato è coerente perché le primitive sono coerenti.

Lo stesso schema, ripetuto su mobile

Su React Native ho seguito un percorso quasi identico. Ho usato UI Kitten e React Native Paper — entrambi solidi, entrambi con design system coerenti, entrambi basati sui componenti. Gli stessi compromessi si sono applicati: veloce da avviare, friction per personalizzare, sempre più goffo quando le esigenze del prodotto divergevano dalle assunzioni della libreria.

NativeWind ha portato il modello Tailwind su React Native — lo stesso approccio utility-first, gli stessi vincoli applicati attraverso un linguaggio di design condiviso. Il cambiamento mi è sembrato familiare perché era la stessa mossa: da "usa i nostri componenti" a "usa la nostra scala".

La trappola da evitare

C'è una versione di questa storia che va storta. Lo sviluppatore decide di saperne più del framework e inizia a fare override — valori di spaziatura custom qui, colori arbitrari lì, un componente che piega le regole della libreria perché il design richiedeva qualcosa di leggermente diverso. Sei mesi dopo, la UI è incoerente in modi difficili da tracciare, perché le regole del sistema non si applicano più in modo uniforme.

Il valore di un design system non sta nelle singole decisioni che prende. Sta nell'uniformità. Viola abbastanza regole e non hai più un sistema — hai una collezione di scelte ad hoc che condividono una libreria di componenti.

Quando ho accettato che il mio compito era restare dentro i vincoli invece di fuggirne, la UI è migliorata senza che io diventassi un designer migliore. Il lavoro si è spostato dal prendere decisioni al costruire cose. È lì che voglio passare il tempo.

Il vincolo è la funzionalità

Lavorare senza un designer significa accettare che non produrrai interfacce da design award. Quello che puoi produrre è una UI coerente, funzionale, solida — se scegli un sistema e ti impegni a seguirlo.

La scelta del sistema conta meno dell'impegno verso di esso. Quello che rompe la coerenza non è scegliere il framework sbagliato. È scegliere quello giusto e poi decidere di saperne di più.