“Cos’è un Design System?” è la domanda sbagliata
Chiediamoci, invece, da cosa è composto un Design System?
Ciao a tutti, mi chiamo Mauro Erta e sono uno sviluppatore presso VLK STUDIO.
Negli ultimi anni ho avuto la grande opportunità di collaborare allo sviluppo di alcuni Design System e di sviluppare una libreria, di nome Morfeo, che ti aiuta a crearne uno tuo, in questo articolo vorrei condividere con te ciò che ho appreso durante queste esperienze.
Contenuti
· Il Problema: Developer Driven Design System
· La domanda sbagliata: Che cos’è un Design System?
∘ E se invece la domanda fosse semplicemente sbagliata?
· La vera domanda: Da cosa è composto un Design System?
∘ Design Language
∘ Design kit
∘ Component Library
∘ D̶e̶v̶e̶l̶o̶p̶e̶r̶ Sandbox
∘ Documentation
∘ Governance model
· Dividi et impera
· Ⓜ️ Morfeo
· 👋 Salutiamoci
Il Problema: Developer Driven Design System
In questi anni di sviluppi e continui refactoring, mi è capitato di notare un pattern ricorrente:
La maggior parte dei Design System sono fatti dagli sviluppatori, per gli sviluppatori;
O per meglio dire, non sono dei veri e propri design system, sono dei sistemi che cercano di riutilizzare componenti e regole comuni, ma in modo caotico, e con uno scarso risultato. Mi piace chiamare questi sistemi Developer Driven Design System (DDDS o, per gli amanti di Nintendo, 3DS).
È un fenomeno un pò strano, un design system dovrebbe essere frutto di una collaborazione tra designer e developer, i DDDS invece nascono dalla assenza di comunicazione, e dal tentativo di creare controllo della UI, ma che invece generano il più delle volte l’effetto completamente contrario.
Nei DDDS, quando il team di UI/UX richiede un nuovo sviluppo, la situazione più comune che si viene a creare è la seguente:
Esatto. I componenti a disposizione non riescono a rappresentare i nuovi layout e questo costringerà la creazione di nuovi componenti o la modifica di quelli esistenti; Sai cosa significa vero? Moltissime regressioni e l’innesco del classico fenomeno del sistemo da una parte e rompo dall’altra.
Dovremmo porci quache domanda in queste circostanze:
- Come è possibile che il sistema sia così fragile?
- Come è possibile che il team di design proponga degli aggiornamenti di così difficile implementazione?
La risposta è molto semplice: Mancata comunicazione!
E non intendo che sia una lacuna specifica degli sviluppatori o tantomeno dei designer, infatti, è di entrambi!
La colpa di una mancata comunicazione, è sempre condivisa!
Come dicevo prima, infatti, un Design System dovrebbe essere frutto di una collaborazione tra (quantomeno) designer e sviluppatori, se questa collaborazione non avviene è inevitabile la nascita di un DDDS, che non è altro che un nobile, ma purtroppo sbagliato, tentativo di implementare le regole del design, ma quindi la domanda è: Dove sono queste regole?
Se sei un designer e ti ritrovi in mano una applicazione brutta, non coerente e poco armoniosa, sappi che molto probabilmente tu hai anche più responsabilità di questo caos rispetto a qualche developer (probabilmente non) incapace, per una semplice ragione: tu conosci il design e le sue regole!
Cosa intendo con “Tu conosci il design”?
Intendo che un buon design dovrebbe comunicare, come fosse un linguaggio. A questo punto dovresti chiederti: Dov’è il mio linguaggio? Ho mai insegnato e mostrato questo linguaggio al team di sviluppo? Se la risposta è no, avevo ragione, anche tu hai la tua buona dose di colpe per il mare di inconsistenza in cui la tua applicazione sta affogando.
La domanda sbagliata: Che cos’è un Design System?
Se fai una ricerca su google, oppure anche qui su Medium, potrai trovare decine e decine di definizioni differenti. Verrebbe da chiedersi, come mai così tante? Bè semplice, perché un Design System non è una cosa sola!
Proverò comunque a dare la più semplice e breve definizione:
Un Design System è la sorgente di verità del comportamento visivo della tua applicazione
Ovviamente nessuno può essere pienamente soddisfatto di questa definizione, io in primis, e seppur la ritengo corretta, non penso che possa aiutare nessuno a cogliere il punto.
E se… la domanda fosse semplicemente sbagliata?
Un Design System non è una cosa sola, e sopratutto non coinvolge una sola persona.
È un insieme di più parti, create da diverse persone e con differenti capacità; Allora perché fermarsi ad una singola definizione? Se vuoi veramente capire che cos’è un Design System e magari crearne uno tutto tuo, è meglio focalizzarsi sul problema nella sua interezza, il quadro generale.
La vera domanda: Da cosa è composto un Design System?
Credo che Rangle.io abbia fatto un lavoro incredibile nello scomporre ed analizzare le varie parti di un design system, mi trovo in completo accordo con quanto scrivono in questo articolo di cui farò un riassunto e, successivamente, una mia interpretazione; Vi consiglio in ogni caso la lettura dell’articolo originale.
Rangle, divide il design system in 6 parti:
- Design Language
- Design Kit
- Component Library
- Developer sandbox
- Documentation
- Governance Model
Design Language
Come dicevo prima, un buon design deve comunicare come se fosse un linguaggio. Il Design Language è il punto di partenza per la costruzione del tuo Design System, esso comprende la definizione dei colori da utilizzare, delle sfumature, dei font, degli spazi, delle ombre... Sul Design language si baseranno tutti le prossime parti, la sua progettazione è fondamentale per la creazione di quella consistenza ed armonia che stai ricercando nel tuo prodotto.
Dal punto di vista applicativo, il Design Language è normalmente chiamato “tema” e può essere rappresentato con un oggetto che segue la specifica di System UI.
Design kit
È creato dai designer, rappresenta l’insieme dei componenti e dei layout di cui l’applicazione è composta, questi elementi sono creati coerentemente con il Design Language.
I più comuni programmi per la creazione di Design kit sono Figma, Sketch o Adobe XD.
Component Library
È creato dagli sviluppatori ed è l’implementazione del Design Kit: è quindi l’insieme dei componenti e dei layout che nel concreto compongono la tua applicazione. La Component Library deve essere la rappresentazione esatta del design kit, queste due parti devono essere sempre allineate.
La Component Library è tipicamente realizzata scrivendo componenti con React, Vue, Svelte, Angular o Web Components.
D̶e̶v̶e̶l̶o̶p̶e̶r̶ Sandbox
È il posto dove poter testare il comportamento dei vari componenti, di visualizzarli in isolamento e testarne il funzionamento al variare di proprietà come dimensione, colore e risoluzione schermo. Esistono vari tool che permettono di creare una Developer Sandbox, il più famoso tra questi è probabilmente Storybook. Questa parte è importantissima e si collega molto bene alla prossima, infatti, strumenti come Storybook oltre a dare un playground per i nostri componenti rappresentano anche un modo semplice per documentarli e per mostrare lo stato della Component Library ai designer che possono facilmente avere un confronto con il proprio Design Kit.
A differenza di Rangle, preferisco chiamare questa parte semplicemente Sandbox, perché ritengo che dare la possibilità anche ai designer di giocare con la Sandbox possa aiutare parecchio la comunicazinoe fra i team, i designer possono capire lo stato della component library, se è congrua con il Design Kit, e cosa è possibile fare con essa.
Documentation
La potenza è nulla senza controllo.
Una buona documentazione comprende tipicamente una descrizione di ogni componente, descrivendone funzionalità, casi di utilizzo e relazioni con altri componenti. Dovrebbe inoltre includere informazioni di più alto livello così da descrivere chiaramente l’intento del design system, la sua filosofia e le regole per assicurare armonia nella composizione dei vari componenti.
Dei bei tool per scrivere e mantenere la documentazione sono Gitbook, Confluence, Notion oppure, nel caso di siti interamente dedicati, Docusaurus o Nextra. Come detto nel punto precedente però, la parte della documentazione più specifica sui componenti potrebbe essere integrata direttamente nella Sandbox.
Governance model
Così come qualsiasi prodotto, sia software che hardware, anche un Design System una volta creato dovrà essere mantenuto. Con mantenimento si intende non solo (l’inevitabile) bug fixing, ma anche il suo ampliamento nel corso del tempo, per permettere l’inserimento di nuovi componenti o la modifica di quelli esistenti. Il Governance Model descrive i processi che devono essere seguiti per l’aggiornamento del Design System.
Vedere il Design System come una composizione di queste 6 parti rafforza ancora di più il concetto espresso nella prima parte dell’articolo, e cioè che esso è frutto di una comunicazione tra designer e sviluppatori.
Questa collaborazione però, non deve essere interpretata come un’allargamento delle responsabilità, anzi, tutto il contrario!
Dividi et impera
L’aver scomposto il Design System suggerisce anche come i vari team dovrebbero interagire tra di loro: Design Language e Design Kit sono sicuramente responsabilità del team di design, Component Library e Developer Sandbox sono ovviamente a carico del team di sviluppo, Documentation e Governance Model riceveranno contribuzioni da entrambe le squadre relativamente ai propri sviluppi e processi.
Ecco il motivo della piccola riflessione fatta all’inizio di questo articolo:
La maggior parte dei Design System sono fatti dagli sviluppatori per gli sviluppatori
Credo che ora sia chiaro quanto importante sia vedere il Design System come la composizioine di più parti, in questo modo viene molto semplice dividere anche le responsabilità e permettere una collaborazione vincente.
Dove abbiamo applicato questi concetti, abbiamo percepito svariati vantaggi, come:
- Armonia nelle schermate dell’app: I nuovi layout e componenti, essendo creati a partire da un Design Language comune, sono consistenti tra di loro, anche se sviluppati da diversi team di sviluppo;
- Pulizia del codice: avere una rigida documentazione e regole nella costruzione delle schermate ha migliorato notevolmente la qualità e la manutenibilità del codice prodotto;
- Comunicazione tra i reparti: Il gruppo di design e di sviluppo hanno lavorato a strettissimo contatto. La condivisione di un linguaggio comune (Design Language) per la creazione dei componenti sia del team di sviluppo che del team di design ha reso la comunicazione molto più immediata.
- Performance: a regime, costruire nuovi layout è diventato quasi come giocare con i lego, i vari componenti si incastrano tra di loro con armonia e nei modi per cui sono stati progettati permettendoci di implementare nuove funzionalità in tempi nettamente inferiori;
- Curva di apprendimento: entrare in confidenza con una code-base di grosse dimensioni è sempre una grande impresa, inutile dire come una standardizzazione dei processi agevoli anche l’apprendimento di essi, anche i nuovi membri hanno appreso in poco tempo i concetti e le meccaniche dietro al Design System;
- Scalabilità: Oltre a migliorare i tempi di progettazioni e sviluppo, le interfacce prodotte sono risultate anche più predisposte a poter essere modificate ed aggiornate con nuove funzionalità.
Come si può notare, il fatto che ora la nostra applicazione sia finalmente bella da vedere, è quasi un effetto collaterale di un processo che ha portato benefici a tutte le aree dell’azienda: dalla qualità e manutenibilità del codice lato sviluppo, all’armonia e coerenza delle interfacce lato design, alle performance e scalabilità lato business.
Penso sia tutto merito del vecchio e caro “Dividi et impera” declinato, in questa circostanza, nella divisione del Design System in parti che possono essere ottimizzate e pensate dai team che hanno competenze verticali su quel campo, ma con una direzione unica seguita da tutti.
Ⓜ️ Morfeo
Volevo chiudere questo articolo introducendovi Morfeo, un insieme di librerie e strumenti che ti aiutano nella creazione di un Design System.
Puoi integrare Morfeo in qualsiasi framework o libreria javascript; Con esso potrai creare stili e componenti fortemente basati su un Design Language centralizzato, supporta il Multi-Theming nativamente ed è facilmente estendibile e testabile; Inoltre, grazie all’estensione per browser permette di avere una Developer Sandbox basata sui tuoi temi e componenti, completamente auto-generata e sempre disponibile nel browser.
Morfeo è ancora in beta, stiamo sviluppando nuove funzionalità e lo stiamo testando in diversi progetti così da renderlo production-ready il prima possibile, se però sei curioso, questo è il sito web:
Mentre qui, invece, la pagina Github:
Ed infine qui, il link per installare la web extension ( che puoi provare direttamente sul sito di Morfeo):
👋 Salutiamoci
Sono curioso di ricevere opinioni e pareri e magari sentire anche le vostre esperienze nella creazione di design system.
Nel caso tu voglia lasciarmi un feedback, ti invito a lasciarmi un commento a questo articolo, se invece vuoi parlare con noi del progetto Morfeo, non c’è modo più veloce del nostro server Discord:
Grazie per essere arrivati fin qui!
