Cominciamo dall'inizio

Sistema di progettazione. Negli ultimi anni questo termine è ovunque. Per noi designer, la definizione e l'utilità di un sistema di progettazione sono evidenti. Tuttavia, per gli altri membri del team, non è sempre così chiaro. 

Se sai già cos'è un sistema di progettazione, non esitare a saltare direttamente al paragrafo sulla comunicazione.

Nel 2018, Usabilis ha offerto questa descrizione: un Design System è simile a una libreria di componenti, elementi visivi e principi con codice riutilizzabile. Questo toolkit in continua evoluzione fornisce un repository UX e UI per designer e sviluppatori di prodotti e servizi digitali. Va bene, ma senza il gergo tecnico?

Potremmo paragonare un sistema di design a una grande cucina. Ci sono molti ingredienti e ricette che ti permettono di usare correttamente questi ingredienti.

I cuochi del design system sono i designer (UI e UX) e gli sviluppatori. È per loro che il sistema di progettazione servirà di più. I designer selezioneranno gli ingredienti (creeranno i componenti), scriveranno le ricette (realizziamo i modelli) e le forniranno agli sviluppatori che cucineranno i piatti (svilupperanno i siti web, le app, ecc.).

Utilizzando una cucina comune, utilizzando gli stessi ingredienti e le stesse ricette, designer e sviluppatori sono sicuri di avere coerenza su tutti i piatti consegnati in camera (in produzione) e soprattutto di avere un risultato sviluppato molto vicino o addirittura identico al modelli creati a monte.

E questo non è nemmeno il principale vantaggio del sistema di progettazione! In effetti, il suo principale vantaggio è la velocità di esecuzione che rende possibile per l'intero team di prodotto (designer + sviluppatori). Essendo già pronti i componenti, non resta che assemblarli per creare nuove pagine, interfacce,…! Spesso confrontiamo il design system con i Lego, non per niente.

L'altro vantaggio principale deriva dagli aggiornamenti dei componenti. Infatti, essendo tutti i componenti “connessi” alla libreria, un aggiornamento di uno di essi direttamente nella libreria permette di aggiornare il componente senza sforzo ovunque venga utilizzato. Risparmia tempo, risparmia fatica (non c'è bisogno di cercare a mano dove viene utilizzato il componente!), cosa si può chiedere di più?

Disclaimer: per gli sviluppatori, il design system presenta vantaggi solo per il fronte. Non toglie in alcun modo la complessità della schiena e delle regole di gestione.

# Contenuti

Un sistema di progettazione generalmente consiste in 2 fonti di lavoro. Un sorgente per i progettisti, compatibile con i software utilizzati (Sketch, Figma,…) e un sorgente per gli sviluppatori, che presenta tutti i componenti già sviluppati e il loro codice. In entrambi i casi, i componenti presenti su questi sorgenti possono essere “chiamati” direttamente (o nei modelli per i progettisti, o nel codice per gli sviluppatori) il che fa risparmiare molto tempo e coerenza nella realizzazione.  

Quando si parla di design system, ci si riferisce più spesso al codice sorgente di sviluppo perché è quello utilizzato in produzione. Sono gli elementi che contiene a essere visibili agli utenti finali. Il codice sorgente di progettazione è destinato a essere visibile solo ai progettisti e agli sviluppatori.

Ma cosa c'è dentro? Beh, dipende. Ci sono ovviamente delle linee guida, una moltitudine di articoli che elencano le migliori pratiche. Non esitate a seguirli se non corrispondono del tutto alle esigenze. Inoltre, impostare un sistema di progettazione è qualcosa di molto lungo. Fare tutto in una volta è complicato. Ci sono però elementi importanti verso cui tendere, elementi meno primordiali che è comunque bene avere e che potremo aggiungere completamente in seguito.

Alcuni importanti elementi di contenuto:

• i colori
• tipografia
• grate
• i componenti
• le linee guida per l'utilizzo di tutti gli elementi sopra citati
• il tono da usare

Nella mia esperienza, i problemi principali durante l'impostazione di un sistema di progettazione sono:

• per l'azienda: il costo di costituzione e mantenimento che risulterà redditizio a lungo termine
• per i team che lo installeranno e lo utilizzeranno: anticipazione dell'arrivo di nuovi membri nel team e comunicazione designer-sviluppatore

Qui ci concentreremo su ciò che colpisce direttamente le squadre.

Se vi state chiedendo cosa renda così speciale l'arrivo di nuovi membri, ho una domanda per voi. Avete mai provato a cucinare a casa di qualcun altro? Se sì, avete aperto ogni armadietto e cassetto alla ricerca degli ingredienti e degli utensili necessari? Vi siete stupiti di non trovare una spezia che considerate essenziale? Per me, la risposta è sì.

