DESIGN SYSTEM
RESTRUCTURE
Guidata la ristrutturazione del Design System: da un unico file a una struttura modulare basata su branch, per una collaborazione più chiara.
INTRODUZIONE
Quando sono entrato in Swydo, il Design System era organizzato in un unico file contenente ogni componente e asset usato dal prodotto, rendendo difficile per designer, sviluppatori e altri stakeholder trovare, scorrere o validare qualsiasi cosa. L'ho ristrutturato in file più piccoli, specifici per scopo, che comunicano tra loro — più facili da scorrere, e più facili da revisionare e a cui contribuire per l'intero team attraverso i branch.
PROGETTO
Il sistema è stato ricostruito mettendo al centro i principi di brand e di prodotto dell'azienda, per poi essere suddiviso seguendo i fondamenti dell'Atomic Design in Foundations, Essentials, Compositions, Icons e Illustrations — con i token documentati nel file Foundations per facilitare il dialogo tra designer e sviluppatori.
SFIDA
La sfida principale era rendere la nuova struttura adottabile, non solo più ordinata: i designer dovevano poter creare branch, iterare e richiedere revisioni su un singolo componente senza toccare il resto del sistema, mentre gli sviluppatori avevano bisogno di una documentazione di cui potersi fidare come fonte di verità.
IL MIO RUOLO
Ho guidato la ristrutturazione del Design System come Product Designer del team — analizzando il sistema esistente, definendo la nuova struttura dei file e la categorizzazione dei componenti, e documentando foundation e token, lavorando a stretto contatto con gli sviluppatori per far sì che il nuovo workflow attecchisse davvero.
NUOVA STRUTTURA
Sulla base di esperienze precedenti sui Design System, l'obiettivo principale era suddividere il design system in file più piccoli che comunicassero tra loro, rendendoli più leggeri e facili da scorrere.
La prima cosa che ho fatto è stata identificare il core dell'azienda, mettendo al centro del progetto i principi aziendali, sia di brand che di business. Da lì, il grafico qui sopra vuole mostrare come, dal core fino agli asset concreti, l'organizzazione degli asset possa diventare uno strumento che permette alle persone in azienda di avere voce in capitolo nella definizione di ogni singolo passaggio della creazione del Design System, con i designer alla guida del progetto. Qui sotto, un flowchart dettagliato di come questa organizzazione di responsabilità e divisione delle aree può svilupparsi.
DESIGN SYSTEM - SUDDIVISIONE DELLE CATEGORIE
La prima cosa da fare è stata la ricerca sui componenti disponibili. Dopo aver identificato la struttura dei componenti nel sistema precedente, li abbiamo classificati seguendo i fondamenti dell'Atomic Design, dividendo gli asset in: Foundations Essentials Compositions Icons Illustrations
FOUNDATIONS
Nel file Foundations, a differenza del sistema precedente, l'idea è lavorare con i Token che, come noto, facilitano il dialogo tra designer e sviluppatori.
Colori primitivi
Palette colori
Una volta aggiunti i token alla documentazione, ho anche creato una versione più tangibile progettando parte della documentazione nel file Foundation. Qui sotto un esempio per i colori primitivi.
Per quanto riguarda i componenti, l'idea principale è collocare nel file Foundations gli elementi non troppo complessi in termini di costruzione e rilevanti per la costruzione di altri elementi. Qui sotto un esempio del componente Button:
Il vantaggio di avere una documentazione suddivisa secondo questo criterio è che, quando serve creare una variante o modificare alcune impostazioni del componente attuale, i designer possono facilmente creare un Branch e sottoporlo a revisione.
Una volta concluso il lavoro sul branch, il designer può richiedere una review ad altri stakeholder, che possono lasciare commenti o unire (merge) il branch se non ci sono problemi rilevanti.
ESSENTIALS
Dopo il file Foundation, il file Essentials include componenti più complessi, o "molecole", seguendo i principi dell'Atomic Design. L'idea è che i componenti presenti a questo livello siano costruiti a partire dai componenti presenti nel file Foundation. Un esempio potrebbe essere il componente Button Group.
Sopra, la documentazione del componente; sotto, la struttura di come il componente annidato viene mostrato nella toolbar laterale. Il designer può controllare sia il componente padre sia quello annidato, come mostrato qui sotto.
COMPOSITIONS
Il file Compositions è quello che ospita tutti i componenti riutilizzabili più grandi e strutturalmente più complessi. Qui sotto mostro come affrontare la costruzione di un componente riutilizzabile con l'esempio dell'Header.
Qui sotto un dettaglio di come vengono costruiti i componenti annidati.
E qui come apparirà un componente più complesso una volta costruito e documentato correttamente.
CONCLUSIONI E ACCORDO
Questi aggiornamenti al Design System hanno favorito una comunicazione fluida tra designer e sviluppatori e facilitato la realizzazione di nuove funzionalità. Ogni volta che sarà necessario implementare un nuovo componente o modificarne uno esistente, qui sotto ho definito un processo da condividere lato design su come affrontare possibili integrazioni.
