Design system per prodotti deep tech: un solo linguaggio dalla console agli strumenti firmware

Quando si pensa ai design system, si immaginano le app consumer: pulsanti, colori, una libreria di componenti in Figma e nel codice.

I prodotti deep tech hanno bisogno di design system di più, non di meno. Solo di un tipo diverso.

Un prodotto di sicurezza o industriale raramente è un’interfaccia sola. È una console web, uno strumento da riga di comando, un’API, documentazione, report per gli auditor, a volte un piccolo schermo su un dispositivo. Ogni parte la costruiscono team diversi, spesso con strumenti diversi. Senza un linguaggio comune, lo stesso concetto finisce con cinque nomi e tre colori.

Cosa cambia nel deep tech

Il vocabolario è il sistema. Nei prodotti consumer la coerenza è soprattutto visiva. Nel deep tech la principale fonte di confusione è il linguaggio. È un «dispositivo», un «asset», un «nodo» o un «endpoint»? Un risultato è «critico», «alto» o «grave»? Mettersi d’accordo sui termini, e farli rispettare tra console, CLI, API e documentazione, è il lavoro più prezioso che un design system può fare qui.

Gli stati portano rischio. Colori e etichette di stato non sono decorazione. Un utente agisce in base a loro. Devono essere coerenti ovunque, non devono mai affidarsi al solo colore e il loro significato va documentato con la stessa precisione di un’API.

I principali contributori sono ingegneri. Molte interfacce nel deep tech le costruiscono ingegneri senza un designer nella stanza. Il design system deve funzionare per loro: regole chiare, buone impostazioni predefinite, componenti facili da usare bene e difficili da usare male.

La densità dei dati è reale. Gli esperti hanno bisogno di tabelle, log e grafici densi. Un design system pensato per pagine di marketing ariose non li serve. Servono modelli per la densità che restino leggibili.

Come lo costruirei

1. Partire dal glossario. Prima dei componenti, definisci gli oggetti del dominio, i loro stati e i loro nomi. Mettilo nel repository, accanto al codice, dove gli ingegneri lo vedranno.

2. Usare token semantici. Dai ai token un nome per significato, non per valore: «status-critical», non «red-600». È l’unico modo per mantenere coerenza tra console web, palette del terminale e report stampato. Ne ho scritto in Token semantici.

3. Coprire le superfici non visive. Messaggi d’errore, formati di output della CLI, livelli di log, modelli di report e codici d’errore delle API fanno parte dell’esperienza. Dai regole anche a loro.

4. Integrare l’accessibilità. Contrasto, navigazione da tastiera, stati di focus e alternative testuali vanno dentro i componenti, così ogni team li ottiene senza sforzo. Vedi accessibilità negli strumenti di sicurezza.

5. Tenerlo piccolo e applicato. Un sistema breve usato ovunque batte uno grande non usato da nessuno. Regole di lint, checklist per la code review e modelli fanno più di un bellissimo sito di documentazione.

Perché conta per il business

La coerenza nel deep tech non serve a sembrare curati. Riduce gli errori, accorcia l’inserimento di nuovi clienti e nuovi ingegneri, e rende il prodotto più facile da sottoporre ad audit e da considerare affidabile.

Come ho sostenuto in Il design system è morto. Lunga vita al design system, gli strumenti cambiano ogni anno. Il bisogno di un linguaggio comune no. Nei prodotti tecnici complessi quel bisogno è solo più evidente.