È esattamente lo stesso per il nostro sistema di progettazione. Che si tratti di un nuovo sviluppatore o di un nuovo designer che si unisce al team, dovrà essere in grado di trovare molto rapidamente da solo ciò che sta cercando e che le istruzioni per l'uso siano sufficientemente chiare da consentirgli di utilizzare correttamente i componenti . Questo permetterà al nostro novellino (chiamiamolo Fred) di poter prendere in carico questo nuovo progetto nelle migliori condizioni e senza frustrazioni.

Poi arriva il problema della comunicazione. Per estensione della nomenclatura e disposizione dei componenti nel sistema di progettazione. Infatti, affinché i membri del team (nuovi o meno) possano orientarsi, il sistema di progettazione deve essere già intuitivo.   

Se i membri del team utilizzano più termini per fare riferimento allo stesso componente, prima o poi diventerà un problema.

Facciamo un semplice esempio :

Alcuni parleranno qui di elenco a discesa, altri di elenco a discesa. Altri ancora dall'elenco a discesa o anche da DDL. 4 possibili nomi per designare un singolo componente.

Se per più componenti del design system ognuno usa il proprio nome, la comunicazione tra le persone sarà sempre più difficile perché ognuno dovrà fare lo sforzo di ricordare che Lenny dice “dropdown”, Karl “DDL”, Lisa “droplist”.

Ciascuno quindi tradurrà ogni volta il pensiero dell'altro. In questo contesto, ora immagina Tony, l'ultimo arrivato. Non sa ancora che questi colleghi usano nomi diversi per parlare della stessa cosa. Durante una conversazione, Lisa gli parlerà della "lista a discesa". Va bene, Fred ne ha bisogno per il suo lavoro. Si riferirà quindi al sistema di progettazione e… non esiste un componente denominato “droplist”. Ci vorrà quindi uno sforzo in più per Fred per trovare il famoso componente. Dovrà anche imparare che Lenny e Karl usano altri termini. 

Al contrario, se per parlare del colore successivo hai detto "blu", e tutta la squadra usa lo stesso termine, la comunicazione andrà bene. Se diciamo "questo componente è blu", tutti intorno al tavolo sapranno di quale sfumatura di blu stiamo parlando.

Come puoi vedere, avere un'unica nomenclatura per tutti i membri del team, sia verbalmente che nel sistema di progettazione, è molto importante per avere una comunicazione fluida e anche per consentire una facile gestione e navigazione nel sistema di progettazione.

# Mantenere e aggiornare il sistema di progettazione

Un termine chiave nella descrizione di Usabilis è "scalabile". Un sistema di progettazione è pensato per essere in movimento. Queste non sono leggi scolpite nella pietra: gli elementi che lo compongono possono essere aggiornati, altri possono essere creati, vecchi componenti possono essere cancellati. Così come adattiamo una ricetta ai nostri gusti dopo averla preparata più volte, possiamo aggiungere nuovi ingredienti per ottenere più sapori, più sottigliezze. 

Un sistema di progettazione non è fine a se stesso. È uno strumento di lavoro per progettisti e sviluppatori. Come tale, si evolve insieme ai team e ai progetti.

Un sistema di progettazione non deve essere considerato come un progetto di durata limitata. I componenti e le regole che contiene possono cambiare. Potrebbero essere necessarie variazioni eccezionali di alcuni componenti. Pertanto, è importante continuare ad allocare risorse (dev + designer) per monitorare e mantenere il sistema di progettazione. Se fosse rimasto fuori per un anno, aggiornarlo sarebbe quasi come rifare tutto il lavoro per allestirlo. È molto lungo. Nessuno vuole farlo due volte. Per non parlare del costo per l'azienda. È quindi fondamentale destinare risorse al mantenimento e all'evoluzione del sistema progettuale. Un'ora alla settimana può essere sufficiente a seconda del grado di maturità del DS.

# Punti chiave

Se sei arrivato fin qui, spero che questo articolo abbia aperto nuovi orizzonti per il tuo sistema di progettazione, o che tu capisca meglio di cosa si tratta ea cosa serve.

Se doveste ricordare solo pochi punti :

• Il design system è uno strumento di creazione e comunicazione costruito da e per designer e sviluppatori
• Garantisce la consistenza di un prodotto
• Il suo costo di implementazione e manutenzione è ampiamente compensato dalla velocità di esecuzione che offre a progettisti e sviluppatori
• Può cambiare nel tempo
• Dovrebbe essere aggiornato regolarmente