Marzo 6, 2023 - di Mattia Picca
Design System: il linguaggio comune di progettazione del prodotto
Aziende come Apple, Google, IBM e Shopify utilizzano uno strumento unico nel suo genere che permette di aumentare drasticamente la qualità e il percepito dei loro prodotti: parliamo del Design System.
Ne sentiamo parlare sempre di più e sta diventando (per fortuna, direi) un must-do delle best practice nella progettazione di prodotti digitali… ma cos’è il Design System? Scopriamolo insieme!
Cosa approfondiremo in questo articolo:
- Cos’è il Design System?
- Quando è il momento giusto per costruire un Design System?
- Come si progetta un Design System?
- Come si sviluppa un Design System?
- Come si usa e mantiene un Design System?
- Perché è utile un Design System?
Cos’è il Design System?
Iniziamo con il dare una definizione tecnica e autorevole:
“Un Design System è un insieme di regole e standard usati per gestire il design su larga scala, riducendo la ridondanza, creando un linguaggio condiviso e una coerenza visiva tra diverse pagine e canali“.
Nielsen Norman Group
Cosa significa?
Si tratta di costruire un vero e proprio insieme di norme su come progettare e usare elementi visivi estremamente diversi tra di loro e che spaziano dal logo di un’azienda, fino al più piccolo bottone all’interno del loro sito o app. Il tutto, mantenendo ordine, rigore e pulizia visiva.
Se le parole ordine, rigore e pulizia visiva hanno stuzzicato la vostra curiosità, possiamo entrare nel dettaglio e analizzare quando è necessario, come progettare, sviluppare e come usare un Design System. Infine, vedremo perché è importante questo strumento e quali benefici comporta.
Quando è il momento giusto per costruire un Design System?
Potrei rispondere molto facilmente dicendo “Da subito!”, ma sarebbe irrealistico pensare che un progetto così complesso e impegnativo – come scopriremo – possa partire fin dal primo giorno. Con tono più realistico e pragmatico, vi posso però dire che è bene pensare fin da subito che arriverà il momento in cui sarà necessario.
Per capire, però, quando è necessario, abbiamo in nostro aiuto 3 elementi da tenere in considerazione.
1. La dimensione del progetto
Se state costruendo un progetto molto complesso – che richiede molto effort sia lato progettuale, sia lato sviluppo – non potete astenervi dal pensare fin da subito a progettare un design system. Come vedremo al termine dell’articolo, i benefici in termini di velocità di progettazione e sviluppo vi torneranno molto comodi per efficientare i tempi della vostra roadmap.
2. Il numero di persone coinvolte
Più è grande il numero di persone che lavorano al progetto, maggiore sarà la complessità gestionale ed implementativa. Usare, fin da subito, un Design System vi permetterà di ridurre questa complessità sapendo che tutto il team sarà allineato sul risultato finale del vostro prodotto.
3. Il tempo a vostra disposizione
Il tempo è un tiranno e lo sapete fin troppo bene! Se avete necessità di correre e uscire presto sul mercato con il vostro prodotto, il Design System vi richiederà un po’ del vostro tempo iniziale per il setting, ma vi regalerà maggiore flessibilità durante le fasi di progettazione e sviluppo. Siete davvero di corsa? Allora iniziate usando framework e UI kit già esistenti e open source. Non sarà totalmente vostro, è vero, ma avrete tutto il tempo di migliorare il vostro lavoro successivamente
Come si progetta un Design System?
I principi
La costruzione di un Design System può essere definito come il culmine della razionalità di un Product designer. Nel momento in cui iniziamo a strutturare questo progetto, mettiamo da parte per alcuni minuti (giorni in verità… ma va bene!) la parte creativa del nostro subconscio e cominciamo a ragionare sui principi che devono governare le scelte progettuali del nostro Design System.
Per comprendere meglio questo passaggio è utile un esempio.
Google, dall’ormai lontano 2014, ha progettato il suo Design System: Material Design. Questo si basa su una serie di principi di design basati sulla fisica, la psicologia e alcune ferree regole tipografiche.
Mi soffermo sul primo, la fisica. Nel progettare i vari elementi di UI, Google ha immaginato ogni componente come se fosse un oggetto tridimensionale, illuminandolo con una luce. Studiando sovrapposizioni, profondità e il modo in cui la luce regola le ombre, sono nati gli stili di questi componenti.
Se vi sembra complesso, non spaventatevi. Non dobbiamo necessariamente trovare o studiare principi esageratamente elaborati. Possiamo anche rifarci a regole e norme di buon design già utilizzate da molti anni. Basti pensare alla Gestalt, nome ripreso anche da Pinterest per il suo Design System, oppure le iterazioni uomo-macchina e la teoria dello Human-centered Design, ripresi da Apple per le Human Interface Guidelines. I vostri designer sapranno trovare la soluzione più idonea per le vostre esigenze.
Questa fase è anche il momento principale di dialogo tra Product Manager e Product Designer (se vi serve un ripasso, abbiamo già parlato di quanto sia importante la sinergia tra PM e PD, di chi è e cosa fa il Product Designer e anche di come creare un design inclusivo per ampliare l’accessibilità): grazie alle conoscenze di prodotto e business, il PM sarà in grado di indirizzare e mantenere il focus sugli obiettivi di prodotto e il Designer riuscirà a tradurre queste informazioni in principi di Design.
Un consiglio ai Product Manager: ricordatevi che la scrittura dei Principi è un task che può richiedere molto studio e tempo. Dialogate fin da subito con i Designer coinvolti per capire le esigenze temporali di questa attività e supportatela con processi e logiche SCRUM per raggiungere rapidamente l’obiettivo.
I componenti
Abbiamo identificato i nostri principi, più o meno complessi che siano, e abbiamo bene in testa qual è il mood di quello che vogliamo progettare. Ora dobbiamo iniziare a creare. Cosa? I componenti che costituiscono il nostro Design System.
Possiamo suddividere i componenti in 3 macro-aree:
- Foundation, o elementi di base;
- Componenti;
- Pattern.
Per Foundation intendiamo gli elementi di stile base che regolano il nostro Design System e sono figli dei principi che abbiamo deciso in precedenza. Nei Foundation troveremo quindi i colori della nostra palette, i font e icone che usiamo, griglie, indicazioni delle dimensioni per componenti/spazi e tanto altro.
Le Foundation sono anche la struttura di base (o elementi atomici se vogliamo riprendere la teoria dell’Atomic Design) su cui, in un secondo momento, vedremo la costruzione dei Design Token, ma ci arriveremo.
Per Componenti, invece, ci allontaniamo dallo spettro degli stili ed entriamo nel mondo degli item utili a strutturare le interazioni che i nostri utenti svolgeranno sui nostri prodotti digitali: bottoni, tabelle, liste, grafici… tutto quello che è visibile e permette un’azione.
Infine, i Pattern, rappresentano le specifiche interazioni dei nostri utenti. Sono elementi più complessi rispetto ai Componenti, ripetibili e racchiudono la complessità dell’esperienza utente.
Un esempio: le modali sono un Pattern, composto da vari Componenti (bottoni, check-box, etc.), strutturato seguendo le Foundation (colori, margini, spazi, testo, etc.) e vengono usate tutte allo stesso modo, indifferentemente dal contenuto, per focalizzare l’attenzione dell’utente su un tema importante che deve essere portato all’attenzione dell’utente.
Completate queste attività, avremo a disposizione il nostro deliverable da dare in pasto al team di sviluppo.
Il deliverable
Quale sarà il deliverable? Qualunque strumento abbia usato il designer per progettare i vari componenti (Figma, Sketch, etc.), vi occorreranno:
- Una library dei componenti creati, che si traduce in un file contenente tutto il materiale grafico necessario per lo sviluppo;
- Una guida ai principi e all’uso delle Foundation (un foglio Confluence, una presentazione… qualunque cosa possa presentare queste informazioni).
Fate attenzione, nelle fasi di review (se vuoi approfondire, abbiamo anche scritto dei 10 segreti per una sprint review interessante), a come porre un feedback: il buon design non è soggettivo ed ogni scelta è motivata. Se avete dubbi o domande su una scelta di stile, ricordate di chiederne la motivazione anziché immaginare a come avreste svolto voi il lavoro. Allo stesso modo, ogni vostro feedback va giustificato. Tradotto: il feedback “A me non piace…” o “Io lo farei giallo…” sono banditi se non sono seguiti da un “perché…”.
Come si sviluppa un Design System?
Il modo che sceglieremo per sviluppare il nostro Design System è totalmente libero e si baserà su tipologia di tecnologia che utilizzate, sul tipo di app (web, iOS, Android), sul tipo di linguaggio di linguaggio che usate e tanti altri fattori tecnici.
Per sviluppare al meglio il vostro progetto, posso presentarvi due best pratice da seguire:
- Revisionate il Design System con il vostro team Tech;
- Adottate l’implementazione dei Design Token.
Comunicare con chi prenderà il nostro progetto di design e lo renderà tangibile anche agli utenti finali è fondamentale: vedere fin da subito (dal momento dell’ideazione dei principi sarebbe l’ideale) il lavoro svolto, prima che questo venga sviluppato, ci permetterà di esaminare ogni criticità implementativa prima che questa si manifesti, ma non solo. Questo creerà una serie di rituali e cerimonie tra Designer, Dev e Product Manager per strutturare un piano di sviluppo e rilascio compatibile con la complessità dei vari elementi da sviluppare.
I Design Token, invece, sono un’ottima pratica in ottica di scalabilità e modifica del nostro Design System.
Per Design Token si intendono tutte le variabili di stile che identificano gli elementi essenziali (es. colori e font) e i vari componenti che costituiscono il Design System. Una volta codificata ogni variabile di stile del nostro Design System, potremmo inserirli nel flusso di sviluppo coscienti del fatto che (se in un secondo momento) cambieremo qualcosa, potremo farlo velocemente su tutti i componenti che utilizzano la variabile che stiamo modificando.
Se abbiamo seguito queste semplici regole e abbiamo strutturato tutto il nostro lavoro al meglio, avremo ottenuto un framework totalmente funzionante e implementabile. Ora dobbiamo normarne l’uso, la conservazione e l’aggiornamento.
Come si usa e mantiene un Design System?
Normare l’uso di un Design System è la parte più burocratica e meno creativa del processo, ma è quello che ci allontanerà il più possibile dagli errori.
Per fare un paragone: abbiamo di fronte una feature complessa e come farebbe un buon Product Manager, dobbiamo strutturare le Spec che spiegano questa feature tenendo conto di due livelli di lettura diversi:
- Da un lato dovremo fare in modo che ogni Designer abbia a portata le regole d’uso e progettazione del nostro Design System;
- Dall’altro lato dovremo mettere a disposizione dei nostri Dev uno spazio dove poter conservare, catalogare e tenere traccia delle modifiche del nostro framework.
Per tutto quello che è Design, possiamo muoverci su più livelli e con più strumenti. Possiamo creare delle librerie su Figma, Sketch o qualunque strumento usino i vostri Designer e, molto probabilmente, lo avranno già fatto durante la fase di progettazione. Vogliamo rendere disponibile questo materiale anche ai non addetti ai lavori o a persone esterne all’azienda? Allora struttureremo delle documentazioni del nostro Design System sul nostro sito aziendale, oppure con documentazioni digitali (su Confluence ad esempio).
Per quello che riguarda lo sviluppo e mantenimento del nostro Design System, servizi come Storybook o Pattern Lab ci permetteranno di costruire una documentazione efficiente e utile ai nostri Dev.
Ricordate: questa attività di documentazione richiede mantenimento e aggiornamenti costanti! Un Design System non è mai fermo, ma cambia in base a quanto cresce il progetto, come cambia la tecnologia e, soprattutto, come si approcciano gli utenti del vostro prodotto.
Proprio gli utenti finali saranno il vero ago della bilancia che sposterà le logiche e i tempi di mutamento e aggiornamento del vostro Design System (e consecutivamente della vostra documentazione).
Un buon modo per non perderci questo fattore? Organizzate momenti di retrospettiva sul Design System dove analizzare feedback, richieste e segnalazioni degli utenti e usate sistemi di tracciamento oggettivi come Google Analytics, Hubspot e altri per tracciare e monitorare l’esperienza utente degli utenti.
Questi dati saranno utilissimi e influenzeranno aspetti che potreste aver trascurato o non considerato nelle fasi di progettazione, come l’accessibilità del vostro prodotto o l’esperienza d’uso su particolari device.
Perché è utile un Design System?
Se siete arrivati a leggere fino a qui, penso che abbiate ben in mente quali sono i benefici di avere ed usare un Design System all’interno del vostro prodotto, ma riassumiamoli:
1. Velocità di progettazione
Completato questo enorme lavoro, avrete a disposizione una serie di strumenti di progettazione rapida che ridurrà drasticamente i tempi di sviluppo e implementazione di una feature, permettendovi di aumentare il numero di progetti su cui lavorare.
2. Miglioramento dell’esperienza utente
Con una serie di preset logici e visivi già strutturati, l’esperienza utente sarà più semplice e incentrata su action e pattern ripetibili, in modo da evitare flussi complessi e disallineati tra loro.
3. Scalabilità e Flessibilità
La rapida modifica e implementazione di nuovi componenti, vi permetterà di scalare il vostro Design System in base alla crescita tecnologica del vostro prodotto digitale.
Come dicevo, i benefici sono lampanti, anche se il costo del lavoro iniziale richiesto può sembrare enorme o eccessivo.
Un ultimo consiglio? Iniziate fin da subito ad usare il Design System!
———
Se avete già creato un Design System o state pensando che sia il momento buono per crearlo, questo è il luogo giusto per parlarne insieme! Raccontatecelo nei commenti 😉
